On 2011-09-26 21:04, Junio C Hamano wrote:
> Benny Halevy <benny@xxxxxxxxxx> writes:
>
>> From: Benny Halevy <bhalevy@xxxxxxxxxx>
>>
>> Otherwise, with two remotes: test, test-2
>> git remote rename test test-
>> ends up with:
>> .git/refs/remotes/test-
>> .git/refs/remotes/test--2
>> ...
>> diff --git a/builtin/remote.c b/builtin/remote.c
>> index f2a9c26..5443e71 100644
>> --- a/builtin/remote.c
>> +++ b/builtin/remote.c
>> @@ -571,7 +571,7 @@ static int read_remote_branches(const char *refname,
>> const char *symref;
>>
>> strbuf_addf(&buf, "refs/remotes/%s", rename->old);
>> - if (!prefixcmp(refname, buf.buf)) {
>> + if (!strcmp(refname, buf.buf)) {
>
> At this point of the code, refname has "refs/remotes/test/foo" and it is
> queued to later rename it to "refs/remotes/test-/foo" (the next invocation
> of this function will see "refs/remotes/test/bar" in refname). And the
> strbuf buf.buf has "refs/remotes/test"; your !strcmp(refname, buf.buf)
> would never trigger, I suspect.
>
> Isn't 60e5eee (remote: "rename o foo" should not rename ref "origin/bar",
> 2011-09-01) the correct fix for this issue? It makes buf.buf properly
> terminated with a slash, to contain "refs/remotes/test/" so that prefixcmp
> properly matches it with "refs/remotes/test/foo" but not with refs under
> other hierarchies like "refs/remotes/test-2/anything".
OK, 60e5eee solves the problem too.
I wasn't aware of it as I was looking at the master branch.
FWIW, here's the test I used:
#!/bin/sh
git=git
cwd=$(pwd)
function fail ()
{
echo $0: $*
exit 1
}
for i in main test test-2; do
mkdir $i || fail $i exists;
$git init $i || fail git init $i failed
echo $i > $i/foo
( cd $i; git add foo; git commit -m $i )
done
cd main || fail cd main failed
for i in test test-2; do
$git remote add $i file://$cwd/$i || fail git remote add $i failed
done
$git remote update || fail git remote update fail
$git remote rename test test-
$git show test-2/master || fail FAILED
echo PASSED
>
> Thanks.
--
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