Hi Philip, On Thu, 18 Jan 2018, Philip Oakley wrote: > From: "Jacob Keller" <jacob.keller@xxxxxxxxx> > > On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin > > <johannes.schindelin@xxxxxx> wrote: > > > This commit implements the commands to label, and to reset to, given > > > revisions. The syntax is: > > > > > > label <name> > > > reset <name> > > > > > > As a convenience shortcut, also to improve readability of the generated > > > todo list, a third command is introduced: bud. It simply resets to the > > > "onto" revision, i.e. the commit onto which we currently rebase. > > > > > > > The code looks good, but I'm a little wary of adding bud which > > hard-codes a specific label. I suppose it does grant a bit of > > readability to the resulting script... ? It doesn't seem that > > important compared to use using "reset onto"? At least when > > documenting this it should be made clear that the "onto" label is > > special. > > > > Thanks, > > Jake. > > I'd agree. > > The special 'onto' label should be fully documented, and the commit message > should indicate which patch actually defines it (and all its corner cases and > fall backs if --onto isn't explicitly given..) I hoped that the example todo lists would clarify that 'onto' is just the name of the first label: label onto is *literally* how all of those todo lists start. And that is why there are no possible concerns about any missing `--onto` argument: that argument is irrelevant for that label. Maybe it is just a bad name. Maybe `START` would be a better label. What do you think? > Likewise the choice of 'bud' should be explained with some nice > phraseology indicating that we are growing the new flowering from the > bud, otherwise the word is a bit too short and sudden for easy > explanation. I dropped the `bud` command. Ciao, Dscho
