Hi Junio, On Tue, 30 Jan 2018, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > Changes since v1: > > > > - reintroduced "sequencer: make refs generated by the `label` command > > worktree-local" (which was squashed into "sequencer: handle autosquash > > and post-rewrite for merge commands" by accident) > > Good. > > > - got rid of the universally-hated `bud` command > > Universally is a bit too strong a word, unless you want to hint that > you are specifically ignoring my input ;-). In the interest of comic effect, I exaggerated a little. > > - the no-rebase-cousins mode was made the default > > Although I lack first-hand experience with this implementation, this > design decision matches my instinct. Excellent. > May comment on individual patches separately, later. 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. 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>. 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). 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'll probably refrain from implementing support for -m because I do not want to implement the dequoting. Ciao, Dscho
