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?
-Peff
--
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