On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > 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`, `bud` and `reset` commands > to label commits and to reset to a labeled commits. This patch adds the > `merge` command, with the following syntax: > > merge <commit> <rev> <oneline> > > The <commit> parameter in this instance is the *original* merge commit, > whose author and message will be used for the to-be-created merge > commit. > > The <rev> parameter refers to the (possibly rewritten) revision to > merge. Let's see an example of a todo list: > > label onto > > # Branch abc > bud > pick deadbeef Hello, world! > label abc > > bud > pick cafecafe And now for something completely different > merge baaabaaa abc Merge the branch 'abc' into master > > To support creating *new* merges, i.e. without copying the commit > message from an existing commit, use the special value `-` as <commit> > parameter (in which case the text after the <rev> parameter is used as > commit message): > > merge - abc This will be the actual commit message of the merge > > This comes in handy when splitting a branch into two or more branches. >
Would it be possible to open the editor with the supplied text when there's no commit? The text after <rev> must be oneline only.. It's difficult to reword merges because of the nature of rebase interactive, you can't just re-run the rebase command and use "reword". I suppose you could cheat by putting in an "edit" command that let you create an empty commit with a message... Thanks, Jake
