Re: [PATCH] Allow multiple merges to invalid HEAD

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2011, 07:07 UTC
Message-ID: <7vlizrg6ef.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1301813216-19507-1-git-send-email-tnachen@gmail.com>

Timothy Chen <tnachen@gmail.com> writes:

> Subject: Re: [PATCH] Allow multiple merges to invalid HEAD

I thought somebody already suggested to reword "invalid HEAD" to something more sensible, like "unborn branch", but I may be misremembering things...

Show 7 quoted lines

> Currently git merge only allows one branch when current HEAD
> is not yet pointing to a valid commit.
>
> This patch will allow multiple branches to be passed in,
> and first updates current HEAD to the first branch's head then subsequently
> merge the rest of the branches.
> ---

Missing sign-off.

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"

And all the above steps actually do work, except for the last step and that is why we added the "pull into emptiness" hack.

Even though it does a very different thing at the mechanical level, having the hack helps these two sequences (a single "clone" vs the "init/remote add/fetch/merge") that are conceptually similar to behave the same.

I however don't think of a halfway sane rationale similar to why we have "merge one into emptiness" to justify this patch. 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".