git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Adam Spiers <git@adamspiers.org>
Cc: git mailing list <git@vger.kernel.org>
Subject: Re: RFC: new git-splice subcommand for non-interactive branch splicing
Date: Fri, 27 May 2016 17:27:14 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1605271701500.4449@virtualbox> (raw)
In-Reply-To: <20160527140811.GB11256@pacific.linksys.moosehall>

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

  reply	other threads:[~2016-05-27 15:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27 14:08 RFC: new git-splice subcommand for non-interactive branch splicing Adam Spiers
2016-05-27 15:27 ` Johannes Schindelin [this message]
2016-05-27 16:36   ` Adam Spiers
2016-05-28  7:06     ` Johannes Schindelin
2016-05-28 11:24       ` Adam Spiers
2016-05-30  0:34 ` RFC: new git-transplant subcommand for non-interactively moving commits between branches Adam Spiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1605271701500.4449@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git@adamspiers.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).