On Tue, 2017-10-03 at 05:10 -0400, Jeff King wrote:
> I dunno. Maybe I am wrong, because certainly I never set it. We've
> had
> two reports on the list since v2.14.2. The motivation for the first
> was
> "I have no idea why I set that, and I'll switch to auto". This is the
> second.
>
I also cam
On Wed, Oct 04, 2017 at 11:59:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Here's what I came up with on the "color.ui=always is nonsense that we
> > should not offer" front. The number of patches may be a little daunting,
> > but most of them are just removing cases of "git -c co
Jeff King writes:
> Here's what I came up with on the "color.ui=always is nonsense that we
> should not offer" front. The number of patches may be a little daunting,
> but most of them are just removing cases of "git -c color.ui=always"
> from the tests.
>
> [01/12]: test-terminal: set TERM=vt1
On Tue, Oct 03, 2017 at 07:38:24PM +0900, Junio C Hamano wrote:
> That's an argument to say color.ui=always is not a useful thing to
> use and Git is wrong to offer such a nonsense option. I agree with
> both of them.
>
> But it is a different matter that plumbing commands are now doing
> the "c
Jeff King writes:
> On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Note that I'm arguing that it's a foot-gun even without scripts in the
>> > picture at all. Forget about plumbing versus porcelain. If you set
>> > color.ui to "always", you're goi
On Tue, Oct 03, 2017 at 02:15:15AM -0400, Jeff King wrote:
> The two reasonable paths forward to me are:
>
> 1. Do nothing. Putting "color.ui = always" in your on-disk config is a
> bad idea, and the right fix is to stop doing it.
>
> 2. Make "always" a synonym for "auto". This has the
I also don't remember why I set it, and as such I removed it.
A helpful hint as to a bad config option would've been great.
Something along the lines of "The use of color.ui = always is not
recommended", with a flag allowing you to disable said warning.
Thanks,
Tsvi
Tsvi Mostovicz
ttm...@gmail.c
On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Note that I'm arguing that it's a foot-gun even without scripts in the
> > picture at all. Forget about plumbing versus porcelain. If you set
> > color.ui to "always", you're going to get unexpected and con
Jeff King writes:
> Note that I'm arguing that it's a foot-gun even without scripts in the
> picture at all. Forget about plumbing versus porcelain. If you set
> color.ui to "always", you're going to get unexpected and confusing
> results from time to time.
Really?
I would think you would cons
On Tue, Oct 03, 2017 at 05:34:40PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I agree it's not quite the same thing, and I agree the problem was made
> > much worse by 4c7f1819b. But I still think color.ui=always is
> > inherently a foot-gun, and in either case it is the user that s
Jeff King writes:
> I agree it's not quite the same thing, and I agree the problem was made
> much worse by 4c7f1819b. But I still think color.ui=always is
> inherently a foot-gun, and in either case it is the user that sets it
> that is harmed (and they are the ones who have the power to fix it
On Tue, Oct 03, 2017 at 04:10:12PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'd prefer not to revert. I think setting any of the color config to
> > "always" in an on-disk file is basically a broken config. It was
> > exacerbated by 4c7f1819b, but it was already broken for scripts
Jeff King writes:
> I'd prefer not to revert. I think setting any of the color config to
> "always" in an on-disk file is basically a broken config. It was
> exacerbated by 4c7f1819b, but it was already broken for scripts that
> call "git log" or "git diff", or even just something as simple as pi
On Tue, Oct 03, 2017 at 11:25:44AM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jonathan Nieder writes:
> >
> >> Yet another alternative would be to treat color.ui=always as a
> >> deprecated synonym for color.ui=auto. I think that's my preferred
> >> fix.
> >
> > It is mine, t
Junio C Hamano writes:
> In any case, I think the first step may be to revert 136c8c8b from
> both 'master' and 2.14.x. These alternative solutions can come on
> top.
>
> Thoughts?
With the attached patch, after reverting 136c8c8b ("color: check
color.ui in git_default_config()", 2017-07-13) fr
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> Yet another alternative would be to treat color.ui=always as a
>> deprecated synonym for color.ui=auto. I think that's my preferred
>> fix.
>
> It is mine, too. And I do not think color.ui=absolutely-always for
> those who want to keep the
Jonathan Nieder writes:
> Yet another alternative would be to treat color.ui=always as a
> deprecated synonym for color.ui=auto. I think that's my preferred
> fix.
It is mine, too. And I do not think color.ui=absolutely-always for
those who want to keep the current behaviour is unneeded.
Hi,
Toni Uebernickel wrote:
> I updated to git version v2.14.2 on macOS using homebrew.
>
> Since then `git add --patch` and `git stash save --patch` are not
> working anymore. It's just printing the complete diff without ever
> stopping to ask for actions. This results in an unusable state, as
>
That's a very very old setting :)
Honestly, I don't know why it's "always". I have set up this setting years ago
and never thought about it again, as it worked out.
I changed it to "auto" and the --patch options are working again on v2.14.2!
Thank you very much for your time & efforts.
If I can
On Thu, Sep 28, 2017 at 07:03:55AM +0200, Toni Uebernickel wrote:
> color.ui=always
This is the problem, and Jonathan's guess was correct that 136c8c8b8f
(color: check color.ui in git_default_config(), 2017-07-13) is related.
Re-reading that commit message, I'm inclined to say that the commit
is
Hi Jonathan,
my configuration reads as follows, I only removed private tokens content.
I will try to get more details on which version exactly breaks the command.
Kind Regards,
Toni
core.excludesfile=/usr/local/etc/gitignore
core.whitespace=trailing-space,space-before-tab,-indent-with-non-tab,ta
Jonathan Nieder wrote:
> Jeff King wrote:
>> There aren't a lot of changes to the script between v2.13.2 and v2.14.2.
>> The most plausible culprit is d5addcf522 (add--interactive: handle EOF
>> in prompt_yesno, 2017-06-21), but I'm scratching my head over how that
>> could cause what you're seein
Hi,
Jeff King wrote:
> On Wed, Sep 27, 2017 at 07:28:49PM +0200, Toni Uebernickel wrote:
>> The previous version was v2.13.2.
>> I switched back to this version, and it works perfectly fine; without any
>> changes to my system.
>
> Thanks for confirming.
>
> There aren't a lot of changes to the
On Wed, Sep 27, 2017 at 07:28:49PM +0200, Toni Uebernickel wrote:
> The previous version was v2.13.2.
> I switched back to this version, and it works perfectly fine; without any
> changes to my system.
Thanks for confirming.
There aren't a lot of changes to the script between v2.13.2 and v2.14.
The previous version was v2.13.2.
I switched back to this version, and it works perfectly fine; without any
changes to my system.
--
Toni Uebernickel
tuebernic...@gmail.com - https://keybase.io/havvg
https://github.com/havvg - https://www.xing.com/profile/Toni_Uebernickel
> On 27. Sep 2017, at
On Wed, Sep 27, 2017 at 03:23:21PM +0200, Toni Uebernickel wrote:
> Hi there,
>
> I updated to git version v2.14.2 on macOS using homebrew.
>
> Since then `git add --patch` and `git stash save --patch` are not
> working anymore. It's just printing the complete diff without ever
> stopping to ask
26 matches
Mail list logo
