Re: [PATCH 0/3] Support config-based names

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 12, 2007, 03:31 UTC
Message-ID: <20070612033134.GS6073@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0706112244210.5848@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:

> It can be useful to refer to commits in remotes based on their configured 
> relationship to local branches. For example, "git log HEAD^[push]..HEAD" 
> would, when pushing is set up, show what hasn't been pushed yet.

Interesting.

What about `git diff master^[push]@{3.days.ago}^{tree} master` ?

Can anyone even understand that? Can Git even understand it? As I follow your code I don't think it would, as the ^[push] operator seems like it needs to be on the very end of the string, and it assumes everything to the left of the ^[ is the branch name. So I also couldn't phrase that as:

  git diff master@{3.days.ago}^[push]^{tree} master

More interesting is just what do you want going on here with the reflog query and the ^[push] query. Should the reflog operator apply before the ^[push] translation, or after? Or should it depend on the order of them in the statement? I can see where you would want to look at your local tracking branch for the current branch 3 days ago, which might be "HEAD^[push]@{3.days.ago}". But I'm not really sure what the meaning of "HEAD@{3.days.ago}^[push]" is. Is that the branch that HEAD was on 3 days ago's push branch? Huh? ;-)

Food for thought.

In general it seems our "operators" are ^{foo} or @{foo}, so I wonder why not ^{push}. push is not a valid object type, and probably never will be, so peeling the onion back to get to what ^{push} means (even though its not an object type) is probably OK.

-- 
Shawn.