Re: Creating remote branch called HEAD corrupts remote clones

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 20, 2011 at 01:43:17PM -0800, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The
> > HEAD thing is the most likely, of course, but I could do something like:
> >
> >   git symbolic-ref refs/remotes/origin/convenient-alias \
> >                    refs/remotes/origin/some-name-you-dont-like
> 
> Isn't it already wrong to do the above locally, in the sense that it is
> equally wrong to do this?

Probably. My argument in favor would be "that is what we are doing with
remotes/*/HEAD", but I think the logic is somewhat circular there.

Thinking on it more, yeah, if you want "convenient-alias", you are
probably better off to do:

  git symbolic-ref refs/convenient-alias refs/remotes/origin/whatever

>     git update-ref refs/remotes/origin/no-such-thing-exists-over-there 
>     	refs/heads/master

Actually, don't we end up with that in the case of upstream deleting a
ref? Which isn't to say it isn't a stupid thing to do, but that we can
and do get into that state.

Thinking on it even more, I don't think we can cover all of the weird
"you have a ref named $foo and they suddenly created a ref named $foo"
push corner cases. There is no substitution for actual communication and
organization of ref names if you are going to be pushing along with
other people into a central repo. Because fundamentally the ref name is
the unique identifier, and matching refs during push tries to reconcile
matches based on those identifiers.

> I personally like this line of thought, especially as a thought experiment
> to see what corner cases we could find, but I doubt I will be able to say
> we covered all the corner cases with confidence without thinking long and
> very hard.  For now, I do not find this issue worth spending that kind of
> deep thinking, especially when a lot simpler and easier to explain
> workaround is available, but others may disagree and perfect your idea.

Yeah, after reading your response and considering a bit, I think the
simple "don't make HEAD" thing (or at least "don't pull or push HEAD")
is a sane workaround.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]