1. Summarise the issue (what were doing, what went wrong?)

When doing `darcs record` without any flag, darcs prompts the user for 
the patch name and then asks "Do you want to add a long comment?".

I remember this annoyed students two years ago when they used darcs for 
the first time (as reported in http://darcs.net/Ideas/Education ).

2. What behaviour were you expecting instead?

Don't ask for a long description. I suspect few people actually use this 
and they can use `darcs record --edit`, or correct the patch afterwards 
with `darcs amend --edit`.

On 05/10/2013 08:05 PM, Guillaume Hoffmann wrote:
> 2. What behaviour were you expecting instead?
>
> Don't ask for a long description. I suspect few people actually use this
> and they can use `darcs record --edit`, or correct the patch afterwards
> with `darcs amend --edit`.

I use this y/n feature[1].  I often only make the decision whether to 
write a long description once I've written the short description (and 
decided whether it's sufficient).  I write a long description maybe a 
third of the time.  The `darcs record --edit` workflow seems okay if I'm 
okay with always passing --edit, interacting with readline, *and* then 
interacting with Vim.[2]

Alternatively, I tried the `darcs amend --edit` workflow and it asked 
which patch I wanted to amend (not too bad) and then asked me to 
reconsider which changes I wanted to include in the commit 
(confusing[3]) and *then* it let me edit the message.

As long as there's still a discoverable okay workflow I'll be happy.

Hmm, if I configure --prompt-long-comment to be a default flag, it'd 
restore the y/n behavior (--prompt-long is a bit lengthy to type by hand 
every time).

[1] though I'm not very important since I mostly use Git these days.

[2] Brainstorming: Perhaps the readline and editor steps can be combined 
somehow - which would be a different feature.  Or the readline step 
could allow one to press enter with an empty commit-message line to go 
straight to the editor [if --edit is passed].

[3] `darcs amend` doesn't tell me which keys to press to mean "don't 
change which changes are in this commit".  This deserves to be improved.

-Isaac

What about always editing long comment?

It'd be good if we could have a way of finding out who uses this
feature. Also: it's possible that folks don't use this feature because
they don't really understand what it's for, and if they were just
dumped straight into it might partake of it.

I edit long comments all the time, but then I only reflect one kind of
user population (programmer types), and probably a more fanatical one
at that.  Other types of users (eg. non-programmer types who for
whatever reason are working with darcs fans) will tend not to put any
comments at all, not even a patch name (or will at least put the
minimum they can get away with)

Generally, descriptive comments probably make for better version
control.  Is there a way to encourage that behaviour without pissing
off users who don't yet know they should care about version control?



On 11 May 2013 03:33, Isaac Dupree <bugs@darcs.net> wrote:
>
> Isaac Dupree <ml@isaac.cedarswampstudios.org> added the comment:
>
> On 05/10/2013 08:05 PM, Guillaume Hoffmann wrote:
>> 2. What behaviour were you expecting instead?
>>
>> Don't ask for a long description. I suspect few people actually use this
>> and they can use `darcs record --edit`, or correct the patch afterwards
>> with `darcs amend --edit`.
>
> I use this y/n feature[1].  I often only make the decision whether to
> write a long description once I've written the short description (and
> decided whether it's sufficient).  I write a long description maybe a
> third of the time.  The `darcs record --edit` workflow seems okay if I'm
> okay with always passing --edit, interacting with readline, *and* then
> interacting with Vim.[2]
>
> Alternatively, I tried the `darcs amend --edit` workflow and it asked
> which patch I wanted to amend (not too bad) and then asked me to
> reconsider which changes I wanted to include in the commit
> (confusing[3]) and *then* it let me edit the message.
>
> As long as there's still a discoverable okay workflow I'll be happy.
>
> Hmm, if I configure --prompt-long-comment to be a default flag, it'd
> restore the y/n behavior (--prompt-long is a bit lengthy to type by hand
> every time).
>
> [1] though I'm not very important since I mostly use Git these days.
>
> [2] Brainstorming: Perhaps the readline and editor steps can be combined
> somehow - which would be a different feature.  Or the readline step
> could allow one to press enter with an empty commit-message line to go
> straight to the editor [if --edit is passed].
>
> [3] `darcs amend` doesn't tell me which keys to press to mean "don't
> change which changes are in this commit".  This deserves to be improved.
>
> -Isaac
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2321>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

2013/5/11 Eric Kow <kowey@darcs.net>:
> What about always editing long comment?

This is actually what Svn, Git, Mercurial and Bazaar do. So there is
also a "let's be consistent with the rest of the universe" point here
to be made.

And it's good since it does not split the description edition step in
two, which is my complaint to the current UI.

g.

I think I like this general trend of

  Make Interactivity Count

In the sense that the interactive UI is a great asset to Darcs, *but*
if it's used in the wrong place will ruin the experience and make it
harder to appreciate the places where it really does serve well.  So
rah-rah getting rid of prompts when they only get in people's ways, or
confuse them, etc… (but using prompts in places where they make Darcs
easier to use/more powerful).  Subtle and difficult.  We'll get there!

On 11 May 2013 19:49, Guillaume Hoffmann <guillaumh@gmail.com> wrote:
> 2013/5/11 Eric Kow <kowey@darcs.net>:
>> What about always editing long comment?
>
> This is actually what Svn, Git, Mercurial and Bazaar do. So there is
> also a "let's be consistent with the rest of the universe" point here
> to be made.
>
> And it's good since it does not split the description edition step in
> two, which is my complaint to the current UI.
>
> g.



-- 
Eric Kow <http://erickow.com>

Updating the issue name to fit the conclusion we reached in the 
discussion.

The following patch sent by Jose Luis Neder <jlneder@gmail.com> updated issue issue2321 with
status=resolved;resolvedin=2.10.0 HEAD

* resolve issue2321: when no patch name given, directly invoke text editor 
Ignore-this: 9d678890810c837a6fa845c9a6d23dfe