On Fri, Nov 19, 2010 at 4:15 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Tue, Nov 16, 2010 at 09:29:46PM -0500, Martin von Zweigbergk wrote:
>
>> > What about simply checking if "rev-parse @{u}" succeeds, in which case
>> > we can use upstream_name=@{u} ? ÂIf it fails, then we can do the work
>> > of finding where the config flaw is (and delegate this to a func).
>> > That would help keep the nominal code path short.
>>
>> Will make sure to find out the error only when needed as you suggest.
>>
>> I thought I would need the ref name to be able to walk the reflog if my
>> other propasal would be accepted (see
>> http://thread.gmane.org/gmane.comp.version-control.git/161381), but it
>> seems to work with @{u} as well. I just adapted the call from 'git pull'
>> (git-parse-remote.sh), but I guess I could use 'git rev-parse @{upstream}'
>> instead. It does seem more natural to me.
>>
>> Maybe one of the guys on the CC list can advise?
>
> I'm not quite sure I understand the question, coming into the middle of
> the conversation. If you want to know "can I traverse the reflog of the
> upstream with @{u}", the answer is yes. We dereference the ref first
> (similarly, foo@{u}@{3.days.ago} looks at the upstream branch's reflog).
> If you want the refname, you can also use "git rev-parse
> --symbolic-full-name @{u}".
>
> Does that help?
Yes, I did try that and I noticed that it worked, but it helps to know
that it is not just by accident. I realize I was not very clear, but
what I really was wondering if there is any advantage to using
"git for-each-ref --format='%(upstream)' ${branch_name}" (as used by
git pull) as compared to "git rev-parse @{upstream}" as suggested by
Yann. ($branch_name in this case would be the current branch.)
--
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