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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html