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
related.
>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html