Skip to content

Conversation

@xim
Copy link
Contributor

@xim xim commented Nov 4, 2022

This brings color to the people without the complexities of the higher number of configs.

Relates to git-for-windows/git#4095

Signed-off-by: Morten Minde Neergaard [email protected]

This brings color to the people without the complexities of the higher
number of configs.

Relates to git-for-windows/git#4095

Signed-off-by: Morten Minde Neergaard <[email protected]>
@dscho
Copy link
Member

dscho commented Nov 5, 2022

While I see that this does what it is supposed to do, I cannot help but wonder what else this change does.

For example, I seem to remember vaguely that color.ui was not respected in all code paths where color.diff was respected, or some similar issue.

Also, this is technically a change in behavior that might negatively affect existing setups. What can we do to build confidence that this is not the case?

@xim
Copy link
Contributor Author

xim commented Nov 5, 2022

While I see that this does what it is supposed to do, I cannot help but wonder what else this change does.

For example, I seem to remember vaguely that color.ui was not respected in all code paths where color.diff was respected, or some similar issue.

There could always be bugs, of course, but from my reading of the source code it looks like color.ui should be respected quite universally.

Also, this is technically a change in behavior that might negatively affect existing setups. What can we do to build confidence that this is not the case?

For one, the change appears to only affect PortableGit, which might make things easier to reason about. The cases I can think about where this might cause changes would be where the user has specified color.ui = never or color.ui = always in their config or on the command line, and that would still result in colored output in most cases before.

Of close, it's always possible there might be behaviour changes I'm not thinking of. Feel like this move goes in a positive direction however, as I it reduces complexity and possibilities for confusion.

@dscho
Copy link
Member

dscho commented Nov 7, 2022

Okay, let's take it, then, and hope that any regressions are caught before Git v2.39.0 is due.

@dscho dscho merged commit a02eefd into git-for-windows:main Nov 7, 2022
@dscho
Copy link
Member

dscho commented Nov 7, 2022

The git-extra package was built successfully. Therefore, the next snapshot will have it.

dscho added a commit that referenced this pull request Nov 7, 2022
Portable Git no longer configures `color.diff`, `color.status`
and `color.branch` individually, but [configures `color.ui`
instead](#442),
which makes it easier to override the default.

Signed-off-by: Johannes Schindelin <[email protected]>
@xim xim deleted the default-color-config branch November 7, 2022 22:17
@xim
Copy link
Contributor Author

xim commented Nov 7, 2022

Great! I'll give it a spin then!

@xim
Copy link
Contributor Author

xim commented Nov 27, 2022

The change doesn't appear to be present in the snapshots. Apologies for not spotting it sooner, still using my custom-built version.

@dscho
Copy link
Member

dscho commented Nov 28, 2022

The change doesn't appear to be present in the snapshots. Apologies for not spotting it sooner, still using my custom-built version.

@xim thank you for testing! And you're absolutely correct, the issue is not fixed in the snapshots at all.

The reason is that this PR only addresses the issue if /etc/gitconfig did not exist yet. But when git-for-windows/git-sdk-64@b6f79f4 upgraded git-extra, the /etc/gitconfig file existed already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants