Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

>> $ # uses HEAD~1 instead of refs/heads/master
>> $ git fast-export HEAD~1
>>
>> blob
>> mark :1
>> data 0
>>
>> reset HEAD~1
>> commit HEAD~1
>
> Thanks for the report.  It turns out this bug has been reported and is
> in the testsuite as t9350.19 -- currently marked as expected to fail.
> I looked at the problem a couple years ago for a little bit but never
> finished that particular patch and never got back around to it.

What _should_ be the right behaviour to begin with, I have to wonder.

Even though it is very clear that the set of objects that are exported are
defined by the "rev-list arguments" given to the command, I do not think
fast-export's semantics is not clearly defined as to what "refs" are to be
updated.

The easiest fix for this issue would be to forbid "git fast-export HEAD~1"
(or any range whose positive endpoints are _not_ refs), and I think that
would be in line with the original motivation of the command to export the
whole repository in a format fast-import would understand.  The original
f2dc849 (Add 'git fast-export', the sister of 'git fast-import',
2007-12-02) says "This program dumps (parts of) a git repository...",
implying that partial export is within the scope of the command, but I do
not think it was designed carefully enough to deal with ranges more
complex than just "a set of branches".

I however have a feeling that people would want to say:

 - I want to export up to that commit, and have that commit on this branch
   on the importing side; or even better

 - I want to export up to that commit, but what refs points at the commits
   contained in the output stream will be decided when the output is
   imported.

I do not think the latter meshes well with how "fast-import" works,
though.  But fast-export should be fixable to allow the former without
breaking the semantics of fast-import.

You can think of "fast-export" an off-line "push" command [*1*]; instead
of giving a random commit object, e.g. "git fast-export HEAD~1", that can
not be used as a ref, you can use the refspec notation to tell where the
result should go, e.g. "git fast-export HEAD~1:refs/heads/a-bit-older",
from the command line of fast-export.

I suspect that also may clarify what Sverre was trying to do in his recent
series. The root cause of both this and the issue Sverre wanted to fix is
the design mistake of fast-export that tries to reuse the notation of
object range specification for a different purpose of telling which "ref"
to update, I think.

[Footnote]

*1* In a similar sense, unpacking "git bundle" output is an off-line
"fetch"; the bundle creator gave anchor points for tip objects, and allows
the unpacker to map them into its own namespace.