Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Nov 4, 2009, 21:20 UTC
- Message-ID
- <alpine.LNX.2.00.0911041601170.14365@iabervon.org>
- In-Reply-To
- <1257364098-1685-10-git-send-email-srabbelier@gmail.com>
On Wed, 4 Nov 2009, Sverre Rabbelier wrote:
Show 25 quoted lines
> This way the helper can write to 'refs/remotes/origin/*' instead of > writing to 'refs/heads/*'. > > Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> > --- > > Daniel, does this look good to you? > > Let's assume the following: > * list: only HEAD is a symref (to refs/heads/<branch>), all other > refs are '? refs/heads/<branch>'. > * import: the helper creates branches under refs/remotes/<alias>/* > (since the refspec code is not yet in that would allow > it to create them under refs/<vcs>/<alias>/*) > > Now when updating the refs we do the following: > transport-helper.c:145 "read_ref(posn->name, posn->old_sha1);" > > The value of posn->name looks like "refs/heads/<branch>". So what > does this lookup do? It tries to lookup the new value of the ref > _where it will be created_, this fails of course, since the ref > currently only exists as "refs/remotes/origin/<branch>". So, we > should instead be doing a lookup using posn->peer_ref->name, and > not do a lookup at all if it posn->peer_ref is not set (which > should not occur as we are passed only wanted peer refs).
That's not true for "git pull <url> <branch>"; we do want the remote ref, but it doesn't have a local peer. I think going straight to the refspec command is the right answer.
-Daniel *This .sig left intentionally blank*