Hi Adam,
On Fri, 27 May 2016, Adam Spiers wrote:
> Description
> -----------
>
> git-splice(1) non-interactively splices the current branch by removing
> a range of commits from within it and/or cherry-picking a range of
> commits into it. It's essentially just a glorified wrapper around
> cherry-pick and rebase -i.
It sounds as if you could accomplish the same with
git checkout -b former-commits <split>
git checkout -b latter-commits <base>
git cherry-pick <split>..HEAD@{2}
> Next steps, and the future
> --------------------------
>
> Obviously, I'd welcome thoughts on whether it would make sense to
> include this in the git distribution.
Far be I from discouraging you to work on these scripts, but I think that
a really good place for such subcommands is a separate repository, as you
have it already. There are already some rarely used subcommands in
libexec/git-core/ cluttering up the space and I would be reluctant to add
even more subcommands to the default Git installation delivered to every
user.
You can *always* just extend the PATH so that git-splice can be found;
Then `git splice ...` will do exactly what you want. That is e.g. how
git-flow works. (Of course I hope that you will maintain your scripts
much, much better than git-flow, i.e. not abandon all users).
> 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.
This is just cherry-pick with a range...
> - git-explode(1) which wraps around git-transplant(1) and
> git-deps(1), and automatically breaks a linear sequence of commits
> into multiple smaller sequences, forming a commit graph where
> ancestry mirrors commit dependency, as mentioned above. I expect
> this to be more difficult, and would probably write it in Python.
You mean something like Darcs on top of Git. Essentially, you want to end
up with an octopus merge of branches whose commits would conflict if
exchanged.
I implemented the logic for this in a shell script somewhere, so it is not
*all* that hard (Python not required). But I ended up never quite using it
because it turns out that in practice, the commit "dependency" (as defined
by the commit diffs) does not really reflect the true dependency.
For example, in my work to move large parts of rebase -i into a builtin, I
have an entire series of commits that do nothing else but prepare the
sequencer for rebase -i's functionality. Most of these commits touch
completely separate parts of the code, so they would make independent
branches in your git-explode command. Yet, that would destroy the story
that the patch series tells, as the natural flow would get lost.
Another major complication is that sometimes the "dependency as per the
diff" is totally bogus. Take for example Git for Windows' patches on top
of Git: there are a couple "sub branches" that add global variables to
environment.c. By the logic of the overlapping (or touching) hunks, these
sub branches should build on top of each other, right? But they are
logically completely independent.
So I think that this is a nice exercise, but in practice it will require a
human to determine which commits really depend on each other.
> Eventually, the utopia I'm dreaming about would become a reality and
> look something like this:
>
> git checkout -b new-feature
>
> while in_long_frenzied_period_of_hacking; do
> # don't worry too much about branch maintenance here, just hack
> git add ...
> git commit ...
> done
>
> # Break lots of commits from new-feature into new topic branches:
> git explode
>
> # List topic branches
> git work list
You would render me *really* impressed if you could come up with an
automated way to determine logical dependencies between patches.
Ciao,
Johannes
--
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