On Wed, Jan 31, 2018 at 5:29 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > I think I may want to introduce a bigger change, still. I forgot who > exactly came up with the suggestion to use `merge -C <original-commit> > <to-merge>` (I think it was Jake), and I reacted too forcefully in > rejecting it. >
I believe someone else suggested it, but I replied that I liked it. > This design had been my original design in the Git garden shears, and I > did not like it because it felt clunky and it also broke the style of > <command> <commit>. > I agree it's a bit weird it breaks the style of "<command> <commit>", but on some level merge does this anyways as it's the first one to take more than one argument. > But the longer I think about this, the more I come to the conclusion that > I was wrong, and that the -C way is the way that leaves the door open to > the pretty elegant `-c <commit>` (imitating `git commit`'s option to > borrow the commit message from elsewhere but still allowing to edit it). > The other reason I liked this, is that it matches merge syntax on the command line, so users don't need to learn a special new syntax for the todo file. > And it also leaves open the door to just write `merge <to-merge>` and have > the sequencer come up with a default merge message that the user can then > edit. I like that we could completely forgo the -C and -c in order to allow the normal default merge commit message that is auto generated as well. > > I'll probably refrain from implementing support for -m because I do not > want to implement the dequoting. > Yea, I don't think that is necessary either. Thanks, Jake > Ciao, > Dscho
