Re: Re* [PATCH] doc: glossary: add entry for revision range

Jeff King wrote:

On Mon, May 17, 2021 at 05:30:01AM -0500, Felipe Contreras wrote:

quoted

quoted

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.

quoted

quoted

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

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.

Cheers.

-- 
Felipe Contreras