All of
 help / color / mirror / Atom feed
From: Felipe Contreras <>
To: Jeff King <>, Felipe Contreras <>
Cc: "Junio C Hamano" <>,, "Nguyễn Thái Ngọc Duy" <>,
	"Richard Hansen" <>
Subject: Re: Re* [PATCH] doc: glossary: add entry for revision range
Date: Mon, 17 May 2021 12:22:56 -0500	[thread overview]
Message-ID: <60a2a670648b1_12801e20895@natae.notmuch> (raw)
In-Reply-To: <>

Jeff King wrote:
> On Mon, May 17, 2021 at 05:30:01AM -0500, Felipe Contreras wrote:
> > > As there is no need to spell out HEAD, `master..` would be a better
> > > example.
> > 
> > I don't think so. The description said _starting_ and _ending_ points...
> > `master..` has no ending point.
> > 
> > If we must not use @, then I would rather use `master..mybranch`, or
> > something like that. HEAD seems like a technical accident. But of course
> > I would prefer HEAD to nothing, because at least it qualifies as an
> > ending point.
> I agree that if the purpose is to be illustrative, using shortcuts like
> "an empty endpoint means HEAD" is not helpful. And likewise for "@"; if
> you need to have "revision range" defined, there is a good chance that
> you don't know about shortcuts like "@" either.

But they don't need to know what @ means; it's clearly a shortcut for
_something_, and that's all they need to know. In fact, I'd say most
people can quickly realize what a shorcut for it is, which is why it was
picked by the git project, and many Mercurial projects as well.

Sure the same argument applies to HEAD too, but if we are going to pick
a placeholder for _something_ the user doesn't need to know about, then
@ is much simpler than HEAD.

We could do X too (typically used for _whatever_), but I'd argue @ is
much better than X because it actually works, and not just works, but
it's what the user most often would use.

> So I would prefer something more explicit (whether it's "mybranch" or
> "end" or "HEAD" or whatever).

I prefer something less explicit, because it's not relevant what X is,
just that it is an end point.

But if you feel strongly about it, "mybranch" it is.

Actually, I would prefer something more real, like "feature-x".

> In a more fleshed-out description it might be nice to casually introduce
> such shortcuts to let the user pick them up naturally, but in a
> one-liner like a glossary entry, I think clarity is the most important
> thing.

Indeed, but I find `master..@` is a perfectly clear example of a
revision range from something to something.

> > > Especially since most people are downstream consumers, I'd
> > > suggest using `origin..` or `@{u}..` here.
> > 
> > Nobody uses "origin" (what does that even mean?), [...]
> I guess I'm "nobody" then, because I use it all the time.

Language is rarely 100% specific. By "nobody" of course I meant
"virtually nobody".

And yeah, I know you actually use "origin", because you do have correct
"origin/HEAD" for many of your repositories. I don't, and I'd argume
most users don't either.

It's right next in my to-do list to work on fetch.updateHead so I (and
many users) can join you in using "origin". But that's not the case

> The example in Documentation/rev-list-description.txt (which feeds into
> the git-log and git-rev-list manpages) uses "origin..HEAD", as well.

I think it shouldn't, but that's a separate topic.

> IMHO it is a pretty reasonable example, but the examples in
> gitrevisions(7) use made up "r1..r2", and that seems perfectly readable,
> as well.

It is readable, sure, but it's not a real example. When picking an
example of English sentence with subject and predicate I'd pick "Mary
went to the moves" over "Subject predicate" in heartbeat.

An instance that doesn't come from the set of real commands is not
really an example to me.


Felipe Contreras

  reply	other threads:[~2021-05-17 17:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 20:37 [PATCH] doc: glossary: add entry for revision range Felipe Contreras
2021-05-17  7:46 ` Re* " Junio C Hamano
2021-05-17 10:30   ` Felipe Contreras
2021-05-17 11:55     ` Jeff King
2021-05-17 17:22       ` Felipe Contreras [this message]
2021-05-18  6:59         ` Jeff King
2021-05-18 12:28           ` Felipe Contreras
2021-05-17 19:26       ` Junio C Hamano
2021-05-17 21:05         ` Felipe Contreras
2021-05-18  0:51           ` Junio C Hamano
2021-05-18  1:26             ` Felipe Contreras
2021-05-18  2:08           ` Jeff King
2021-05-18  2:57             ` Junio C Hamano
2021-05-18  5:20               ` Felipe Contreras
2021-05-18  5:02             ` Felipe Contreras
2021-05-18  6:55               ` Jeff King
2021-05-18 11:42                 ` Felipe Contreras
2021-05-18 12:47                   ` Jeff King
2021-05-18 21:09                     ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60a2a670648b1_12801e20895@natae.notmuch \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.