super config issue with VS2015 (and possibly other libgit2 clients)

[Kirill Katsnelson]

When GfW is installed, the new Windows-only super config has the option "core.crlf=auto" added (assuming the user selects the corresponding preference, which is a wise thing to do in Windows). Unfortunately, VS2015 Git provider does not know about the super config, and therefore thinks all files have changed when opening a solution from the cloned repository

To confirm, I selected Team Explorer/Settings/Repository settings/Other inside VS2015, and indeed "core.crlf" is not one of the settings listed there, nor any other from it (e. g., I see help.format, rebase.autosquash and others in the super config but not in VS dump)

The only sensible workaround now is to copy the super config settings manually into the system or global config, but that kinda defeats the purpose of the whole thing.

I do not know if there is a sensible solution except propagating the super config feature up to the main stream development and let the VS Git provider and other libgit2 clients pick up the change. Currently, it is half-baked, unusable and causes more confusion than solves problems.

To me, it would make more sense to create an ntfs link from .../etc/gitconfig to %ProgramData%/git/config to pioneer a good setup practice. It is easy to symlink in cygwin and thus share the same config, if the user wants 2 different Gits installed, or migrates.

 -kkm

[Kirill Katsnelson]

Addendum: ntfs linking does not work. An ntfs soft-link confises msys runtime. and git fails with a filesystem error ("feature not supported"). A hard link works, but the settings do not pop in in Visual Studio whatsoever. I conjecture VS Git provider has its own idea of the system config locations--the original problem that the super config was intended to fix.

Oh well. Maybe the installer should put a copy of settings it puts into super also into the global config? I do not know, the super config idea was good, but it certainly does not work in the real life :(

[Thomas Copper]

On Thu, Nov 5, 2015 at 5:56 AM, Kirill Katsnelson <k...@pobox.com> wrote:

When GfW is installed, the new Windows-only super config has the option "core.crlf=auto" added (assuming the user selects the corresponding preference, which is a wise thing to do in Windows). Unfortunately, VS2015 Git provider does not know about the super config, and therefore thinks all files have changed when opening a solution from the cloned repository

Excuse me, but I think GfW is not a good abbreviation for git-for-windows. Because it can be easily confused with "great firewall" of China.

( "great firewall" is a part of Internet censorship project of China.)

(Here are some articles about it :

https://en.wikipedia.org/wiki/Golden_Shield_Project
https://en.wikipedia.org/wiki/Great_Firewall )

Maybe "GfWin" or "GforWin" is better.

PS: My apologize to David Macek for disturbing him again.

 

To confirm, I selected Team Explorer/Settings/Repository settings/Other inside VS2015, and indeed "core.crlf" is not one of the settings listed there, nor any other from it (e. g., I see help.format, rebase.autosquash and others in the super config but not in VS dump)

The only sensible workaround now is to copy the super config settings manually into the system or global config, but that kinda defeats the purpose of the whole thing.

I do not know if there is a sensible solution except propagating the super config feature up to the main stream development and let the VS Git provider and other libgit2 clients pick up the change. Currently, it is half-baked, unusable and causes more confusion than solves problems.

To me, it would make more sense to create an ntfs link from .../etc/gitconfig to %ProgramData%/git/config to pioneer a good setup practice. It is easy to symlink in cygwin and thus share the same config, if the user wants 2 different Gits installed, or migrates.

 -kkm

--
You received this message because you are subscribed to the Google Groups "git-for-windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
To post to this group, send email to git-for...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/2bea7f03-3baf-4eec-b3f0-7f3c54af2901%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johannes Schindelin]

Hi Kirill,

On Wed, 4 Nov 2015, Kirill Katsnelson wrote:

> When GfW is installed, the new Windows-only super config has the option
> "core.crlf=auto" added (assuming the user selects the corresponding
> preference, which is a wise thing to do in Windows). Unfortunately,
> VS2015 Git provider does not know about the super config, and therefore
> thinks all files have changed when opening a solution from the cloned
> repository

You probably meant core.autocrlf, not core.crlf.

And yes, libgit2 does not (yet) heed the config in ProgramData. I have no
time line for you on that front, unfortunately.

> To confirm, I selected Team Explorer/Settings/Repository settings/Other
> inside VS2015, and indeed "core.crlf" is not one of the settings listed
> there, nor any other from it (e. g., I see help.format, rebase.autosquash
> and others in the super config but not in VS dump)
>
> The only sensible workaround now is to copy the super config settings
> manually into the system or global config, but that kinda defeats the
> purpose of the whole thing.

No, copying is the wrong thing to do. The whole, entire idea of moving the
config into a location that is *outside* of Git for Windows' directory
tree is to have a *proper* OS-wide config. It was a cute trick of libgit2
(and JGit, and other Git tools) to try to reuse Git for Windows' own
config, but it was also not quite the proper thing to do, as seen by the
config's move from C:\Program Files (x86)\etc\gitconfig to C:\Program
Files\Git\mingw64\etc\gitconfig. The location of the config is an
*implementation detail* that other tools just should never have relied
upon.

> I do not know if there is a sensible solution except propagating the super
> config feature up to the main stream development and let the VS Git
> provider and other libgit2 clients pick up the change. Currently, it is
> half-baked, unusable and causes more confusion than solves problems.

Thanks for your judgement. :-P

Seriously again, if you want to help, by all means, it is Open Source and
you are welcome to contribute. Venting your frustration is, however,
likely to be counterproductive: guess how much fun it is for others to
work on something where you get only frustration and anger as reward?

So yeah, I guess I am a bit more unlikely now to pick this up, in favor of
more rewarding tickets.

> To me, it would make more sense to create an ntfs link from
> .../etc/gitconfig to %ProgramData%/git/config to pioneer a good setup
> practice. It is easy to symlink in cygwin and thus share the same
> config, if the user wants 2 different Gits installed, or migrates.

Oh my. Symlinks. I fear that you may lack the entire background on this
can of worms:

https://github.com/git-for-windows/git/wiki/Symbolic-Links

Please note that there is no such thing as an "ntfs link". There are
reparse points, of which there are two relevant sub types: Vista-style
symlinks and pre-Vista junction points.

And of course there are .lnk files (which Cygwin used before to emulate
symlinks).

All of these (which all are referred to as "symbolic links") come with
their own set of challenges.

Ciao,
Johannes

[Kirill Katsnelson]

On Tue, Nov 17, 2015 at 5:07 AM, Johannes Schindelin <Johannes....@gmx.de> wrote:

On Wed, 4 Nov 2015, Kirill Katsnelson wrote:


You probably meant core.autocrlf, not core.crlf.

Correct, my bad.

 

And yes, libgit2 does not (yet) heed the config in ProgramData. I have no
time line for you on that front, unfortunately.

> The only sensible workaround now is to copy the super config settings
> manually into the system or global config, but that kinda defeats the
> purpose of the whole thing.

No, copying is the wrong thing to do. The whole, entire idea of moving the
config into a location that is *outside* of Git for Windows' directory
tree is to have a *proper* OS-wide config. It was a cute trick of libgit2
(and JGit, and other Git tools) to try to reuse Git for Windows' own
config, but it was also not quite the proper thing to do, as seen by the
config's move from C:\Program Files (x86)\etc\gitconfig to C:\Program
Files\Git\mingw64\etc\gitconfig. The location of the config is an
*implementation detail* that other tools just should never have relied
upon.

Yes, I understand the idea, and I agree that this is an important enhancement. Windows does not have anything like /etc, and all git incarnations should have a common place to look for system-wide settings. But.

 

> I do not know if there is a sensible solution except propagating the super
> config feature up to the main stream development and let the VS Git
> provider and other libgit2 clients pick up the change. Currently, it is
> half-baked, unusable and causes more confusion than solves problems.

Thanks for your judgement. :-P

I am still holding on to it. I am not venting at all, this is a technical assessment. We do not use Git in isolation; arguably, the most important client to libgit2 on Windows is Visual Studio. Before we can get the best support this new feature from VS, it is probably of use to a very limited number of users.

Seriously again, if you want to help, by all means, it is Open Source and
you are welcome to contribute.

To me, it looks quite simple: the feature can go into libgit2, and by way of this get support from VS 20xx. But this is years ahead, and we are here and now.

 

only frustration and anger as reward?

I am sorry you are copying me this way. I am talking about a technical problem only, and I did not mean to sound angered at all. Indeed, I wished the discussion be more productive.

 

So yeah, I guess I am a bit more unlikely now to pick this up, in favor of
more rewarding tickets.

My apologies, I think I am losing your train of thought here. So libgit2 and therefore Visual Studio support for the super config is not really a high priority issue?

I am aware of the linking mess in Windows; I am just trying to think up an intermediate solution until (of if?) Visual Studio is aware of the super config. I take for granted that the solution could be imperfect, or even a dirty hack, but dropping VS on the floor does not seem to me the most fruitful way of handling the problem.

Unfortunately, GfW now seems very unaware of links. When it sees a linked file or a junction point, it just crashes. I have a worktree created by cygwin git, with ntfs link support (and yes, it is messy!), but GfW just breaks trying to stat files there. Similarly, linking config files did not do any good. So currently I do not see any workaround that would make the super config usable. Are you aware of any?

 -kkm

[Johannes Schindelin]

Hi Kirill,

On Tue, 17 Nov 2015, Kirill Katsnelson wrote:

> On Tue, Nov 17, 2015 at 5:07 AM, Johannes Schindelin <
> Johannes....@gmx.de> wrote:
>
> > Seriously again, if you want to help, by all means, it is Open Source
> > and you are welcome to contribute.
>
> To me, it looks quite simple: the feature can go into libgit2, and by
> way of this get support from VS 20xx. But this is years ahead, and we
> are here and now.

How about this: you contribute a patch to libgit2 to support the
ProgramData config and I will do my best to get it fast-tracked into VS?

Deal?

Ciao,
Johannes

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 14:07:34 +0100 (CET)
Johannes Schindelin <Johannes....@gmx.de> wrote:

[...]

> No, copying is the wrong thing to do. The whole, entire idea of
> moving the config into a location that is *outside* of Git for
> Windows' directory tree is to have a *proper* OS-wide config. It was
> a cute trick of libgit2 (and JGit, and other Git tools) to try to
> reuse Git for Windows' own config, but it was also not quite the
> proper thing to do, as seen by the config's move from C:\Program
> Files (x86)\etc\gitconfig to C:\Program Files\Git\mingw64\etc
> \gitconfig. The location of the config is an *implementation detail*
> that other tools just should never have relied upon.

Sorry, I'm late to the party and had only a cursory look over this
thread but shouldn't the "system" GfW config file be located
in a directory under whatever is defined by [1] (see the first comment
there; I know better MSDN resources on this exist but I fail to locate
them ATM), that is, under "C:\ProgramData\Git" on ≥ Vista and
under "C:\Documents and Settings\All Users\Applcation Data\Git"
under Windows XP?

IIUC, that's what is defined to be "application-wide writable state".

If we would codify this, it would seize to be an implementation detail
because it would be a well-known location.
Sure I understand that everyone is supposed to call `git config` to
obtain Git configuration but certain pieces of softwaew, like libgit2
and JGit simply don't call out to Git and so they either need to have
their very own set of "global" configuration pieces or share them with
stock Git; I'd say the later would be an infinitely better approach.

[...]

1. https://msdn.microsoft.com/en-us/library/aa367992%28v=vs.85%29.aspx

[Kirill Katsnelson]

Sure. I'll start a discussion on a Github issue with them, and let's see
how far it gets us.

What is the license of GfW? libgit2 contribution guide says

> Other [than GPL -kkm] licenses have other requirements; check the license of the library you're porting code from to see what you need to do. As a general rule, MIT and BSD (3-clause) licenses are typically no problem. Apache 2.0 license typically doesn't work due to GPL incompatibility.

Is it compatible? I am assuming the changes in GfW may be considered a port.

-kkm

[Kirill Katsnelson]

On 151118 0227, Johannes Schindelin wrote:

> How about this: you contribute a patch to libgit2 to support the
> ProgramData config

If I am not mistaken, there is already one merged:

https://github.com/libgit2/libgit2/pull/3475

Am I missing anything?

-kkm

[Johannes Schindelin]

Hi Kirill,

As far as I can see, it is not in a release yet. Let me check my
background channels.

Will come back to you,
Johannes