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>

Reply via email to