On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
Hi all,
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
regards,
Daniele
Hi all,
following from a discussion in IRC freenode #git between me, sitaram an
shruggar
step to reproduce:
$ # time to create the remote HEAD branch
$ cd buggenerator/
$ git push origin HEAD:HEAD
But I think that git shouldn't allow the remote HEAD reference to be
created in the first place
Maybe git should also refuse to create a local branch named HEAD. I made a
mistake recently where I used something likes this:
for B in $(git branch -a|grep "remotes/origin/"); do git co -t $B ; done
After that, git st was giving a warning about an ambiguous HEAD ref. Hopefully,
a simple "git branch -d HEAD" fixed it once I found the problem.
P.Rouleau
On Fri, 2011-10-14 at 13:35 +0200, Daniele Segato wrote:
On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
quoted
Hi all,
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
Hi again,
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.
Thanks.
Regards,
Daniele Segato
From: Michael Haggerty <hidden> Date: 2016-06-15 22:52:28
On 11/14/2011 10:07 AM, Daniele Segato wrote:
On Fri, 2011-10-14 at 13:35 +0200, Daniele Segato wrote:
quoted
On Fri, 2011-10-14 at 13:31 +0200, Daniele Segato wrote:
quoted
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):
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/
From: Jeff King <hidden> Date: 2016-06-15 22:52:28
On Mon, Nov 14, 2011 at 11:45:46AM +0100, Michael Haggerty wrote:
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.
I didn't recreate the test situation and look closely, but my impression
is that this isn't a code bug at all, but rather a design problem in the
way we store remote namespaces. That is, we make "refs/remotes/foo/HEAD"
a symbolic ref with special meaning, but then fetch into it from the
remote's refs/heads namespace, writing remote's HEAD branch into
whatever our HEAD symref points to.
So one solution is to block fetching of remote branches called HEAD
(which I would be OK with). But another is to use a more sensible layout
for representing the remote refs, like:
refs/remotes/origin/HEAD (a symbolic ref)
refs/remotes/origin/heads/master
refs/remotes/origin/tags/v1.0
etc. Then the namespaces are properly separated, and the magic remote
"HEAD" symref is not in the way.
Obviously there's a lot more to it than just tweaking the default fetch
refspecs. The ref lookup rules need to be changed to take this into
account. There was some discussion about this over the summer (under the
subject of possible "1.8.0" changes), but I don't think any work has
been done.
-Peff