On Mon, 11 Jun 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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*
-
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
