Re: default behaviour for `gitmerge` (no arguments)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2010, 09:47 UTC
Message-ID: <7v6376pc9w.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.1001131024420.3043@intel-tinevez-2-302>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

>> 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.