On Sat, Feb 10, 2018 at 7:10 PM, 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` and `reset` commands to label > commits and to reset to a labeled commits. This patch adds the `merge`
s/to a/to/ > 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: > > label onto > > # Branch abc > reset onto > pick deadbeef Hello, world! > label abc > > reset onto > pick cafecafe And now for something completely different > merge -C baaabaaa abc # Merge the branch 'abc' into master > > To edit the merge commit's message (a "reword" for merges, if you will), > use `-c` (lower-case) instead of `-C`; this convention was borrowed from > `git commit` that also supports `-c` and `-C` with similar meanings. > > To create *new* merges, i.e. without copying the commit message from an > existing commit, simply omit the `-C <commit>` parameter (which will > open an editor for the merge message): > > merge abc > > This comes in handy when splitting a branch into two or more branches. > > Note: this patch only adds support for recursive merges, to keep things > simple. Support for octopus merges will be added later in a separate > patch series, support for merges using strategies other than the > recursive merge is left for the future. > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de>
