Jeff King [off-list ref] writes:
quoted
The way for the Porcelain scripts to mimick the internal "last one
wins" has been to grab values out of --get-all and do the "last one
wins" themselves, and I agree that a mode that frees them from
having to worry about it is a good *addition*. I would even say
that if we were designing "git config" plumbing without existing
users, it would be the only sensible behaviour for "--get".
But "git config --get" users have been promised to get errors on
duplicate values so far, so I have to say this needs to come with a
big red sign about API breakage.
The problem is that scripts currently using "--get" are broken by
duplicate entries in include files, whereas internal git handles them
just fine. Introducing a new switch means that everybody also has to
start using it.
Not exactly. There are three classes of people:
- wrote scripts using --get; found out that --get barfs if you feed
two or more of the same, and have long learned to accept it as a
limitation and adjusted their configuration files to avoid it.
They have been doing just fine and wouldn't benefit from this
series at all.
- wrote scripts using --get, relying on it barfing if fed zero
(i.e. missing) or two or more (i.e. ambiguous), perhaps a way to
keep their configuration files (arguably unnecessarily) clean.
They are directly harmed by this series.
- wrote scripts using --get-all and did the last-one-wins
themselves. They wouldn't benefit directly from this series,
unless they are willing to spend a bit of time to remove their
own last-one-wins logic and replace --get-all with --get (but the
same effort is needed to migrate to --get-one).
- wanted to write scripts using --get, but after finding out that
it barfs if you feed two, gave up emulating the internal, without
realizing that they could do so with --get-all. They can now
write their scripts without using --get-all.
The only people who benefit are from the last class; it does not
matter if they have to write --get-one or --get.
That is not an excuse for breakage, of course, but only a motivation for
considering it. And here is what I think mitigates that breakage:
1. If you are a script that cares about multiple values and choosing
one (whether last-one-wins or otherwise), you are already using
--get-all and are not affected.
Correct.
2. If you are a script that only wants to mimic how get retrieves
a single value, then this is a bug fix, as it brings "--get" in
line with git's internal use.
But by definition, no such script exists (if it used "--get", it
didn't mimic the internal in the first place).
3. If you are a script that only wants a single value, but cares about
duplicates, you are already failing to notice them when the
duplicates are cross-file. That is, we already do "last one wins"
if an entry is found in ~/.gitconfig and .git/config.
Yeah, so the only ones that can be harmed is a config lint that uses
the --get option with --file to make sure variables they know must
be single value are indeed so, and they are not doing a thorough
job, unless they are checking across files themselves, at which
point they are better off using --get-all piped to "sort | uniq -c"
or something. So breakages do not matter much for correctly written
scripts.
I would argue that anybody fetching standard git config variables (and
not using --list or --get-all) falls into case (2) and is being fixed,
as they will not otherwise match the behavior of git itself.
As people shove random stuff that git itself does not care about in
their config files, they may not care, though.
IOW, I do not see a legitimate use case for this, but see it as an extra
check on broken config.
Yes, I agree with the latter half of that sentence.
On Wed, Nov 21, 2012 at 11:46:33AM -0800, Junio C Hamano wrote:
quoted
The problem is that scripts currently using "--get" are broken by
duplicate entries in include files, whereas internal git handles them
just fine. Introducing a new switch means that everybody also has to
start using it.
Not exactly. There are three classes of people:
- wrote scripts using --get; found out that --get barfs if you feed
two or more of the same, and have long learned to accept it as a
limitation and adjusted their configuration files to avoid it.
They have been doing just fine and wouldn't benefit from this
series at all.
- wrote scripts using --get, relying on it barfing if fed zero
(i.e. missing) or two or more (i.e. ambiguous), perhaps a way to
keep their configuration files (arguably unnecessarily) clean.
They are directly harmed by this series.
- wrote scripts using --get-all and did the last-one-wins
themselves. They wouldn't benefit directly from this series,
unless they are willing to spend a bit of time to remove their
own last-one-wins logic and replace --get-all with --get (but the
same effort is needed to migrate to --get-one).
- wanted to write scripts using --get, but after finding out that
it barfs if you feed two, gave up emulating the internal, without
realizing that they could do so with --get-all. They can now
write their scripts without using --get-all.
I have a feeling that your cases 2 and 4 do not really exist. Because we
did "last one wins" in the case that it mattered (between different
files), it was always "good enough" to just assume that using "--get"
behaved like git did internally, and nobody really noticed or cared that
we did duplicate detection at all. But that is just from my own
perspective; it is not like I did a complete survey of git-config users.
More compelling to me is that the only ones negatively affected are your
case 2, and that is qualified by the "arguably unnecessary" you wrote.
Everyone else is not negatively impacted, and can later move to using
"--get" if they want to give up any home-grown --get-all code.
quoted
2. If you are a script that only wants to mimic how get retrieves
a single value, then this is a bug fix, as it brings "--get" in
line with git's internal use.
But by definition, no such script exists (if it used "--get", it
didn't mimic the internal in the first place).
They do not exist if we assume that anyone using "--get" carefully
thought about the distinction. But I have the impression that is not the
case, and that they _meant_ to behave just like git, and did not realize
they were not doing so. Even our own scripts are guilty of this.
Yeah, so the only ones that can be harmed is a config lint that uses
the --get option with --file to make sure variables they know must
be single value are indeed so, and they are not doing a thorough
job, unless they are checking across files themselves, at which
point they are better off using --get-all piped to "sort | uniq -c"
or something. So breakages do not matter much for correctly written
scripts.
Right.
quoted
IOW, I do not see a legitimate use case for this, but see it as an extra
check on broken config.
Yes, I agree with the latter half of that sentence.
So what do we want to do?
-Peff
Junio C Hamano wrote:
Jeff King [off-list ref] writes:
...
Not exactly. There are three classes of people:
- wrote scripts using --get; found out that --get barfs if you feed
two or more of the same, and have long learned to accept it as a
limitation and adjusted their configuration files to avoid it.
They have been doing just fine and wouldn't benefit from this
series at all.
- wrote scripts using --get, relying on it barfing if fed zero
(i.e. missing) or two or more (i.e. ambiguous), perhaps a way to
keep their configuration files (arguably unnecessarily) clean.
They are directly harmed by this series.
- wrote scripts using --get-all and did the last-one-wins
themselves. They wouldn't benefit directly from this series,
unless they are willing to spend a bit of time to remove their
own last-one-wins logic and replace --get-all with --get (but the
same effort is needed to migrate to --get-one).
- wanted to write scripts using --get, but after finding out that
it barfs if you feed two, gave up emulating the internal, without
realizing that they could do so with --get-all. They can now
write their scripts without using --get-all.
There are three classes ofpeople: those that can count and those that can't
Sorry could not resist ;-)