[PATCH 0/3] Support config-based names

[PATCH 0/3] Support config-based names

[Daniel Barkalow]

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*

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

[Shawn O. Pearce]

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.

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

[Daniel Barkalow]

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

> 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.

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*

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> 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.

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

[Daniel Barkalow]

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

> Daniel Barkalow <barkalow@iabervon.org> 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.

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*

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Mon, 11 Jun 2007, Junio C Hamano wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> 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.

I would agree that I'd worry about that; we will eventually want
some sort of function that is user customizable from command
line, in the same sense as "@{any date specifier}" but possibly
stronger.  And at that point, even [] would get in the way of
that scriptable part.  I'd prefer to provide a set of well
defined and usable "atoms" and let the people script with them.

>> 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.

First, I think 'push' is a misnomer for that purpose, as your
widely popular "pretend we immediately fetched back" topic made
remote tracking branches, which were originally associated more
strongly to 'fetch', associated equally well to 'push'.  You are
comparing what the remote counterpart of your current branch has
(or supposed to have) with what you built.  So I would have
called it 'remote'.

Second, more importantly, that functionality to do log or diff
would go to post commit hook script, and you shouldn't have to
have such a built-in "function" and new syntax to implement
that.  I think more generally useful would be a change to "git
remote" to teach what "git-parse-remote" historically has done,
so that scripts can ask things like:

 - what is the symbolic name of the remote associated with my
   current branch (i.e. branch.$current.remote)?

 - what is the url of the remote given its symbolic name
   (i.e. remote.$remote.url and URL: in .git/remotes/$remote)?

 - what branch at the remote would my current branch pushed to
   (i.e. $current mapped through remote.$remote.push and Push: in
   .git/remotes/$remote)?

 - what remote tracking branch I am using to track that branch
   (i.e. that remote branch mapped through remote.$remote.fetch
   and Pull: in .git/remotes/$remote)?

 - what remote branch do I usually merge into my current branch
   (i.e. branch.$current.merge or the "first refspec listed"
   fallback)?

and combinations of the above.  I would even prefer the
"combinations" to be performed by callers of "git remote", iow,
in your hook script, not as myriad of "git remote" options.

> I didn't have a particular need for ^{merge}, but I accidentally wrote it 
> first because I was confused as to what I wanted.

The last question above is there for completeness.  I think it
would also be a good thing to give to the user.

In other words, I think the questions I listed above are "atoms"
at more appropriate granularity to build flexible tools out of
in order to fit people's different workflow, and I think it is
way premature to embed only a selected-few combinations of them
into syntax sha1_name.c understands.