Another use of "@"?

Hi,

My setup is a bit peculiar where I do git development on three different machines. Say I updated branch long-branch-name on machine A. Then I continue my work on machine B. I would want to hard reset that long-branch-name on machine B before resuming my work. What I usually do is

git co long-branch-name git diff A/long-branch-name git reset --hard A/long-branch-name

but typing long-branch-name (even with TAB completion) is not fun. Could I do this (or something similar) instead?

git co long-branch-name git diff A/@ git reset --hard A/@ -- Duy

Duy Nguyen <pclouds@gmail.com> writes:

Perhaps

    git checkout long-bra<TAB>
    git diff A/!$
    git reset --hard !$

In any case, not a Git question, I would have to say.

Junio C Hamano <gitster@pobox.com> writes:

As a Git question, probably the answers are

	git co long-bra<TAB>
        git diff @{u}
        git reset --hard @{u}

with an appropriate setting of the upstream, perhaps?

On Fri, May 3, 2013 at 4:38 PM, Junio C Hamano <gitster@pobox.com> wrote:

"diff" does not have to follow "checkout".

and @{u} can't be used because I might want to resume from machine C instead of A. I don't have a single upstream. -- Duy

Duy Nguyen <pclouds@gmail.com> writes:

At least in bash with readline, you can also use M-. to cycle through the last arguments of the previous commands.

Junio C Hamano <gitster@pobox.com> writes:

I think Duy meant

  git diff A/$(git symbolic-ref --short HEAD)

i.e. "the branch with the same name as the current one, but on a different remote". If this is the question, then it is a Git thing more than a shell one.

The A/@ could make sense, but I'm wondering whether we're taking the direction of implementing some kind of Brainfuck dialect in Git revision specifiers. I'm not sure we want to add more special characters here and there with subtly different meanings (@ = HEAD, @{1} = HEAD@{1}, A/@ = A/$(git symbolic-ref --short HEAD)).

On Sat, May 4, 2013 at 5:09 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Another subtle overloading of @ that might be desirable (althought might be achievable another way). "git log -g" is equal to "git log -g HEAD" but there is no easy way (that I know of) to do "git log -g $(git symbolic-ref HEAD)". "@" could fill the inconvenient spot here, I think. Alias is no good because I won't be able to add extra options. -- Duy

On Sat, May 4, 2013 at 10:26 AM, Duy Nguyen <pclouds@gmail.com> wrote:

I wouldn't mind typing <ref>@{link} that does "git symbolic-ref <ref>", though. Because ref is optional, "git log -g @{link}" is not bad. "link" is probably not a good name for this. -- Duy

On Thu, May 2, 2013 at 9:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Maybe this would make more sense:

%git co long-branch-name %git reset --keep A/long-branch-name

If you have changes but they don't conflict, they will be carried over, and it they do conflict, the reset won't continue. I think in most cases there will be no conflict, so the times you need to do 'git diff' will be rather small.

Yes, many times I would like an idiom that would just replace something with the current branch, like your A/@, but I don't know where the right place for that would be.

Also, I feel we are missing some kind of branch, like a remote-specific upstream, so instead of 'git reset A/foo' you would do 'git reset A@{u}'. By default the remote-specific upstream would be the same name of the branch, but it could be configured.

Moreover, we should probably have common aliases distributed (e.g. git co).

[joining the discussion late; was travelling]

Duy Nguyen wrote:

In this form, this looks highly inconsistent. You have to decide if you want @ to resolve to the current branch name or HEAD. Our current @-proposal makes @@{1} display the reflog for HEAD for instance. The other problem is that we resolve things like @{-1} to full refs like refs/heads/master. Making a A/@{-1} work makes little or no sense, because that refs/heads needs to be changed to refs/remotes in the first place. What about refs/decapitated/@{-1}? Should we support it?

I tend to agree with Junio here: @{u} is the way forward. We need to define useful reduced consistent semantics; while inventing a mini-language to do all kinds of revision manipulations may be a fun theoretical exercise, it's too much effort for too little gain. We have to learn to work within the limitations of what we've invented so far.

On Matthieu's note, I have a comment: symbolic refs are an absolute dead end. We didn't think of it from the start, and it's too late now. Do NOT go there: from my investigation, I believe that hooking up everything to the revision parser is the way forward.

Ramkumar Ramachandra <artagnon@gmail.com> writes:

My comment was not about the solution, but about the problem (which seemed to have been misunderstood). The question seems to be "get the reference with the same names as what HEAD points to, but on remote A", and the "points to" part is about symbolic references.