Re: [PATCH 7/7] sha1_name: implement finding @{push}

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 24, 2013, 18:21 UTC
Message-ID: <CALkWK0mmJE3Q2WU3pmhWdcrxv=jFXb8oVhPCRW+Zc6yLdDmfUg@mail.gmail.com>
In-Reply-To: <7vehcw9s0k.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 11 quoted lines

>>> rev-parse (with an option, maybe) may be a better place for
>>> this.
>>
>> Er, no.  I actually want things like diff @{p}..HEAD.  I want it to be
>> a first-class revision, just like @{u}.
>
> I think Duy's suggestion makes perfect sense; rev-parse already has
> a mechanism to expand @{u} to the full name, so if you are hooking
> into the same codepath as @{u} to implement the "I publish there"
> information, which I think you should, you already should have it
> for free.

*scratches head*

Okay, I'm not understanding this. I've implemented @{push} as a revision, so all callers who know how to get_sha1_basic() will be able to resolve this (including rev-parse). Are you talking about --symbolic-full-name? That just calls dwim_ref(), which calls interpret_branch_name() anyway: except you get a symbolic name instead of the sha1. Why do I have to think about rev-parse specifically in this patch series? rev-parse has no special logic for @{u} either.

The codepath that resolves @{u} is in interpret_branch_name(): it's just a matter of reading branch->merge[0]->dst; it's trivial to determine because read_config() just reads the configuration file and fills in these values when you get_branch(). How do I get "I publish there" information for free? Where is it contained? In fact, it's so complicated to get that information that I had to break my head to even get this far (after mucking around in the transport layer); that's what I'm trying to show in this series. Unless I'm very badly mistaken, it's _impossible_ for any codepath in git to determine where a push will go, except the one activated by invoking the builtin push.

The long-term impact of this series is not just @{push}, but that anyone else in git will be able to determine where a push is supposed to go. Ultimately, it can lead to very heavy optimizations of the transport_push() codepath (which is currently super-convoluted unless I'm missing something).