Ramkumar Ramachandra [off-list ref] writes:
Duy Nguyen wrote:
quoted
Then "show @{p}" should show the tip commit of rr/master, not the ref
name.
Yes, that is correct.
quoted
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.
Junio C Hamano wrote:
quoted
quoted
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).