Re: [PATCH] Allow multiple merges to invalid HEAD

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 3, 2011, 21:52 UTC
Message-ID: <20110403215246.GA6332@elie>
In-Reply-To: <7vlizrg6ef.fsf@alter.siamese.dyndns.org>

(+cc: Martin, who also requested something like this long ago[1] iirc) Hi,

The following is only about motivation; I'm ignoring the mechanics for now.

Junio C Hamano wrote:

Show 15 quoted lines

> What's the point of being able to do this in the first place?
>
> The _only_ reason "git pull $there $branch" into an unborn branch exists
> is because it feels like
>
> 	$ git clone $there $directory
>
> could be broken down as this command sequence:
>
> 	$ mkdir $directory
>         $ cd $directory
>         $ git init
>         $ git remote add origin $there
> 	$ git fetch
>         $ git pull $there ;# or "git merge origin/master"

I'm to blame for the suggestion, I'm afraid.

I haven't wanted to be able to "git init && git remote add origin $there && git fetch && git merge origin/topic-1 origin/topic-2" for a long time, but there was a time (around 3 years ago, I think) I wanted it a lot.

In fact I can't remember the details of why.  The facts I remember:

 - /etc was kept in a git repository managed by etckeeper;
 - history was not precious --- it was just a way of understanding the
   final result;
 - the user wasn't sure how to manage topic branches yet.  The usual
   workflow involved

    (1) cherry-picking each automatic commit to an appropriate topic
        branch and writing a sensible description
    (2) bundling the topic branches together with an octopus merge
    (3) diff-ing against the automatically committed latest state to
        see if anything was missing
    (4) force a push.

So I suspect my use case was "start with a bundle of these branches". I could have (and did) used "git checkout -b" to grab the first one and merged the rest, but somehow a merge into nothingness seemed more intuitive. Remember, this is before the days of checkout --orphan and rebase -i --everything.

That said.

I doubt the above is a very compelling use case, to justify the maintenance cost and easily explain in documentation. I would find something like the following more compelling:

	Currently git merge has a special case to "pull into
	emptiness", to support the following sequence of commands:

		git init repo
		cd repo
		git remote add origin $url
		git fetch origin
		git merge origin/master

	But it is very much a special case.  It does not support
	octopus merges, --squash, --stat, alternate strategies,
	or any of the rest of merge machinery.

	It would be more intuitive if the above features _did_ work
	where they make sense, and if this essentially worked as
	though performing an ordinary merge with merge base being an
	empty tree that is ancestor of everything.

	Here is a first step --- support for octopus merges.  It
	also makes it easier to support the others, by [...].

> It very much feels like
> "because I can make things more complex", not "because this is an often
> desired missing feature that is a major pain point".

Therefore a good goal would be to make this make the code more simple at the same time as making the semantics so.

(But also: Tim, please don't feel attached to this topic if you're not interested in it; there are many more out there.)

Thanks for some useful feedback. Jonathan

[1] http://bugs.debian.org/432558