Another use of "@"?

Another use of "@"?

[Duy Nguyen]

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

Re: Another use of "@"?

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> 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

Perhaps

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

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

Re: Another use of "@"?

[Junio C Hamano]

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

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> 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
>
> Perhaps
>
>     git checkout long-bra<TAB>
>     git diff A/!$
>     git reset --hard !$
>
> In any case, not a Git question, I would have to say.

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?

Re: Another use of "@"?

[Duy Nguyen]

On Fri, May 3, 2013 at 4:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> 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
>>
>> Perhaps
>>
>>     git checkout long-bra<TAB>
>>     git diff A/!$
>>     git reset --hard !$

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

>> In any case, not a Git question, I would have to say.
>
> 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?

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

Re: Another use of "@"?

[Thomas Rast]

Duy Nguyen <pclouds@gmail.com> writes:

> On Fri, May 3, 2013 at 4:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Duy Nguyen <pclouds@gmail.com> writes:
>>>
>>>> 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
>>>
>>> Perhaps
>>>
>>>     git checkout long-bra<TAB>
>>>     git diff A/!$
>>>     git reset --hard !$
>
> "diff" does not have to follow "checkout".

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

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Another use of "@"?

[Matthieu Moy]

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

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> 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
>
> Perhaps
>
>     git checkout long-bra<TAB>
>     git diff A/!$
>     git reset --hard !$

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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Another use of "@"?

[Duy Nguyen]

On Sat, May 4, 2013 at 5:09 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 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)).

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

Re: Another use of "@"?

[Duy Nguyen]

On Sat, May 4, 2013 at 10:26 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, May 4, 2013 at 5:09 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> 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)).
>
> 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.

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

Re: Another use of "@"?

[Felipe Contreras]

On Thu, May 2, 2013 at 9:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> 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/@

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

-- 
Felipe Contreras

Re: Another use of "@"?

[Ramkumar Ramachandra]

[joining the discussion late; was travelling]

Duy Nguyen wrote:
> git co long-branch-name
> git diff A/@
> git reset --hard A/@

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.

Re: Another use of "@"?

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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

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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/