Git development
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Daniele Segato <daniele.bilug@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Git shouldn't allow to push a new branch called HEAD
Date: Mon, 14 Nov 2011 11:45:46 +0100	[thread overview]
Message-ID: <4EC0F15A.9010502@alum.mit.edu> (raw)
In-Reply-To: <1321261662.2941.13.camel@mastroc3.mobc3.local>

On 11/14/2011 10:07 AM, Daniele Segato wrote:
> On Fri, 2011-10-14 at 13:35 +0200, Daniele Segato wrote:
>> On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
>>> following from a discussion in IRC freenode #git between me, sitaram an
>>> shruggar
>>>
>>>
>>> step to reproduce:
>>>
>>> $ mkdir /tmp/gitbug
>>> $ cd /tmp/gitbug/
>>>
>>> $ # create a fake remote repo
>>> $ git init --bare remote.git
>>>
>>> $ # clone it with the user that will generate the bug
>>> $ git clone remote.git buggenerator
>>> $ cd buggenerator/
>>> $ touch whatever
>>> $ git add .
>>> $ git commit -m "first commit"
>>> $ git push origin master 
>>>
>>> $ # now clone the same repo the other guy is the "victim" of this issue
>>> $ cd ..
>>> $ git clone remote.git victim
>>>
>>> $ # time to create the remote HEAD branch
>>> $ cd buggenerator/
>>> $ git push origin HEAD:HEAD
>>>
>>> $ # the remote refs has been created!
>>> $ git ls-remote
>>>
>>> $ # another commit
>>> $ echo 'any change' >> whatever 
>>> $ git commit -a -m "some change"
>>> $ git push origin master 
>>>
>>> $ # the refs/heads/HEAD is still where it was
>>> $ git ls-remote
>>>
>>> $ # now from the victim perspective
>>> $ cd ../victim/
>>>
>>> $ # every time executing a fetch he will get a force update
>>> $ # or maybe even an error, seen it my real repo, don't know how
>>> $ # to reproduce
>>> $ git fetch 
>>> $ git fetch 
>>> $ git ls-remote
>>> $ git fetch 
>>> $ git ls-remote
>>> $ git branch -a
>>
>> This should also help understanding what happen in the "victim" local
>> repo at every fetch:
>>
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
>> * master                11d0a12 [behind 1] first commit
>>   remotes/origin/HEAD   -> origin/master
>>   remotes/origin/master 77852ef some change
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git fetch 
>> From /tmp/gitbug/remote
>>  + 77852ef...11d0a12 HEAD       -> origin/HEAD  (forced update)
>> mastro@mastroc3 /tmp/gitbug/victim (master) $ git br -av
>> * master                11d0a12 first commit
>>   remotes/origin/HEAD   -> origin/master
>>   remotes/origin/master 11d0a12 first commit
> 
> I'm aware my request has been ignored for a good reason but I would
> appreciate someone stepping in and explaining to me why this is not a
> bug or why it has been ignored.

This is a nice little bug.

I'm sure that you noticed that running "git fetch" repeatedly from the
"victim" repository alternates between two behaviors (I'm using 1.7.7.2):

> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
>  + 6bf3df1...4c9ebba HEAD       -> origin/HEAD  (forced update)
> $ git for-each-ref
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit	refs/heads/master
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit	refs/remotes/origin/HEAD
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit	refs/remotes/origin/master
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
>    4c9ebba..6bf3df1  master     -> origin/master
> $ git for-each-ref
> 4c9ebba3c0618bd6238a810013da4a8cd4f2213b commit	refs/heads/master
> 6bf3df178cd92ca72625ae5bda9206c4333fd807 commit	refs/remotes/origin/HEAD
> 6bf3df178cd92ca72625ae5bda9206c4333fd807 commit	refs/remotes/origin/master
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
>  + 6bf3df1...4c9ebba HEAD       -> origin/HEAD  (forced update)
> $ git fetch
> From /home/mhagger/tmp/gitbug/remote
>    4c9ebba..6bf3df1  master     -> origin/master

The whole time, victim's .git/HEAD contains "ref: refs/heads/master",
.git/refs/remotes/origin/HEAD contains "ref:
refs/remotes/origin/master", and its packed-refs file contains

# pack-refs with: peeled
4c9ebba3c0618bd6238a810013da4a8cd4f2213b refs/remotes/origin/master

In "remote.git", refs/heads/HEAD contains not a symbolic reference but
the explicit SHA1 "4c9ebba...".  This is of course not affected by
running "git fetch" in the "victim" tree.  Deleting this file makes the
problem go away.


Given that this problem seems to be in the remote protocol rather than
in the refs API, I think I'll stop working on this.  I hope that my
observations are helpful to somebody.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2011-11-14 10:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-14 11:31 Git shouldn't allow to push a new branch called HEAD Daniele Segato
2011-10-14 11:35 ` Daniele Segato
2011-11-14  9:07   ` Daniele Segato
2011-11-14 10:45     ` Michael Haggerty [this message]
2011-11-14 11:16       ` Jeff King
2011-11-14 20:22         ` Junio C Hamano
2011-11-14 20:26           ` Jeff King
2011-10-14 23:00 ` P Rouleau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC0F15A.9010502@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=daniele.bilug@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox