From: Junio C Hamano <hidden> Date: 2021-05-17 19:26:57
Jeff King [off-list ref] writes:
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.
So I would prefer something more explicit (whether it's "mybranch" or
"end" or "HEAD" or whatever).
Perhaps. Being illustrative for common use case is also important,
so I do not mind teaching "missing endpoint at either side defaults
to HEAD" early.
If "missing" endpoint is disturbing, the description can be fixed to
stress that they are "often but not always" given.
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.
Oh, I'm nobody, too, and so are many others ;-)
The example in Documentation/rev-list-description.txt (which feeds into
the git-log and git-rev-list manpages) uses "origin..HEAD", as well.
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.
-Peff
From: Felipe Contreras <hidden> Date: 2021-05-17 21:05:45
Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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.
So I would prefer something more explicit (whether it's "mybranch" or
"end" or "HEAD" or whatever).
Perhaps. Being illustrative for common use case is also important,
so I do not mind teaching "missing endpoint at either side defaults
to HEAD" early.
A glossary is not a place to teach (anything other than the definition).
It's supposed to contain glosses (brief explanations).
You don't find a complete recipe when you look for the definition of
"recpipe". That information belongs elsewhere.
If "missing" endpoint is disturbing, the description can be fixed to
stress that they are "often but not always" given.
This is unnecessary information.
If we teach that then we also have to teach that the starting point is
not always given either (`..mybranch`). And where does it end? We would
have to teach that `mybranch ^master` is yet another form of a revision
range, and so is -1.
That's what gitrevisions(7) is for.
quoted
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.
Oh, I'm nobody, too, and so are many others ;-)
That depends on the definition of "many". My guess is that it's less
than 1% of users (probably 0.01%), and for me that's not many.
If you google for `git remote "set-head"` there's barely any
information. It's basically all online man pages.
I don't think anyone can argue it's not obscure.
Cheers.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2021-05-18 02:08:48
On Mon, May 17, 2021 at 04:05:41PM -0500, Felipe Contreras wrote:
quoted
quoted
quoted
Nobody uses "origin" (what does that even mean?), [...]
I guess I'm "nobody" then, because I use it all the time.
Oh, I'm nobody, too, and so are many others ;-)
That depends on the definition of "many". My guess is that it's less
than 1% of users (probably 0.01%), and for me that's not many.
If you google for `git remote "set-head"` there's barely any
information. It's basically all online man pages.
Why would people need to use "git remote set-head" most of the time? The
symlink is set up properly by git-clone, and has been for many years.
For most people, using "origin" just works (the exception is people who
"git init" and then "git remote add origin" themselves; since we're
guessing at numbers, I would guess that _that_ population is less than
1% of users).
-Peff
From: Junio C Hamano <hidden> Date: 2021-05-18 02:57:45
Jeff King [off-list ref] writes:
quoted
If you google for `git remote "set-head"` there's barely any
information. It's basically all online man pages.
Why would people need to use "git remote set-head" most of the time?
I somehow thought Felipe wanted to say that there is nothing but
manual pages that mention the command and, "look how useful set-head
subcommand is, here is how you use it" blog posts are not seen
because nobody uses 'remote set-head'.
I do not quesiotn the frequency count of set-head, but I do not
think the lack of mention of set-head leads to the conclusion that
nobody uses "git log origin.."; there is a leap in logic. As you
said below, "origin" is there without need for set-head, so the lack
of enthusiastic advocate for set-head does not mean anything wrt how
people find "origin" useful.
The
symlink is set up properly by git-clone, and has been for many years.
For most people, using "origin" just works (the exception is people who
"git init" and then "git remote add origin" themselves; since we're
guessing at numbers, I would guess that _that_ population is less than
1% of users).
From: Felipe Contreras <hidden> Date: 2021-05-18 05:02:50
Jeff King wrote:
On Mon, May 17, 2021 at 04:05:41PM -0500, Felipe Contreras wrote:
quoted
quoted
quoted
quoted
Nobody uses "origin" (what does that even mean?), [...]
I guess I'm "nobody" then, because I use it all the time.
Oh, I'm nobody, too, and so are many others ;-)
That depends on the definition of "many". My guess is that it's less
than 1% of users (probably 0.01%), and for me that's not many.
If you google for `git remote "set-head"` there's barely any
information. It's basically all online man pages.
Why would people need to use "git remote set-head" most of the time? The
symlink is set up properly by git-clone, and has been for many years.
First instructions from GitHub:
echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:felipec/test.git
git push -u origin main
Second instructions from GitHub:
git remote add origin git@github.com:felipec/test.git
git branch -M main
git push -u origin main
None of these use `git clone`.
Of 31 repositories I work on and have quickly at hand only 8 have
origin/HEAD.
For most people, using "origin" just works (the exception is people who
"git init" and then "git remote add origin" themselves; since we're
guessing at numbers, I would guess that _that_ population is less than
1% of users).
On what do you base that guess?
The GitHub instructions don't use `git clone`. I can gather similar
instructions from other places if you are unconvinced.
I don't think most people set up their repositories as you think they
do.
And even *if* origin/HEAD did work on most repositories (hardly the
case), most people are not going to train their fingers to type `git cmd
$x` when the only $x where the command works is "origin"; they would
rather train their fingers to do $x/master which works on many more
repositories.
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2021-05-18 05:20:08
Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
quoted
If you google for `git remote "set-head"` there's barely any
information. It's basically all online man pages.
Why would people need to use "git remote set-head" most of the time?
I somehow thought Felipe wanted to say that there is nothing but
manual pages that mention the command and, "look how useful set-head
subcommand is, here is how you use it" blog posts are not seen
because nobody uses 'remote set-head'.
I do not quesiotn the frequency count of set-head, but I do not
think the lack of mention of set-head leads to the conclusion that
nobody uses "git log origin.."; there is a leap in logic.
I did not say that is the only evidence to lead to that conclusion.
But it is evidence.
As you said below, "origin" is there without need for set-head,
Only sometimes.
so the lack of enthusiastic advocate for set-head does not mean
anything wrt how people find "origin" useful.
Yes it does. Contrary to popular belief absence of evidence can be
evidence of absence. If I walk around Central Park for half an hour and
I don't see any elephants, that's evidence that there are no elephants
in Central Park at this very moment. It is not *conclusive* evidence,
but it is evidence.
Just because the evidence for $x is not sufficient to prove $x doesn't
mean there is no evidence for $x.
--
Felipe Contreras
Of 31 repositories I work on and have quickly at hand only 8 have
origin/HEAD.
And of 141 repositories I have on my workstation, 137 have origin/HEAD
(and of the 4 without, one does not even have a remote at all, and one
is a git-svn repository).
I don't think that proves anything except that your workflow is
different than mine. But I contend that most people get repositories by
cloning them.
And even *if* origin/HEAD did work on most repositories (hardly the
case), most people are not going to train their fingers to type `git cmd
$x` when the only $x where the command works is "origin"; they would
rather train their fingers to do $x/master which works on many more
repositories.
I guess I'm not most people, because I sure have enjoyed typing the
shorter thing all these years.
Look, I get that you didn't know or care about the "origin/HEAD" feature
until recently. But it's been part of Git for over 15 years, and has
been used as the documentation examples for revision ranges in both
git-rev-list(1) and gitrevisions(7), as well as the user-manual.
I'm perfectly happy to use placeholder ref names in the glossary
documentation, but it's not like the use of "origin" as a name is some
obscure secret.
-Peff
A random github.com link doesn't show anything. The instructions I'm
talking about are the **first** thing the site gives to users.
On the other hand let's see how we get to your link.
1. Click "New"
2. Type "Repository Name"
3. Click "Create repository"
4. Ignore the entire setup page (with the `git remote add` commands)
5. Click on your profile icon
6. Select "Help"
7. Go to the GitHub.com submenu
8. Ignore the Quickstart
8.1. Ignore the Git cheatsheet
8.1.1. Ignore the `git remote add` part of the cheatsheet that
comes before the `git clone` part
9. Ignore Getting started with Git
9.1. Ignore About remote repositories
9.1.1 Ignore the section Creating remote repositories which does
`git remote add` before it mentions `git clone`
9.2. Ignore Managing remote repositories (talks about `git remote
add`)
10. Select Creating, cloning, and archiving repositories
11. Select Cloning a repository
Finally we reach that link.
To reach that link we need to ignore **all** the tips GitHub gives, and
directly click on a sbusbusection called "Cloning a repository", which
is part of a subsection "Creating, cloning, and archiving repositories"
which is part of the section GitHub.com, which is part of the help.
I seriously dobut this is one of the first things any user sees.
Not to mention that every single repository page mentions cloning under
the "Code" button (including the command-line "gh repo clone" if you are
using their recommended tool).
People clone a lot more than they create new repositories.
Depends what you call "people". If you are talking about professional
software developers, then maybe.
But they are not the only users of git.
Do you have any stats?
quoted
Of 31 repositories I work on and have quickly at hand only 8 have
origin/HEAD.
And of 141 repositories I have on my workstation, 137 have origin/HEAD
(and of the 4 without, one does not even have a remote at all, and one
is a git-svn repository).
I don't think that proves anything except that your workflow is
different than mine.
Exactly, and we cannot assume most people follow your workflow. In fact,
I'd say your workflow is probably one of the most atypical in the world.
You know tricks 99.99% of users don't know about, in fact that probably
99% of git.git developers don't know.
It is sufficient to acknowledge that there are different workflows.
quoted
And even *if* origin/HEAD did work on most repositories (hardly the
case), most people are not going to train their fingers to type `git cmd
$x` when the only $x where the command works is "origin"; they would
rather train their fingers to do $x/master which works on many more
repositories.
I guess I'm not most people, because I sure have enjoyed typing the
shorter thing all these years.
You are not part of that subset.
I'm talking about people that do have "origin/HEAD", but *don't* have
any other "$remote/HEAD".
Do you have a HEAD configured for most of your remotes?
Look, I get that you didn't know or care about the "origin/HEAD" feature
until recently. But it's been part of Git for over 15 years, and has
been used as the documentation examples for revision ranges in both
git-rev-list(1) and gitrevisions(7), as well as the user-manual.
The fact that something is part of the documentation doesn't mean it is
well-known.
The `git remote add -m` option has been documented since 2007, and you
yourself didn't know about it. If you google for that you find nothing.
There's only 1. a qustion on Stack Overflow with zero votes, and 2. the
mail I send you about it. That's it.
Do you agree that `git remote add -m` is obscure?
If so, why is it different from origin/HEAD?
I decided to skim through the entire Pro Git book to see if I could find
any instance in which they use this shortcut... I found **zero**.
If a user can read the most well-known book about git that had hundreds
of contributors without finding a single instance of this shortcut...
How common do you really think it is?
In, fact, I found an interesting quote: "The git rerere functionality is
a bit of a hidden feature." If rerere is a "hidden feature" then what
what is origin/HEAD?
I'm perfectly happy to use placeholder ref names in the glossary
documentation, but it's not like the use of "origin" as a name is some
obscure secret.
It's easier to flip the problem around: if origin/HEAD is well-known,
what would we *not* expect to find?
Is there anything that would falsify the premise?
Cheers.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2021-05-18 12:48:00
On Tue, May 18, 2021 at 06:42:00AM -0500, Felipe Contreras wrote:
A random github.com link doesn't show anything. The instructions I'm
talking about are the **first** thing the site gives to users.
I would think the first thing most users see is _somebody else's
repository_, full of commits, that they then clone.
quoted
People clone a lot more than they create new repositories.
Depends what you call "people". If you are talking about professional
software developers, then maybe.
But they are not the only users of git.
Do you have any stats?
On one of GitHub's servers (selected randomly), there were ~300k clones
in the past 24 hours. In the same time period on the same server, there
were 1780 new repos. Even that's overstating it, since some portion of
those are just forks of existing repos (so the user probably either
cloned their fork immediately, or was already working on a clone of the
upstream fork, rather than having run "git init" locally).
quoted
I don't think that proves anything except that your workflow is
different than mine.
Exactly, and we cannot assume most people follow your workflow. In fact,
I'd say your workflow is probably one of the most atypical in the world.
You know tricks 99.99% of users don't know about, in fact that probably
99% of git.git developers don't know.
It is sufficient to acknowledge that there are different workflows.
I'm not making some bizarre claim about workflows. I'm saying that
people commonly use "git clone" to get repositories. That really doesn't
seem controversial.
But you know what, I've wasted enough time on this thread. If you want
to believe that people don't use "git clone", go for it.
-Peff
From: Felipe Contreras <hidden> Date: 2021-05-18 21:10:08
Jeff King wrote:
On Tue, May 18, 2021 at 06:42:00AM -0500, Felipe Contreras wrote:
quoted
A random github.com link doesn't show anything. The instructions I'm
talking about are the **first** thing the site gives to users.
I would think the first thing most users see is _somebody else's
repository_, full of commits, that they then clone.
All the tutorials I've seen start with `git init`. If you want to learn
git starting from a monstrous repository such as Chrome OS is probably
not a good idea.
And yeah, if you assume most users are professional programmers, then
yeah, that's probably true. But that's an assumption.
Many users are students, others are amateur programmers, others might
be using git to track something other than code, like writing a book, or
their dotfiles.
Experts often forget what it is to be a beginner.
quoted
quoted
People clone a lot more than they create new repositories.
Depends what you call "people". If you are talking about professional
software developers, then maybe.
But they are not the only users of git.
Do you have any stats?
On one of GitHub's servers (selected randomly), there were ~300k clones
in the past 24 hours. In the same time period on the same server, there
were 1780 new repos. Even that's overstating it, since some portion of
those are just forks of existing repos (so the user probably either
cloned their fork immediately, or was already working on a clone of the
upstream fork, rather than having run "git init" locally).
How do you distinguish a git clone from a git init + git remote add + git
fetch?
quoted
quoted
I don't think that proves anything except that your workflow is
different than mine.
Exactly, and we cannot assume most people follow your workflow. In fact,
I'd say your workflow is probably one of the most atypical in the world.
You know tricks 99.99% of users don't know about, in fact that probably
99% of git.git developers don't know.
It is sufficient to acknowledge that there are different workflows.
I'm not making some bizarre claim about workflows. I'm saying that
people commonly use "git clone" to get repositories. That really doesn't
seem controversial.
It's not controversial, but it's also not necessarily true.
On what are you basing that claim?
But you know what, I've wasted enough time on this thread. If you want
to believe that people don't use "git clone", go for it.
I'll parse that as an answer to my quesion:
quoted
Is there anything that would falsify the premise?
"No, there's absolutely nothing that would falsify my premise".
If there's no way to falsify a claim, then there is no point in even
entertaining that claim.
Cheers.
--
Felipe Contreras