Felipe Contreras wrote:
> But why? I'm not familiar with branch_get, but my intuition tells me
> you are changing the behavior, and now branch_get() is doing something
> it wasn't intended to do. And for what?

Why is there a commit message?  I've explained what the behavior change is.

> Your rationale is that it fixes the test cases below, but that's not
> reason enough, since there are other ways to fix them, as my patch
> series shows.

For what exactly.  To fix a real bug: H@{u} and @@{u} don't work where
either H or @ are symbolic refs.  I want custom symbolic refs, because
they are useful.  In other words, "HEAD" is not a sacred symbolic ref.

>>         if (ret && ret->remote_name) {
>>                 ret->remote = remote_get(ret->remote_name);
>>                 if (ret->merge_nr) {
>> diff --git a/sha1_name.c b/sha1_name.c
>> index f30e344..c4a3a54 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -1060,7 +1060,7 @@ int interpret_branch_name(const char *name, struct 
>> strbuf *buf)
>>                 return ret - used + len;
>>         }
>> -       cp = strchr(name, '@');
>> +       cp = strstr(name, "@{");
> This might make sense, but it feels totally sneaked in.

Sneaked in?  I have three paragraphs in my commit message.  The first
two explain two related changes, and the third one shows how they are

>>         if (!cp)
>>                 return -1;
>>         tmp_len = upstream_mark(cp, namelen - (cp - name));
> I think these are two patches should be introduced separately, and
> with a reason for them to exist independent of each other.

I cannot justify the remote.c patch without the "@{" change.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to