Re: git-bundle rev handling and de-duping

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2014, 22:41 UTC
Message-ID: <xmqq1tq6s4j1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <ECD50FDF3714423E99E6CC6B4DE04FBF@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 11 quoted lines

>>  # two branches point at the same object
>>  git branch foo master
>>
>>  # the other side already has master. Let's send them foo.
>>  # this will fail because the bundle is empty. That's mildly
>>  # annoying because we really want to tell them "hey, update
>>  # your foo branch". But at least we get an error.
>>  git bundle create tmp.bundle foo ^master
>
> Isn't this kindof what happens as an issue when we want the right HEAD
> to be included explicitly in a bundle. Though

What we are discussing here is "we tell from the command line where the histories end, but do we correctly record all these end points as fetchable refs in the resulting bundle?"

It does not have anything to do with "bundle that does not record its HEAD cannot be cloned", which happens when you do not mention HEAD when creating the bundle in the first place, which is a totally different thing.

> http://thread.gmane.org/gmane.comp.version-control.git/234053 suggests
> its more complicated than that.

The main topic of discussion does not have much to what bundle records and what a reader of a bundle guesses. It is about what goes on the wire and mention of bundle was just a tangent brought up by those who do not know what was being discussed, I think.

I think the right fix to the "git bundle" issue is to make it easier on the "git bundle create" side to have the resulting bundle record its HEAD, even when the user did not mention HEAD on the command line. For example, when there is only one end point, e.g. "git bundle create x next", record refs/heads/next _and_ HEAD pointing at the same commit, because there is no other seneible choice.

"git bundle create y master next" may record master, next and HEAD while HEAD is likely pointing at the same commit as master (because 'master' is special). Or we could give a warning and even go interactive to ask which ref to record as HEAD.

But the above three paragraphs are tangent so I'd stop here.