[PATCH 0/3] Support config-based names

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.

I picked base^[word] as the format for sha1 names which are some arbitrary 
function of base. I think this format isn't used for anything yet, isn't 
valid as ref names, and is structureally suitable for having a variety of 
extensions. I added {branch}^[merge] for the default head to merge into 
{branch} and {branch}^[push] for the tracking ref for the remote branch to 
push {branch} to. The push one could be extended to include the branch to 
push to by default at other remotes as {branch}^[push:{remote}]. I'm not 
too picky about the format for this, if there's something better for the 
space of sha1 names that don't have to be super compact and may have lots 
of options.

(In order to prepare this email, I set up a push default of my branch to 
next, and did: "git log --reverse HEAD^[push]..HEAD" and "git diff --stat 
HEAD^[push]...HEAD")

Patch 1 is likely to be independantly useful for things like a 
builtin-fetch, which needs to get configuration for branches along with 
remotes.

 Patch 1: Parse and report branch config
 Patch 2: Search for matching push refspec in configuration
 Patch 3: Add sha1 names using the preceding functions

 remote.c    |  109 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
 remote.h    |   22 +++++++++++-
 sha1_name.c |   50 +++++++++++++++++++++++++++
 3 files changed, 166 insertions(+), 15 deletions(-)

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow [off-list ref] 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.

On Mon, 11 Jun 2007, Shawn O. Pearce wrote:

Daniel Barkalow [off-list ref] wrote:

quoted

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.

Ah, but the code actually peels off parts and parses the part under, so 
HEAD^[push]^{tree} actually works. However, it doesn't treat HEAD^[push] 
as an alias for a branch, so it doesn't find the reflog.

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?  ;-)

Whatever that means, I bet we don't track the necessary information. I 
think ^[push] only applies to ref names. But it should probably resolve as 
a ref name itself, so that HEAD^[push]@{3.days.ago} would work. Not sure 
how to write the code for that, though.

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.

^{push} and ^{merge} are certainly possible, if the namespace of object 
types and the namespace of functions aren't going to overlap. I wasn't 
sure if this would be true in general with future additions to both 
namespaces.

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow [off-list ref] writes:

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.

It's not like we will be adding 'push' objects and 'merge'
objects, so I think HEAD^{push} (curly brace, not bracket) is
good enough.

We need to see how useful this would be in practice; we would
not want to add new syntax without a set of convincing use
cases.  At this point, it still feels as if it is a feature that
was implemented only because it could, not because there was a
real need.

On Mon, 11 Jun 2007, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

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.

It's not like we will be adding 'push' objects and 'merge'
objects, so I think HEAD^{push} (curly brace, not bracket) is
good enough.

What I'm worried about is whether we'll eventually want some sort of 
function and an object with the same name, and then have to have a syntax 
problem with legacy functions being confusing.

We need to see how useful this would be in practice; we would
not want to add new syntax without a set of convincing use
cases.  At this point, it still feels as if it is a feature that
was implemented only because it could, not because there was a
real need.

I'd be a lot more reliable at using git if git-commit reported "git log 
--pretty=oneline HEAD^{push}..HEAD" after each commit (if there is a 
HEAD^{push}). I'm forever committing things and forgetting to push them 
when I mean to. My original series actually ended with adding something to 
git-commit.sh, but I decided I didn't like the implementation of that 
actual patch.

I didn't have a particular need for ^{merge}, but I accidentally wrote it 
first because I was confused as to what I wanted. I think "git diff 
HEAD^{merge}" might be good for finding out what work you've done that 
hasn't gotten in yet.

Of course, for particular cases, it's just as easy to type the actual 
tracking branch name on the command line, but ^{push} and ^{merge} can be 
used genericly in scripts, because the same common or pattern works for 
any branch.

	-Daniel
*This .sig left intentionally blank*