Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> I wondered why it doesn't hook into interpret_branch_name(), and instead
>> adds itself to the static substitute_branch_name(); it forbids the use
>> of the syntax from by callers of strbuf_branchname().
>
> I _think_ it was to allow something like
>
> git log -g @{u}
>
> but frankly, this is so long ago, I do not remember, I reconstructed this
> reasoning as being the most likely.
That is not the question I was asking.
If you compare substitute_branch_name() and interpret_branch_name() before
your patch, you will notice that they are _meant_ to do the same thing,
with different external API, only because many callers in sha1_name.c do
not use strbuf to hold their names. The primary API is the latter (which
is extern), and the former (which is static) is merely a helping wrapper
that is internal to sha1_name.c
But with your patch, they suddenly have different semantics, and the
function that implements the primary API doesn't know anything about
this new @{upstream} syntax.
This discrepancy will affect callers of strbuf_branchname(), e.g.
merge_name() in builtin-merge.c that prepares the "Merge branch nitfol of
remote frotz" message, or delete_branches() in builtin-branch.c.
Note that I am not saying "branch -d @{upstream}" should or should not
work (at least not yet---I haven't thought the issues through). But I
wanted to know if this subtle change in the semantics was a deliberate
choice, and if so wanted to see the reason behind it described clearly.
--
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