Re: git-bundle rev handling and de-duping

"Philip Oakley" [off-list ref] writes:

quoted

 # 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.