RFC: new git-transplant subcommand for non-interactively moving commits between branches

[Adam Spiers <git@adamspiers.org>]

On Fri, May 27, 2016 at 03:08:11PM +0100, Adam Spiers wrote:
> Hi all,
>
> I finally got around to implementing a new git subcommand which I've
> wanted for quite a while.  I've called it git-splice.

[snipped]

> Next steps, and the future
> --------------------------
>
> Obviously, I'd welcome thoughts on whether it would make sense to
> include this in the git distribution.
>
> In the longer term however, I'd like to write two more subcommands:
>
>   - git-transplant(1) which wraps around git-splice(1) and enables
>     easy non-interactive transplanting of a range of commits from
>     one branch to another.  This should be pretty straightforward
>     to implement.

I've now written git-transplant too (and in the process of doing so,
made many more enhancements to git-splice).


Usage
-----

Examples:

    # Move commits A..B from the current branch onto branch X
    git transplant A..B X

    # Move commits A..B from the current branch into branch X after commit C
    git transplant --after=C A..B X

    # Create a new branch X starting at ref Y, then
    # move commits A..B from the current branch onto X
    git transplant --new-from=Y C A..B X

    # Abort a transplant which failed during cherry-pick or rebase
    git transplant --abort

    # Resume a transplant after manually fixing conflicts caused by
    # cherry-pick or rebase
    git transplant --continue

N.B. this command rewrites history, since after splicing the commits
into the target branch, it removes them from the current branch.  As
with git rebase, you should be aware of all the implications of
history rewriting before using it.


Motivation
----------

See the rest of this mail thread.


Code
----

> Currently this is in alpha state:
>
>   https://github.com/git/git/compare/master...aspiers:splice
>
> and I reserve the right to rewrite the history of that branch in the
> near future ;-)

This still holds for git-splice, but also now for git-transplant too:
the same branch now contains git-transplant and its test suite.


Next steps
----------

- Wait for feedback.  (Ideally I hope people will actually try both tools.)

- If there is any appetite for eventually moving this into the
  distribution, it will still need quite a few things cleaning up first,
  e.g. making the coding style consistent with git's, getting rid of
  bashisms ...

- (Eventually) write git-explode, as explained elsewhere in this thread.


Cheers!
Adam