From: Junio C Hamano <hidden> Date: 2017-08-19 16:37:07
Jeffrey Walton [off-list ref] writes:
Is it possible to fix the issue shown below?
I'm on a test machine. All I do is update to the latest code, build
the library and run the self tests.
The test user account does not have a name and does not have an email
address. There's nothing to provide.
There's no reason to break my workflows for useless Git policies like
"please tell me your email address". Its not my policy, and there's
nothing critical about it.
Jeff
**********
$ git pull
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'test@via.(none)')
On Sat, Aug 19, 2017 at 12:36 PM, Junio C Hamano [off-list ref] wrote:
Jeffrey Walton [off-list ref] writes:
quoted
Is it possible to fix the issue shown below?
I'm on a test machine. All I do is update to the latest code, build
the library and run the self tests.
The test user account does not have a name and does not have an email
address. There's nothing to provide.
There's no reason to break my workflows for useless Git policies like
"please tell me your email address". Its not my policy, and there's
nothing critical about it.
...
Why you can't just set username as name and username@hostname as mail?
You'll do it once and it will be preserved for future. If you use
various accounts for testing, use --system flag for config to store
the values in /etc. If you don't want to modify the environment, use
--local (or no flag) to preserve name in your cloned repository only.
--
| ← Ceci n'est pas une pipe
Patryk Obara
Its 2017. I'd like the tools to work for me instead of me working for the tools.
Ironically, Git used to behave as you requested in 2005. After being
bombarded with complaints about how Git was too lax in creating commits
with bogus ident information, we changed it in 2012. So I don't think
"it's 2017" carries any weight as an argument.
There are numerous discussions in the archive on this. But my
recollection is that the conclusion is:
- stricter ident checking on balance saves more headaches than it
causes, just in terms of numbers
- the headaches solved by stricter checking are hard to fix (because
you unknowingly bake cruft into commit objects, and fixing that
requires a history rewrite)
- the headaches caused by stricter checking are easy to fix (they're
obvious when they happen, and "git -c" lets you provide a dummy
value to override).
We can revisit any of those conclusions, but I'd want to see a
thoughtful discussion of the tradeoffs raised in past rounds, not just
"the current behavior is inconvenient for me".
-Peff
On Sun, 2017-08-20 at 05:18 -0400, Jeff King wrote:
Ironically, Git used to behave as you requested in 2005. After being
bombarded with complaints about how Git was too lax in creating commits
with bogus ident information, we changed it in 2012. So I don't think
"it's 2017" carries any weight as an argument.
I would like to go with the "don't create commits with bogus
ident". "bogus idents" seem to go against the notion of a "content
tracker" which should *help* identifying the user who was the reason
behind the change. It shoudln't encourage users to create "anonymous
changes". Thus an "anonymous user" seems to completely obscure the
meaning of a "content tracker", at least in my opinion
Moreover, there's no tool that can satisfy *all* of it's users because
Humans are so diverse in their thoughts and behaviour.
--
Kaartic
Its 2017. I'd like the tools to work for me instead of me working for the tools.
Ironically, Git used to behave as you requested in 2005. After being
bombarded with complaints about how Git was too lax in creating commits
with bogus ident information, we changed it in 2012.
Maybe I am missing something obvious, but if that's the case then
can't we just do the identity check when trying to make new commits,
in which case you should be able to pull without setting your
identity?
Regards,
Andrew Ardill
Hi Andrew,
On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill [off-list ref] wrote:
Maybe I am missing something obvious, but if that's the case then
can't we just do the identity check when trying to make new commits,
in which case you should be able to pull without setting your
identity?
`git pull` is `git fetch + git merge / git rebase` in disguise, so we
should be ready if git will want to create a merge commit or do a
rebase automatically (and potentially create new commits with
`Committer` set to the current user). `git fetch` and `git clone`
alone, `git branch`, `git checkout` etc don't care about the email (as
of 2.14.1), even if `user.useConfigOnly` is set to `true`.
--
Mit freundlichen Grüßen,
Anatolii Borodin
From: Andrew Ardill <hidden> Date: 2017-08-20 23:33:10
Hi Anatoli,
On 21 August 2017 at 07:57, Anatolii Borodin [off-list ref] wrote:
On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill [off-list ref] wrote:
quoted
Maybe I am missing something obvious, but if that's the case then
can't we just do the identity check when trying to make new commits,
in which case you should be able to pull without setting your
identity?
`git pull` is `git fetch + git merge / git rebase` in disguise, so we
should be ready if git will want to create a merge commit or do a
rebase automatically (and potentially create new commits with
`Committer` set to the current user). `git fetch` and `git clone`
alone, `git branch`, `git checkout` etc don't care about the email (as
of 2.14.1), even if `user.useConfigOnly` is set to `true`.
Is there any reason `git pull` can't delay that check until the point
where it actually tries to create a new commit? It's fair enough to
error if a new commit needs to be made, and there is no user
configured, but for the use cases discussed here it seems a little
eager to error on the chance that the user will be needed.
It seems nicer for the user if the `git fetch` happens first, and if
the merge is not a fast forward, and there is no user configured, that
the error pops then. I don't know if this idea of "do as much as
possible before erroring" is consistent with any other errors we
handle.
Regards,
Andrew Ardill