Hi Philip, On Sun, 22 Apr 2018, Philip Oakley wrote:
> From: "Johannes Schindelin" <johannes.schinde...@gmx.de> > > This patch is part of the effort to reimplement `--preserve-merges` with > > a substantially improved design, a design that has been developed in the > > Git for Windows project to maintain the dozens of Windows-specific patch > > series on top of upstream Git. > > > > The previous patch implemented the `label` and `reset` commands to label > > The previous patch was [Patch 05/16] git-rebase--interactive: clarify > arguments, so this statement doesn't appear to be true. Has a patch been > missed or re-ordered? Or should it be simply "This patch implements" ? > Likewise the patch subject would be updated. As Phillip guessed correctly, it was a mistaken `git commit --amend`. > > commits and to reset to labeled commits. This patch adds the `merge` > > s/adds/also adds/ ? No, as I really want to keep those two commits separate. I disentangled them. > > command, with the following syntax: > > > > merge [-C <commit>] <rev> # <oneline> > > > > The <commit> parameter in this instance is the *original* merge commit, > > whose author and message will be used for the merge commit that is about > > to be created. > > > > The <rev> parameter refers to the (possibly rewritten) revision to > > merge. Let's see an example of a todo list: > > > The example ought to also note that `label onto` is to > `# label current HEAD with a name`, seeing as this is the first occurance. > It may be obvious in retrospect, but not at first reading. I added some sentence to describe what `label onto` does and why. > > label onto > > > > # Branch abc > > reset onto > > Is this reset strictly necessary. We are already there @head. No, this is not strictly necessary, but - it makes it easier to auto-generate (otherwise you would have to keep track of the "current HEAD" while generating that todo list, and - if I keep the `reset onto` there, then it is *a lot* easier to reorder topic branches. Ciao, Dscho
