git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* `@` alias for `HEAD` not working in `git push -u origin @`
@ 2019-07-10  5:06 Mark Florian
  2019-07-10 23:39 ` brian m. carlson
  0 siblings, 1 reply; 7+ messages in thread
From: Mark Florian @ 2019-07-10  5:06 UTC (permalink / raw)
  To: git

Hello!

I learned today that `@` is a shortcut for `HEAD`. From `git help reivisions`:

    @ alone is a shortcut for HEAD.

However, when I tried to use it in a command I frequently use, I got an error:

    $ git push -u origin @
    fatal: invalid refspec '@'

I'm running git version 2.22.0 on Linux.

Is this a bug, or have I misunderstood how this is supposed to work?

Cheers,
Mark

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-10  5:06 `@` alias for `HEAD` not working in `git push -u origin @` Mark Florian
@ 2019-07-10 23:39 ` brian m. carlson
  2019-07-11  9:46   ` Johannes Schindelin
  2019-07-31  5:58   ` Jeff King
  0 siblings, 2 replies; 7+ messages in thread
From: brian m. carlson @ 2019-07-10 23:39 UTC (permalink / raw)
  To: Mark Florian; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On 2019-07-10 at 05:06:08, Mark Florian wrote:
> Hello!
> 
> I learned today that `@` is a shortcut for `HEAD`. From `git help reivisions`:
> 
>     @ alone is a shortcut for HEAD.
> 
> However, when I tried to use it in a command I frequently use, I got an error:
> 
>     $ git push -u origin @
>     fatal: invalid refspec '@'
> 
> I'm running git version 2.22.0 on Linux.
> 
> Is this a bug, or have I misunderstood how this is supposed to work?

This is a bug. If the destination side of a refspec is omitted, and the
source side resolves to a ref starting with "refs/heads/" or
"refs/tags/" (which I expect it does here), then that ref is used as the
destination.

I submitted a patch at [0], but it was decided not to pick it up. If
Junio and the list decide that it's wanted, I'm happy to resend or
revise and resend.

[0] https://public-inbox.org/git/20180729192803.1047050-1-sandals@crustytoothpaste.net/
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-10 23:39 ` brian m. carlson
@ 2019-07-11  9:46   ` Johannes Schindelin
  2019-07-11 14:48     ` brian m. carlson
  2019-07-31  5:58   ` Jeff King
  1 sibling, 1 reply; 7+ messages in thread
From: Johannes Schindelin @ 2019-07-11  9:46 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Mark Florian, git

Hi brian,

On Wed, 10 Jul 2019, brian m. carlson wrote:

> On 2019-07-10 at 05:06:08, Mark Florian wrote:
> >
> > I learned today that `@` is a shortcut for `HEAD`. From `git help reivisions`:
> >
> >     @ alone is a shortcut for HEAD.
> >
> > However, when I tried to use it in a command I frequently use, I got an error:
> >
> >     $ git push -u origin @
> >     fatal: invalid refspec '@'
> >
> > I'm running git version 2.22.0 on Linux.
> >
> > Is this a bug, or have I misunderstood how this is supposed to work?
>
> This is a bug. If the destination side of a refspec is omitted, and the
> source side resolves to a ref starting with "refs/heads/" or
> "refs/tags/" (which I expect it does here), then that ref is used as the
> destination.
>
> I submitted a patch at [0], but it was decided not to pick it up. If
> Junio and the list decide that it's wanted, I'm happy to resend or
> revise and resend.
>
> [0] https://public-inbox.org/git/20180729192803.1047050-1-sandals@crustytoothpaste.net/

After reading that thread, I come to the conclusion that it was not so
much a decision not to pick it up, but more like a falling between the
cracks.

I would be in favor of this patch.

Since I have your attention and since I am interested in a related issue
(when I wanted to propose a GSoC mini project to let `git fetch <remote>
@` expand the `@` to the current (local) branch name, Matthieu Moy
pointed out that `git fetch --current <remote>` might be a better UI):
what does your patch do with `git fetch`'s refspec arguments?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-11  9:46   ` Johannes Schindelin
@ 2019-07-11 14:48     ` brian m. carlson
  2019-07-12 10:29       ` Johannes Schindelin
  0 siblings, 1 reply; 7+ messages in thread
From: brian m. carlson @ 2019-07-11 14:48 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Mark Florian, git

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On 2019-07-11 at 09:46:26, Johannes Schindelin wrote:
> After reading that thread, I come to the conclusion that it was not so
> much a decision not to pick it up, but more like a falling between the
> cracks.
> 
> I would be in favor of this patch.

I think there was some later follow-up in a different thread (one of the
"What's cooking" threads) that expressed reservations about it, but I
can't find that thread right now.

Regardless, if there's interest, I can certainly resend and see how
folks on the list feel about it.

> Since I have your attention and since I am interested in a related issue
> (when I wanted to propose a GSoC mini project to let `git fetch <remote>
> @` expand the `@` to the current (local) branch name, Matthieu Moy
> pointed out that `git fetch --current <remote>` might be a better UI):
> what does your patch do with `git fetch`'s refspec arguments?

I haven't checked. I believe it would resolve "git fetch origin @" to
"git fetch origin HEAD" and "git fetch origin @:refs/heads/master" to
"git fetch origin HEAD:refs/heads/master".

I can add some additional tests for this case, although I'm not
especially sure that it provides useful behavior people will want.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-11 14:48     ` brian m. carlson
@ 2019-07-12 10:29       ` Johannes Schindelin
  0 siblings, 0 replies; 7+ messages in thread
From: Johannes Schindelin @ 2019-07-12 10:29 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Mark Florian, git

Hi brian,

On Thu, 11 Jul 2019, brian m. carlson wrote:

> On 2019-07-11 at 09:46:26, Johannes Schindelin wrote:
>
> > Since I have your attention and since I am interested in a related issue
> > (when I wanted to propose a GSoC mini project to let `git fetch <remote>
> > @` expand the `@` to the current (local) branch name, Matthieu Moy
> > pointed out that `git fetch --current <remote>` might be a better UI):
> > what does your patch do with `git fetch`'s refspec arguments?
>
> I haven't checked. I believe it would resolve "git fetch origin @" to
> "git fetch origin HEAD" and "git fetch origin @:refs/heads/master" to
> "git fetch origin HEAD:refs/heads/master".

That sounds like a sane behavior, as `@` on the "src" side of a refspec
that tries to fetch from a remote repository should probably not expand
to a _local_ branch.

> I can add some additional tests for this case, although I'm not
> especially sure that it provides useful behavior people will want.

Nah, from my side this is not necessary.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-10 23:39 ` brian m. carlson
  2019-07-11  9:46   ` Johannes Schindelin
@ 2019-07-31  5:58   ` Jeff King
  2019-07-31 16:10     ` Junio C Hamano
  1 sibling, 1 reply; 7+ messages in thread
From: Jeff King @ 2019-07-31  5:58 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Mark Florian, git

On Wed, Jul 10, 2019 at 11:39:37PM +0000, brian m. carlson wrote:

> This is a bug. If the destination side of a refspec is omitted, and the
> source side resolves to a ref starting with "refs/heads/" or
> "refs/tags/" (which I expect it does here), then that ref is used as the
> destination.
> 
> I submitted a patch at [0], but it was decided not to pick it up. If
> Junio and the list decide that it's wanted, I'm happy to resend or
> revise and resend.
> 
> [0] https://public-inbox.org/git/20180729192803.1047050-1-sandals@crustytoothpaste.net/

I see I was cc'd on that original, but I don't remember ever reading it.
It seems like a sane enough idea to me.

Although I did notice that you mentioned there:

> I probably type "git push upstream HEAD" from five to thirty times a
> day

I find I do that rarely, because I have:

  [push]
  default = current

and in a triangular workflow, I have:

  [remote]
  pushDefault = upstream

So "git push" without arguments typically does the same thing for me.

Not an argument against your patch, but just something you might find
useful.

-Peff

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: `@` alias for `HEAD` not working in `git push -u origin @`
  2019-07-31  5:58   ` Jeff King
@ 2019-07-31 16:10     ` Junio C Hamano
  0 siblings, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2019-07-31 16:10 UTC (permalink / raw)
  To: brian m. carlson, Jeff King; +Cc: Mark Florian, git

Jeff King <peff@peff.net> writes:

> On Wed, Jul 10, 2019 at 11:39:37PM +0000, brian m. carlson wrote:
>
>> This is a bug. If the destination side of a refspec is omitted, and the
>> source side resolves to a ref starting with "refs/heads/" or
>> "refs/tags/" (which I expect it does here), then that ref is used as the
>> destination.
>> 
>> I submitted a patch at [0], but it was decided not to pick it up. If
>> Junio and the list decide that it's wanted, I'm happy to resend or
>> revise and resend.
>> 
>> [0] https://public-inbox.org/git/20180729192803.1047050-1-sandals@crustytoothpaste.net/
>
> I see I was cc'd on that original, but I don't remember ever reading it.
> It seems like a sane enough idea to me.

I see I was also on the cc list; I am not sure what I thought about
the patch (i.e. implementation, not the desire to use '@' in the
context in place for "HEAD") back then.

Now I read it with everything I thought forgotten, I see two
potential issues:

 - Any error message downstream will mention "HEAD" and there won't
   be a trace of it originally being an "@" sign.  It may not be a
   problem, especially for those who _KNOW_ that they should be
   typing HEAD but can type "@" instead, but I am not sure what to
   do those who do not know much about "HEAD" and start from "@" (by
   the way, it is one reason why I do not like encouraging "@",
   especially in introductory text).

 - The code should update llen to 4; right now the remainder of the
   function does not use the variable in a way that the discrepancy
   of replacing "@" with "HEAD" without updating llen matters, but
   relying on the shape of the code that happens to exist right now
   is a bad code hygiene.

Other than that, the patch looks sensible to me.


> Although I did notice that you mentioned there:
>
>> I probably type "git push upstream HEAD" from five to thirty times a
>> day
>
> I find I do that rarely, because I have:
>
>   [push]
>   default = current
>
> and in a triangular workflow, I have:
>
>   [remote]
>   pushDefault = upstream
>
> So "git push" without arguments typically does the same thing for me.
>
> Not an argument against your patch, but just something you might find
> useful.

That's a helpful tangent.  Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-10  5:06 `@` alias for `HEAD` not working in `git push -u origin @` Mark Florian
2019-07-10 23:39 ` brian m. carlson
2019-07-11  9:46   ` Johannes Schindelin
2019-07-11 14:48     ` brian m. carlson
2019-07-12 10:29       ` Johannes Schindelin
2019-07-31  5:58   ` Jeff King
2019-07-31 16:10     ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox