Re: [PATCH v2 2/3] fast-import: allow "merge $null_sha1" command

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 27, 2012, 23:39 UTC
Message-ID: <20120627233931.GA3014@burratino>
In-Reply-To: <7v395g75gg.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Dmitry Ivankov <divanorama@gmail.com> writes:

Show 5 quoted lines

>> "from $null_sha1" and "merge $empty_branch" are already allowed so
>> allow "merge $null_sha1" command too.
>
> Would accepting such a "merge oops-do-not-do-anything" allow
> exporters' job to be simpler?

Good question.

I was uncomfortable with the patch and couldn't pin down why and I think you've hit it.

I can imagine an importer that does

	cat <<EOF
	commit refs/heads/master
	from $parent
	merge $second_parent
[etc]
	EOF

and uses parent=0000000000000000000000000000000000000000 in the degenerate case, but it is not hard to use

	cat <<EOF
	commit refs/heads/master
	$optional_from_line$optional_second_parent
[etc]
	EOF

so this is not a very strong justification. Mostly it felt like a step in the right direction because once you can do it for "from", someone might try it with "merge" and it's simplest to explain the syntax if we're consistent.

On the other side to be weighed against that is the danger that someone might actually start using "merge" this way. They would be making their frontend break compatibility with old versions of git fast-import for no good reason.

So on second thought, it does not seem like a good direction at all. [Though the cleanup I mentioned might be nice in any case. ;-)]

I wonder if anyone using "from" with a branch name that resolves in the internal branch table to $null_sha1 was actually intending that. Would any importers break if we started to forbid it? Would it make sense to add that check in "next" for a release or two and see if anyone complains?

Looking at the patch for 00e2b884 (Remove branch creation command from fast-import, 2006-08-24), it looks like support for "from $null_sha1" was intentional. Maybe mailing list discussions from around then have insight.

Thanks for some food for thought, Jonathan