Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Hi kusma, On 2015-08-12 13:58, Erik Faye-Lund wrote: On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On 2015-08-11 22:51, Johannes Sixt wrote: Invoking plink requires special treatment, and we have support and even test cases for the commands 'plink' and 'tortoiseplink'. We also support .exe variants for these two and there is a test for 'plink.exe'. On Windows, however, where support for plink.exe would be relevant, the test case fails because it is not possible to execute a file with a .exe extension that is actually not a binary executable---it is a shell script in our test. We have to disable the test case on Windows. Oh how would I wish you were working on Git for Windows even *just* a bit *with* me. At least I would wish for a more specific description of the development environment, because it sure as hell is not anything anybody can download and install as easily as Git for Windows' SDK. FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. Careful. If you continue along those lines, interactive rebase, `git add -p` and all those wonderful scripts Git has will have to stop working. Because those scripts completely disagree with what you just said about Windows if you think about it: *none* of them has an extension. I know that you do not mean this, of course, but that is the argument you were making... ;-) If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. And if we get a shell script without any `.exe` suffix, it is still considered as an invalid executable by the system. And even if we tack on an `.sh` suffix (which is *not* in line with the way Git works), it is *still* considered as an invalid executable by the system. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
On Thu, Aug 13, 2015 at 10:37 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi kusma, On 2015-08-12 13:58, Erik Faye-Lund wrote: On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On 2015-08-11 22:51, Johannes Sixt wrote: Invoking plink requires special treatment, and we have support and even test cases for the commands 'plink' and 'tortoiseplink'. We also support .exe variants for these two and there is a test for 'plink.exe'. On Windows, however, where support for plink.exe would be relevant, the test case fails because it is not possible to execute a file with a .exe extension that is actually not a binary executable---it is a shell script in our test. We have to disable the test case on Windows. Oh how would I wish you were working on Git for Windows even *just* a bit *with* me. At least I would wish for a more specific description of the development environment, because it sure as hell is not anything anybody can download and install as easily as Git for Windows' SDK. FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. Careful. If you continue along those lines, interactive rebase, `git add -p` and all those wonderful scripts Git has will have to stop working. Because those scripts completely disagree with what you just said about Windows if you think about it: *none* of them has an extension. I know that you do not mean this, of course, but that is the argument you were making... ;-) You should know better than to straw-man like that. I was not arguing to break any current functionality, but to not move further away from Windows' semantics. But if I would have, there's nothing that would stop us from renaming those scrips to *.sh, and let the filename dictate how to execute them. Or provide batch-files to wrap them. If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. And if we get a shell script without any `.exe` suffix, it is still considered as an invalid executable by the system. Nope, it's considered an unknown file, not an executable at all. And even if we tack on an `.sh` suffix (which is *not* in line with the way Git works), it is *still* considered as an invalid executable by the system. That's not necessarily true; the Git for Windows installer (optionally, but on by default) registers /bin/sh as a file-handler for .sh files. Windows knows just fine how to execute them, unless the user opts out. But again, I was not arguing to patch git to not parse the shebang. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Hi Johannes, On 2015-08-12 20:31, Johannes Sixt wrote: Am 12.08.2015 um 13:58 schrieb Erik Faye-Lund: On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. We should consider it the same way, otherwise we're on the path to user-experience schizophrenia. I'm not sure I consider this commit a step in the right direction. I, too, think that it is a wrong decision to pessimize git for the sake of a single test case. Oh, you make it sound as if you believe that I had indeed weakened Git *just* for a single test case. That is quite a strong assumption, and could not be further from the truth, though, I have to point out. It is important to keep in mind that we (actually, IIRC it was you) taught Git to recognize shell scripts when executing external programs *because Windows does not do that for us*. So yes, we are deviating from the standard Windows way of things, and we do that quite intentionally so. Now, let's look at the test case for a moment and let's try to understand the technique it uses (that breaks the test case currently). It puts a script in place of an `.exe`, with the intention to execute the script instead of the original executable. This technique is an age-old technique on Unix, and it just works. There are a range of valid reasons, from debugging to slightly modifying the function of a particular `.exe` (possibly renaming the original `.exe` and calling it from the script) in the easiest way: by scripting on top of it. If we want to allow such a thing -- allowing users to use scripts to modify the behavior of executables -- then we *have* to allow `.exe` suffixes for scripts, because that happens to be the suffix of executables on Windows. I guess you would have had an easier time to understand my thinking if I had replaced the sentence So the assumption that the `.exe` extension implies that the file is *not* a shell script is now wrong. by So this is a strong indicator that it was wrong to assume that `.exe` extensions imply that the file is *not* a shell script. Further, I even looked at the performance impact, but that is at least well documented in the commit message. I also have to point out that the alternative solution presented by your patch -- to disable the test case -- is no solution at all: the very platform that is most likely to have plink users is Windows. And to *exclude* that platform from running that unit test is questionable at best. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Am 13.08.2015 um 09:30 schrieb Johannes Schindelin: Hi Johannes, On 2015-08-12 20:31, Johannes Sixt wrote: Am 12.08.2015 um 13:58 schrieb Erik Faye-Lund: On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. We should consider it the same way, otherwise we're on the path to user-experience schizophrenia. I'm not sure I consider this commit a step in the right direction. I, too, think that it is a wrong decision to pessimize git for the sake of a single test case. Oh, you make it sound as if you believe that I had indeed weakened Git *just* for a single test case. Whatever. Since I do not have the time to provide hard numbers that prove my claim that your patch removes an optimization (and, furthermore, I do not want to reply to your arguments that I consider mostly philosophical rather than pragmatic), I bow out. Until this solution or that one is in upstream, I can help myself. Junio, please drop my patch. I do not have the nerves to support it. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Johannes, On 2015-08-11 22:51, Johannes Sixt wrote: Invoking plink requires special treatment, and we have support and even test cases for the commands 'plink' and 'tortoiseplink'. We also support .exe variants for these two and there is a test for 'plink.exe'. On Windows, however, where support for plink.exe would be relevant, the test case fails because it is not possible to execute a file with a .exe extension that is actually not a binary executable---it is a shell script in our test. We have to disable the test case on Windows. Oh how would I wish you were working on Git for Windows even *just* a bit *with* me. At least I would wish for a more specific description of the development environment, because it sure as hell is not anything anybody can download and install as easily as Git for Windows' SDK. FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. We should consider it the same way, otherwise we're on the path to user-experience schizophrenia. I'm not sure I consider this commit a step in the right direction. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Am 12.08.2015 um 13:58 schrieb Erik Faye-Lund: On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Yuck. On Windows, it's the extension of a file that dictates what kind of file it is (and if it's executable or not), not the contents. If we get a shell script written with the .exe-prefix, it's considered as an invalid executable by the system. We should consider it the same way, otherwise we're on the path to user-experience schizophrenia. I'm not sure I consider this commit a step in the right direction. I, too, think that it is a wrong decision to pessimize git for the sake of a single test case. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 13/17] engine.pl: provide more debug print statements
From: Sebastian Schuberth sschube...@gmail.com
On 25.06.2015 02:03, Philip Oakley wrote:
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -41,6 +41,7 @@ EOM
# Parse command-line options
while (@ARGV) {
my $arg = shift @ARGV;
+ #print Arg: $arg \n;
if ($arg eq -h || $arg eq --help || $arg eq -?) {
showUsage();
exit(0);
@@ -129,6 +130,7 @@ sub parseMakeOutput
print Parsing GNU Make output to figure out build
structure...\n;
my $line = 0;
while (my $text = shift @makedry) {
+ #print Make: $text\n; # show the makedry line
Please never commit code that's been commented out. Also see
http://dev.solita.fi/2013/07/04/whats-in-a-good-commit.html
;-)
The gif was fun, even if it's a little OTT. It does smack of religious
dogma though ;-)
--
Hi Sebastian,
It's deactivated code, not dead code [1].
I'd deliberately included this 'code', as per the commit message because
I saw this as a clear part of aiding future maintenance, and it matches
the rest of the code style, i.e. the judicious placement of a comment
that says 'here's the place to pick out the status when debugging' -
perhaps it's my engineering experience that sees the benefits.
These were the key debug points I used - other's I've removed from the
series.
Philip
[1] In one of the replies to
http://embeddedgurus.com/barr-code/2013/02/dead-code-the-law-and-unintended-consequences/
: as per DO178B safety critical software development guideline
document Terms Dead code and Deactivated Code have distinct
meanings:
Dead code : Dead code is source code (and it is a part of binary code)
that is not executed in the final system and it will be not having
traceability to any requirements (one can say unintentional code).
Deactivated code: code which is commented out or removed via #ifdef's
(it is not a part of final binary code) and it will be having
traceability to its low level requirements (its a intentional code and
it can be activated in some configurations through hardware traps for
debugging or other purposes.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Release candidate of Git for Windows 2.x is out
On 2015-06-26 13:06, Ties wrote: Do you have an ETA on the final release? No, sorry, no ETA yet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: 3rd release candidate of Git for Windows 2.x, was Re: Release candidate of Git for Windows 2.x is out
Hi Jon, On 2015-06-20 16:59, Jon wrote: On Saturday, June 20, 2015 at 10:16:09 AM UTC-4, Johannes Schindelin wrote: I just uploaded the 3rd release candidate for the upcoming Git for Windows 2.x release. Please find the download link here: https://git-for-windows.github.io/#download Lots of changes since the first release candidate (v2.4.2, I was too swamped to announce the second release candidate -- v2.4.3 -- I published Friday last week, my apologies). Please find them in the release notes: https://github.com/git-for-windows/build-extra/blob/master/installer/ReleaseNotes.md 1) Why are there two ssl/certs trees? (e.g. - one is used by git-bash.exe and the other git-cmd.exe and cmd/git.exe?) Please keep in mind that Git for Windows is a hybrid collection of pure Win32 executables and MSys2 executables (MSys2 is a stripped-down Cygwin providing a POSIX emulation layer on top of the Win32 API[*1*]). They are separated into the `/usr/` and the `/mingw64/` directories, respectively (`/mingw32/` for 32-bit). An example for a pure Win32 executable is `git.exe` while Perl and Bash are MSys2 executables. In general, we avoid MSys2 as much as possible: while it provides a nice POSIX emulation layer, it comes at a noticable performance penalty. So whenever we can get away with using OpenSSL compiled as pure Win32 library, we do so. Cloning via HTTPS falls into that category. When it comes to `git-svn` -- something that is needed by many users, still, and indeed the motivation for the most prolific contributor helping me with Git for Windows 2.x -- it is not that easy, though: `git-svn` is a Perl script, our Perl is an MSys2 program and therefore uses OpenSSL compiled as MSys2 library. That is the reason why we have separate ssl/ directory structures. One for MinGW (i.e. pure Win32) programs and one for MSys2 ones. 2) Why are INSTALL_DIR/usr/ssl/certs/ca-bundle.crt and INSTALL_DIR/mingw64/ssl/certs/ca-bundle.crt different? We simply use the packages provided by MSys2. The MinGW/MSys2 ca-certificates packages are sometimes out of sync, and that is what you are seeing here. Now, theoretically it would be possible to reconcile the different ca-certificates packages into a single one. The correct way to go about this would be by contributing to the MSys2 project: that way, not only Git for Windows but really all MSys2-based projects benefit from it. Ciao, Johannes Footnote *1*: https://msys2.github.io/ -- To unsubscribe from this list: send the line unsubscribe git in
Re: [msysGit] Re: Release candidate of Git for Windows 2.x is out
Hi, On 2015-06-09 14:10, QbProg wrote: I reproduce it using the windows command prompt (cmd.exe) using any repository. I tryed with bash and it works correctly. Please note that you removed enough context that the mail does not make sense anymore if read individually. At this point it might be best to open a ticket, as I suggested in my announcement: just log into GitHub (or sign up for free) and direct your web browser to https://github.com/git-for-windows/git/issues/new. For the record: I tried again, with `Git CMD`, this time I called ```cmd git clone https://github.com/dscho/images.git octo2 ``` ... and octo2/ is created correctly and contains the `.git/` subdirectory (which is hidden by default, but you can call `cd octo2/.git`). Read: I still cannot reproduce the issue. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Release candidate of Git for Windows 2.x is out
Hi, On 2015-06-09 10:43, Qb wrote: I'm trying the release candidate on Win 8.1. Everything's working now, but when I clone a repository git clone http://./name.git CustomFolder it creates CustomFolder with the checkout files, but the .git folder is created inside CustomFolder\CustomFolder\ I cannot reproduce this behavior. This is what I did to test: 1. install Git-2.4.2.1-release-candidate-64.exe (default options) 2. run Git Bash 3. git clone https://github.com/dscho/images.git octocats This results in a correct checkout: `$HOME/octocats/.git/` exists and contains the local repository. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x
Hi Vitaly, On 2015-04-15 09:17, Vitaly wrote: feel free to give it a spin: https://git-for-windows.github.io/#download I have installed msysgit 1.9.4, installing git for windows 2.3.5.8 (into default localtion and with use from Windows command prompt) Which version, 32-bit or 64-bit? PortableGit or regular Git? and call git --version still give me msysgit1.9.4 And the path was not adjusted at all? That would be strange indeed. I have delete gfw 2.3.5.8 and msysgit 1.9.4, install gfw 2.3.5.8 once again (and check use from Windows command prompt) and now I have: C:\git error launching git: . I see C:\Program Files (x86)\Git\bin in my PATH (from old installs?), but did not see this directory (bin) under Git installation There is explicit code to modify the PATH environment variable when you choose the from Windows command prompt option: https://github.com/git-for-windows/build-extra/blob/4fdceef37514d1b35d524a8752ccf4e7ad778f60/installer/install.iss.in#L1163-L1177 Just to make sure, you are certain that the PATH variable is not touched, even if you reinstall (without uninstalling Git for Windows first)? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x
Hi Rupert, On Mon, Apr 13, 2015 at 1:51 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On 2015-04-11 10:37, rupert thurner wrote: * the prompt is still as slow as before, calculating the branch name on pressing return without option to turn it off There is no explicit option in the installer to turn it off, but you can easily edit `/etc/profile.d/git-prompt.sh` to adjust it to your liking. If you think that more people would want to have an option in the installer to switch it off, you should read https://github.com/git-for-windows/git/wiki/Making-an-installer, edit /usr/src/build-extra/installer/install.iss.in after having a look at https://github.com/git-for-windows/build-extra/commit/cbcf69b9 and open a Pull Request. Personally I edit it away from PS1: https://github.com/rctay/msysgit/commit/4038833505bc2c088524546e923d64d69c0fa37f -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x
On Sun, 12 Apr 2015 19:51:29 +0200 Johannes Schindelin johannes.schinde...@gmx.de wrote: [...] * it is talking german to me would it be sufficient to delete c:\Apps\gitwin\mingw64\share\locale\de\LC_MESSAGES\ resp the whole locale directory to let it speak english? Probably. But the canonical solution is to set the `LC_ALL` or `LANG` environment variables accordingly. JFTR, that won't probably fix `git gui` and `gitk` as they are started directly, not via shell scripts, and hence are unaffected by whatever tweaks are done in ~/.bashrc *unless* they're started from the interactive Git bash shell and hence see that environment. I would hence just stick LC_MESSAGES=en (or LC_ALL, or LANG) into the environment variables (on the user's level) and solve this problem once and for all future programs making use of Unix-y locale setup conventions. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x
Hi Rupert, On 2015-04-11 10:37, rupert thurner wrote: three things i do not like it so much: * the old distinct icon is replaced by a new one which looks similar to many other programs, like google chrome. would it be possible to set the old icon? Git 1.9.5 came with the Git icon already (the diamond with the branch in it) and now we simply have this Windowsified. There was so much positive and uplifting feedback about it at the Git Merge (and besides, I really like the new icon myself), it is unlikely to change. * the prompt is still as slow as before, calculating the branch name on pressing return without option to turn it off There is no explicit option in the installer to turn it off, but you can easily edit `/etc/profile.d/git-prompt.sh` to adjust it to your liking. If you think that more people would want to have an option in the installer to switch it off, you should read https://github.com/git-for-windows/git/wiki/Making-an-installer, edit /usr/src/build-extra/installer/install.iss.in after having a look at https://github.com/git-for-windows/build-extra/commit/cbcf69b9 and open a Pull Request. * it is talking german to me would it be sufficient to delete c:\Apps\gitwin\mingw64\share\locale\de\LC_MESSAGES\ resp the whole locale directory to let it speak english? Probably. But the canonical solution is to set the `LC_ALL` or `LANG` environment variables accordingly. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re:
I was not cross posting. Posted on this thread after you mentioned in your post that writing on msysgit user group is futile. Thought I wouldn't get further replies on my questions there. Plus I got a feeling that I will get more in depth information here. Sorry if I sent a wrong message On Apr 9, 2015, at 6:27 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 08 Apr 2015 23:58:58 +0200 Thomas Braun thomas.br...@virtuell-zuhause.de wrote: [...] I am trying to run the latest git 1.9.5 installer on windows. When I run strings on libneon-25.dll it shows this: ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014 But when I load this dll in dependency walker, it picks up msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions to you: 1. Is libneon-25.dll statically linked with openssl-1.0.1h? 2. If not, where is the reference to 1.0.1h coming from? I would be suprised if we link openssl statically into libneon. I guess libneon just reports against which openssl version it was *built*. I am asked to rebuild git with libneon-25.dll linked against openssl-1.0.1m. But I am having a feeling that this is not needed, since libneon is already picking the latest openssl version. Can you please confirm? You can download the development enviroment for git for windows here [1]. After installation, checkout the msys branch and then you can try to recomplile libneon using /src/subversion/release.sh. [1]: https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/msysGit-netinstall-1.9.5-preview20150319.exe [...] JFTR, the discussion about the same issue has been brought up on git-users as well [2]. (People should really somehow use the basics of netiquette and mention in their posts where they cross-post things.) 2. https://groups.google.com/d/topic/git-users/WXyWE5_JfNc/discussion -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re:
On Wed, 08 Apr 2015 23:58:58 +0200 Thomas Braun thomas.br...@virtuell-zuhause.de wrote: [...] I am trying to run the latest git 1.9.5 installer on windows. When I run strings on libneon-25.dll it shows this: ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014 But when I load this dll in dependency walker, it picks up msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions to you: 1. Is libneon-25.dll statically linked with openssl-1.0.1h? 2. If not, where is the reference to 1.0.1h coming from? I would be suprised if we link openssl statically into libneon. I guess libneon just reports against which openssl version it was *built*. I am asked to rebuild git with libneon-25.dll linked against openssl-1.0.1m. But I am having a feeling that this is not needed, since libneon is already picking the latest openssl version. Can you please confirm? You can download the development enviroment for git for windows here [1]. After installation, checkout the msys branch and then you can try to recomplile libneon using /src/subversion/release.sh. [1]: https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/msysGit-netinstall-1.9.5-preview20150319.exe [...] JFTR, the discussion about the same issue has been brought up on git-users as well [2]. (People should really somehow use the basics of netiquette and mention in their posts where they cross-post things.) 2. https://groups.google.com/d/topic/git-users/WXyWE5_JfNc/discussion -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sparse checkout not working as expected (colons in filenames on Windows)
Hi Duy, On 2015-03-25 01:46, Duy Nguyen wrote: On Wed, Mar 25, 2015 at 6:50 AM, Philip Oakley philipoak...@iee.org wrote: That said, the final error (which I'd missed in the earlier post) is: fatal: make_cache_entry failed for path 'ifcfg-eth0:0' This is on the Windows (pre-compiled msysgit at v1.9.5) Git bash, so could be a catch path in that code for make_cache_entry (I've not checked the code yet). So at the moment it doesn't look like sparse checkout can be used to avoid colons in windows on-disk files based on the current code. Both of your commands below fail by the same function, verify_path() because of this msysgit commit 2e2a2d1 (NTFS: Prevent problematic paths from being checked out - 2014-12-10). I guess that check is a bit too strong, it should apply when new index entries are created from worktree (not from a tree).. Oh, right, that check needs some relaxing. But certainly in a different way: you *definitely* want to prevent attacks from the outside, and those originate from the *tree*. What we need to do instead is to relax the check to apply only if we are really going to write out that file, not when it is skipped. Thanks, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sparse checkout not working as expected (colons in filenames on Windows)
On Wed, Mar 25, 2015 at 1:39 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Duy, On 2015-03-25 01:46, Duy Nguyen wrote: On Wed, Mar 25, 2015 at 6:50 AM, Philip Oakley philipoak...@iee.org wrote: That said, the final error (which I'd missed in the earlier post) is: fatal: make_cache_entry failed for path 'ifcfg-eth0:0' This is on the Windows (pre-compiled msysgit at v1.9.5) Git bash, so could be a catch path in that code for make_cache_entry (I've not checked the code yet). So at the moment it doesn't look like sparse checkout can be used to avoid colons in windows on-disk files based on the current code. Both of your commands below fail by the same function, verify_path() because of this msysgit commit 2e2a2d1 (NTFS: Prevent problematic paths from being checked out - 2014-12-10). I guess that check is a bit too strong, it should apply when new index entries are created from worktree (not from a tree).. Oh, right, that check needs some relaxing. But certainly in a different way: you *definitely* want to prevent attacks from the outside, and those originate from the *tree*. What we need to do instead is to relax the check to apply only if we are really going to write out that file, not when it is skipped. Yeah. In fact if you do this, not checking out files that can't be or not safe to be checked out, then the ifcfg-eth0:0 problem that Phillip wanted to avoid using sparse checkout is also gone. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Duy, On 2015-02-25 11:02, Duy Nguyen wrote: On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. Some data point as I have a half-baked builtin/pull.c in my (forgotten) private branch for 3 years. pull.c has 389 lines (with 24 shell lines left in #if 0). git-pull.sh has 340 lines. Let's add 100 C lines to pull.c when it's complete, that's 50% more lines. But in the git-pull case the student could get a good head start by reusing my code, maybe. Thanks for the pointer, I will keep that in mind! Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Matthieu, On 2015-02-25 11:25, Matthieu Moy wrote: - Original Message - On 2015-02-24 13:28, Jeff King wrote: On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. I tried, but there are no orgs listed as of yet when I click Make connection. Not sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor. Thanks. My username is – surprise! – 'dscho' ;-) Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
- Original Message - Hi Peff, On 2015-02-24 13:28, Jeff King wrote: On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. I tried, but there are no orgs listed as of yet when I click Make connection. Not sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: Done: https://github.com/git/git.github.io/pull/12 Thanks, merged. I opened another PR, based on Mathieu's advice. Thanks, merged. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Matthieu, On 2015-02-25 00:56, Matthieu Moy wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh There is also: $ wc -l git-bisect.sh 528 git-bisect.sh And there is already builtin/bisect--helper.c that can be used to convert step by step shell code to C. I can mentor or co-mentor this convertion by the way, but that would conflict with the other bisect related GSoC project if a student takes it. I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. Sure. You're right, I was thinking too big. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. That's excellent advice. Yeah! This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). Well, all of this is academic at this point. Yeah, but it's still worth keeping in many parts of our collective mind :-) Let's see whether we get accepted, and then, if a student finds this project compelling enough. If both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to get her feet wet. Great! Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. Some data point as I have a half-baked builtin/pull.c in my (forgotten) private branch for 3 years. pull.c has 389 lines (with 24 shell lines left in #if 0). git-pull.sh has 340 lines. Let's add 100 C lines to pull.c when it's complete, that's 50% more lines. But in the git-pull case the student could get a good head start by reusing my code, maybe. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Stefan Beller venit, vidit, dixit 25.02.2015 01:34: On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a shell script before. I did not have much real-coding expertise with the git community before and by today there are 403 lines of code in builtin/repack.c. so going for roughly 3 times (1200 lines of code) change would make a summer, specially if you need to learn how the workflow is in the open source world. There the lines in c doubled nearly exactly. (before 197 shell lines, afterwards 387 c lines). Just last weekend I met people, who were afraid of contributing to open source because sometimes the internet can be very mean. Git being quite a high profile project, as it is widely used, might not help, but rather fear people away. I guess they've read about the lkml too much :) I consider the gitml to be a relatively civilized place for constructive criticism, without rants, flame wars and ad hominem swear word attacks. I don't know how it's perceived from the outside (but that drew me in back then). Maybe we can attach a photo of our maintainer to the GSOC page? That would prove we're nice and polite :) That said I would not underestimate the initial time a student needs to learn the workflow. Though most of that learning is done in the micro project phase. Yes, the technical workflow as well as the social habits. They should follow the gitml even before, and then the micro projects are a great learning ground. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Peff, On 2015-02-24 13:28, Jeff King wrote: On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. I tried, but there are no orgs listed as of yet when I click Make connection. Done: https://github.com/git/git.github.io/pull/12 Thanks, merged. I opened another PR, based on Mathieu's advice. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Matthieu, On 2015-02-25 00:56, Matthieu Moy wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. Sure. You're right, I was thinking too big. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. That's excellent advice. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). Well, all of this is academic at this point. Let's see whether we get accepted, and then, if a student finds this project compelling enough. If both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to get her feet wet. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. Also drop proper as if scripted Porcelains are second class citizens ;-) If you had to deal with the portability/performance issues of the shell scripts I am frequently faced with, you would not call them first class citizens, either. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Peff, On 2015-02-18 20:32, Jeff King wrote: On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote: The response to my previous email was not overwhelming, but people did express some interest in Git doing GSoC this year. So I've started on the application, using last year's version as a template. I feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts. After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Thanks, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. Done: https://github.com/git/git.github.io/pull/12 Thanks, merged. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Peff, On 2015-02-24 13:06, Jeff King wrote: On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote: After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. You may also want to add Windows-specific ideas to the page at: https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md Even something high-level like helping move programs to builtins to help Windows will let students know that it's a potential direction. Done: https://github.com/git/git.github.io/pull/12 Thank you, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Good news! About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one. This way, you can have a first patch series reviewed on-list, and merged in pu rather soon. From my experience, an early review is very important to get the student on track, and splitting the GSoC into multiple related projects avoids the situation where you have the feature 95% completed at the end of the GSoC, but nothing merged. add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. OTOH, you know which script would be most useful to be converted into a builtin much better than me! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Also drop proper as if scripted Porcelains are second class citizens ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a shell script before. I did not have much real-coding expertise with the git community before and by today there are 403 lines of code in builtin/repack.c. so going for roughly 3 times (1200 lines of code) change would make a summer, specially if you need to learn how the workflow is in the open source world. There the lines in c doubled nearly exactly. (before 197 shell lines, afterwards 387 c lines). Just last weekend I met people, who were afraid of contributing to open source because sometimes the internet can be very mean. Git being quite a high profile project, as it is widely used, might not help, but rather fear people away. That said I would not underestimate the initial time a student needs to learn the workflow. Though most of that learning is done in the micro project phase. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
Torsten Bögershausen tbo...@web.de writes: The work to be done, what I can see: please amend the commit message: s/more exotic// Thanks for reminding; I thought this was excised already but apparently hasn't (yet). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-02-12 23.36, Junio C Hamano wrote: So after discussing this one and queuing the resulting three-patch series jk/sanity that consists of the three patches: * jk/sanity (2015-01-27) 3 commits - test-lib.sh: set prerequisite SANITY by testing what we really need - tests: correct misuses of POSIXPERM - t/lib-httpd: switch SANITY check for NOT_ROOT Waiting for ack or counter-proposal from Torsten. Otherwise looking good. Do we want to proceed with these, or do we want any more work done on them? I managed to run the tests with POSIXPERM and/or SANITY under Cygwin, Msysgit, Linux, root@linux, Mac and root@Mac. All passed. The work to be done, what I can see: please amend the commit message: s/more exotic// -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Windows Bluescreen
Am 12.02.2015 um 14:21 schrieb Erik Friesen: Sorry, I don't know what this TOP posting problem is, and hitting reply only replies to the last sender. If you prefer, and you have some regular bugtracker, I could use that instead of email posting. To repro- Set up git user on local linux repo, in my case 192.168.0.100 On a windows 7 64bit machine- $ cd myproject $ git init $ git add . $ git commit -m 'initial commit' $ git remote add origin git@192.168.0.100:/opt/git/project.git $ git push origin master (Shamelessly copied from git page) Problem happens after entering password, it may or may not get started. The nature of a bluescreen doesn't make debugging and reproduction real easy. If it helps, I can get the dumps from those crashes. To move on, I moved back to local http pushes. I'm doing pushes over ssh on a daily basis against my linux server. And I'm using a Win7 64bit machine as well. Can you try if it makes any difference if you use ssh login with public keys instead of passwords? You can also try to add LogLevel Debug to ~/.ssh/config in order to get more verbose ssh output. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 0/3] Win32: nanosecond-precision file times
Hi, On 2015-02-12 20:48, Junio C Hamano wrote: Karsten Blees karsten.bl...@gmail.com writes: This patch series was inspired by the problem that Git does not detect changed file content if st_size, st_mtime and st_ctime are unchanged. This was apparently caused by VSS2Git resetting mtime to a value in the past. [1] I believe (or rather hope) that all involved in the discussion agree that Git cannot reasonably be expected to detect changed file content if file time(s) are reset on purpose. However, some users have expressed concerns that 'same size and mtime' [2] may theoretically happen by chance in daily operation. Hmph. Haven't we already accepted that it is not just may theoretically happen and had counter-measures in racy-git detection machinery for quite some time? I agree that the racy-git reference is more of a red herring; it appears that the report Karsten referred to is based on a different understanding of the mtime than mine (it is purported that the mtime of a file should reflect the time when it entered the repository, rather than the time when the file was written to disk). Please let that not distract you. This patch series has merits on the basis of populating st_mtim.tv_nsec already. We can provide this information in the common case (i.e. NTFS, *not* FAT), so we should. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Windows Bluescreen
Sorry, I don't know what this TOP posting problem is, and hitting reply only replies to the last sender. If you prefer, and you have some regular bugtracker, I could use that instead of email posting. To repro- Set up git user on local linux repo, in my case 192.168.0.100 On a windows 7 64bit machine- $ cd myproject $ git init $ git add . $ git commit -m 'initial commit' $ git remote add origin git@192.168.0.100:/opt/git/project.git $ git push origin master (Shamelessly copied from git page) Problem happens after entering password, it may or may not get started. The nature of a bluescreen doesn't make debugging and reproduction real easy. If it helps, I can get the dumps from those crashes. To move on, I moved back to local http pushes. On Thu, Feb 12, 2015 at 7:42 AM, Thomas Braun thomas.br...@virtuell-zuhause.de wrote: Am Donnerstag, den 12.02.2015, 07:21 -0500 schrieb Erik Friesen: I'd say this is related. http://sourceforge.net/p/mingw/bugs/2240/ There isn't much hope, that was filed months ago with no action. I suggest moving to another ssh library perhaps? Anyways, this is a windows git bug report, so it really needs to stay with mysgit in my opinion. I'd say it should reproduce without much effort. Do a git push using win7 64 pro or similar, I'd say it will have issues. At minimum, this should be on the list for others to view. I have run across problems from others, but I don't think they realized it could be an ssh problem. (Please don't TOP post) The cited bug report does not correlate to msysgit as we compile and ship our own openssh. Git for Windows Version 1.8.x might still have the old and slow openssh. With the newest version I get speeds of up to 30MB/s over Gigabit LAN. Can you create a minimal test case to reprocude the problem? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Windows Bluescreen
Am Donnerstag, den 12.02.2015, 07:21 -0500 schrieb Erik Friesen: I'd say this is related. http://sourceforge.net/p/mingw/bugs/2240/ There isn't much hope, that was filed months ago with no action. I suggest moving to another ssh library perhaps? Anyways, this is a windows git bug report, so it really needs to stay with mysgit in my opinion. I'd say it should reproduce without much effort. Do a git push using win7 64 pro or similar, I'd say it will have issues. At minimum, this should be on the list for others to view. I have run across problems from others, but I don't think they realized it could be an ssh problem. (Please don't TOP post) The cited bug report does not correlate to msysgit as we compile and ship our own openssh. Git for Windows Version 1.8.x might still have the old and slow openssh. With the newest version I get speeds of up to 30MB/s over Gigabit LAN. Can you create a minimal test case to reprocude the problem? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-01-23 22:24, Torsten Bögershausen wrote: [...] either to always switch off SANITY for CYGWIN (or Windows in general). Nice one! You gave me the chuckle for the day ;-) Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-01-22 23.07, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
If I run that sequence manually:
chmod 755 .
touch x
chmod a-w .
rm x
touch y
x is gone, (but shoudn't according to POSIX)
y is not created, access denied
Good (or is that Sad?).
diff --git a/t/test-lib.sh b/t/test-lib.sh
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1039,7 +1039,17 @@ test_lazy_prereq NOT_ROOT '
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
test_lazy_prereq SANITY '
- test_have_prereq POSIXPERM,NOT_ROOT
+ mkdir ds
+ touch ds/x
+ chmod -w ds
+ if rm ds/x
+ then
+ chmod +w ds
+ false
+ else
+ chmod +w ds
+ true
+ fi
'
It looks like a better approach overall.
Because we cannot know where $(pwd) is when lazy prereq is evaluated
(it typically is at the root of the trash hierarchy, but not always)
and we would not want to add, leave or remove random files in the
working tree that are not expected by the tests proper (e.g. a test
that counts untracked paths are not expecting ds/ to be there), your
actual fix may need to be a bit more careful, though.
Thanks.
Hm,
I think there are 2 different possiblities to go further,
either to always switch off SANITY for CYGWIN (or Windows in general).
I haven't tested anything, the idea came up while writing this email.
The other way is to go away from the hard coded we know we are root,
so SANITY must be false, or we know that Windows is not 100% POSIX,
and probe the OS/FS dynamically.
The following probably deserves the price for the most clumsy prerequisite
ever written.
(CopyPaste of a real patch into the mailer, not sure if it applies)
It has been tested under Mac OS, root@Mac OS, Cygwin / Msysgit
What do you think ?
-- 8 --
Subject: [PATCH 1/2] test-lib.sh: Improve SANITY
SANITY was not set when running as root,
but this is not 100% reliable for CYGWIN:
A file is allowed to be deleted when the containing
directory does not have write permissions.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/test-lib.sh | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 93f7cad..b8f736f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1038,8 +1038,26 @@ test_lazy_prereq NOT_ROOT '
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
+# Special check for CYGWIN (or Windows in general):
+# A file can be deleted, even if the containing directory does'nt
+# have write permissions
test_lazy_prereq SANITY '
- test_have_prereq POSIXPERM,NOT_ROOT
+ dsdir=$$ds
+ mkdir $dsdir
+ touch $dsdir/x
+ chmod -w $dsdir
+ if rm $dsdir/x
+ then
+ chmod +w $dsdir
+ rm -rf $dsdir
+ echo 2 SANITY=false
+ false
+ else
+ chmod +w $dsdir
+ rm -rf $dsdir
+ echo 2 SANITY=true
+ true
+ fi
'
GIT_UNZIP=${GIT_UNZIP:-unzip}
--
Subject: [PATCH 2/2] t2026 needs SANITY
When running as root 'prune directories with unreadable gitdir' in t2026 fails.
Protect this TC with SANITY
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t2026-prune-linked-checkouts.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t2026-prune-linked-checkouts.sh
b/t/t2026-prune-linked-checkouts.sh
index 170aefe..2936d52 100755
--- a/t/t2026-prune-linked-checkouts.sh
+++ b/t/t2026-prune-linked-checkouts.sh
@@ -33,7 +33,7 @@ EOF
! test -d .git/worktrees
'
-test_expect_success POSIXPERM 'prune directories with unreadable gitdir' '
+test_expect_success SANITY 'prune directories with unreadable gitdir' '
mkdir -p .git/worktrees/def/abc
: .git/worktrees/def/def
: .git/worktrees/def/gitdir
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
Torsten Bögershausen tbo...@web.de writes:
It has been tested under Mac OS, root@Mac OS, Cygwin / Msysgit
What do you think ?
Except that we may want to be more careful to detect errors from the
initial mkdir and clean-up part (which should abort the test, not
just declare !SANITY), I think the basic idea is sound.
test_dir=$TRASH_DIRECTORY/.sanity-test-dir
! mkdir $test_dir
$test_dir/x
chmod -w $test_dir ||
error bug in test sript: cannot prepare .sanity-test-dir
rm $test_dir/x
status=$?
chmod +w $test_dir
rm -r $test_dir ||
error bug in test sript: cannot clean .sanity-test-dir
return $status
or something along that line?
-- 8 --
Subject: [PATCH 1/2] test-lib.sh: Improve SANITY
SANITY was not set when running as root,
but this is not 100% reliable for CYGWIN:
A file is allowed to be deleted when the containing
directory does not have write permissions.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/test-lib.sh | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 93f7cad..b8f736f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1038,8 +1038,26 @@ test_lazy_prereq NOT_ROOT '
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
+# Special check for CYGWIN (or Windows in general):
+# A file can be deleted, even if the containing directory does'nt
+# have write permissions
test_lazy_prereq SANITY '
- test_have_prereq POSIXPERM,NOT_ROOT
+ dsdir=$$ds
+ mkdir $dsdir
+ touch $dsdir/x
+ chmod -w $dsdir
+ if rm $dsdir/x
+ then
+ chmod +w $dsdir
+ rm -rf $dsdir
+ echo 2 SANITY=false
+ false
+ else
+ chmod +w $dsdir
+ rm -rf $dsdir
+ echo 2 SANITY=true
+ true
+ fi
'
GIT_UNZIP=${GIT_UNZIP:-unzip}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-01-21 23.33, Junio C Hamano wrote: Are you reporting differences between the state before these patches and after, or just the fact that with these patches the named tests break (which may or may not be broken before the patches)? The intention was to report what is now breaking. One example is this one: - git.git/master: ok 15 # skip Test that git rm -f fails if its rm fails (missing SANITY) git.git/pu: not ok 15 - Test that git rm -f fails if its rm fails # #chmod a-w . #test_must_fail git rm -f baz #chmod 775 . # The next step could be to dig further: If I run that sequence manually: chmod 755 . touch x chmod a-w . rm x touch y x is gone, (but shoudn't according to POSIX) y is not created, access denied -- I can see that there are 3 groups of OS/FS combinations: Group 1: File access bits are not maintained, and not obeyed. Typical: VFAT, Git for Windows, (and some network protocols like SAMBA, depending on the OS/FS involved and/or the mount options) Typically core.filemode is false after git init Group 2: File access bits are maintained and obeyed: POSIX/Unix/Linux/Mac OS and CYGWIN Typically core.filemode is true after git init Group 3 : File access bits are maintained, but not (fully) obeyed running as root under Linux/Unix... Or Windows, when a file is allowed to be deleted from a directory without write permissions. - In short, the following seems to be an improvement: diff --git a/t/test-lib.sh b/t/test-lib.sh --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1039,7 +1039,17 @@ test_lazy_prereq NOT_ROOT ' # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test_lazy_prereq SANITY ' - test_have_prereq POSIXPERM,NOT_ROOT + mkdir ds + touch ds/x + chmod -w ds + if rm ds/x + then + chmod +w ds + false + else + chmod +w ds + true + fi ' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-01-22 23.07, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: If I run that sequence manually: chmod 755 . touch x chmod a-w . rm x touch y x is gone, (but shoudn't according to POSIX) y is not created, access denied Good (or is that Sad?). It feels that this is by design: In old days under MS/DOS the only way to hinder people from deleting a file was to make it read only with help of the ATTRIB command. https://en.wikipedia.org/wiki/ATTRIB Later NTFS introduced the (ACL like) secutity information, and (unless I am completely wrong) the delete file is part of the modify permission, not write. diff --git a/t/test-lib.sh b/t/test-lib.sh --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1039,7 +1039,17 @@ test_lazy_prereq NOT_ROOT ' # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test_lazy_prereq SANITY ' - test_have_prereq POSIXPERM,NOT_ROOT + mkdir ds + touch ds/x + chmod -w ds + if rm ds/x + then + chmod +w ds + false + else + chmod +w ds + true + fi ' It looks like a better approach overall. Because we cannot know where $(pwd) is when lazy prereq is evaluated (it typically is at the root of the trash hierarchy, but not always) and we would not want to add, leave or remove random files in the working tree that are not expected by the tests proper (e.g. a test that counts untracked paths are not expecting ds/ to be there), your actual fix may need to be a bit more careful, though. Thanks. So true, what is a better place or way to run the test ? Can we use /tmp (Which may be a different file system)? Or can we use $HOME/$$ds (Which is an artificial HOME) We already pollute the $PWD here test_lazy_prereq CASE_INSENSITIVE_FS ' echo good CamelCase echo bad camelcase test $(cat CamelCase) != good ' and here: test_lazy_prereq UTF8_NFD_TO_NFC ' Would mkdir $HOME/ds be a better approach then ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
Hm, being one day offline and there are lots of ideas and new patches, I like that. I run these test under msys and cygwin on latest pu (a3dc223ff234481356c): ./t0001-init.sh ./t0004-unwritable.sh ./t0061-run-command.sh ./t0070-fundamental.sh ./t1004-read-tree-m-u-wf.sh ./t1300-repo-config.sh ./t1301-shared-repo.sh ./t1308-config-set.sh ./t2026-prune-linked-checkouts.sh ./t3600-rm.sh ./t3700-add.sh ./t4039-diff-assume-unchanged.sh ./t4056-diff-order.sh ./t5537-fetch-shallow.sh ./t7300-clean.sh ./t7503-pre-commit-hook.sh ./t7504-commit-msg-hook.sh ./t7508-status.sh (msys passes or skips all) Without digging further, these fail on my cygwin: $ grep not ok p.txt not ok 29 - init notices EPERM not ok 2 - write-tree should notice unwritable repository not ok 3 - commit should notice unwritable repository not ok 4 - update-index should notice unwritable repository not ok 5 - add should notice unwritable repository not ok 3 - mktemp to unwritable directory prints filename not ok 13 - funny symlink in work tree, un-unlink-able not ok 23 - proper error on non-accessible files not ok 4 - prune directories with unreadable gitdir not ok 15 - Test that git rm -f fails if its rm fails not ok 16 - When the rm in git rm -f fails, it should not remove the file from the index not ok 20 - Re-add foo and baz not ok 21 - Modify foo -- rm should refuse not ok 22 - Modified foo -- rm -f should work not ok 23 - Re-add foo and baz for HEAD tests not ok 24 - foo is different in index from HEAD -- rm should refuse not ok 23 - git add should fail atomically upon an unreadable file not ok 24 - git add --ignore-errors not ok 25 - git add (add.ignore-errors) not ok 26 - git add (add.ignore-errors = false) not ok 27 - --no-ignore-errors overrides config not ok 4 - unreadable orderfile not ok 28 - removal failure not ok 61 - status succeeds in a read-only repository If we remove POSIXPERM from CYGWIN, all tests pass ;-) but some are skipped : ok 26 - init creates a new deep directory (umask vs. shared) ok 3 - run_command reports EACCES ok 4 - unreadable directory in PATH ok 113 - preserves existing permissions ok 2 - shared=1 does not clear bits preset by umask 002 ok 3 - shared=1 does not clear bits preset by umask 022 ok 5 - update-server-info honors core.sharedRepository ok 6 - shared = 0660 (r--r-) ro ok 7 - shared = 0660 (rw-rw) rw ok 8 - shared = 0640 (r--r-) ro ok 9 - shared = 0640 (rw-r-) rw ok 10 - shared = 0600 (r) ro ok 11 - shared = 0600 (rw---) rw ok 12 - shared = 0666 (r--r--r--) ro ok 13 - shared = 0666 (rw-rw-rw-) rw ok 14 - shared = 0664 (r--r--r--) ro ok 15 - shared = 0664 (rw-rw-r--) rw ok 16 - info/refs respects umask in unshared repo ok 17 - git reflog expire honors core.sharedRepository ok 18 - forced modes ok 4 - find-copies-harder is not confused by mode bits ok 10 - shallow fetch from a read-only repo ok 32 - git clean -d with an unreadable empty directory ok 7 - with non-executable hook ok 8 - --no-verify with non-executable hook ok 13 - with non-executable hook ok 14 - with non-executable hook (editor) ok 15 - --no-verify with non-executable hook ok 16 - --no-verify with non-executable hook (editor) I'm not sure what is the best way forward, it seems as if CYGIN is half POSIX now. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Probably a bug with ~ symbol in filenames on Windows 7 x64 in git 1.9.5
On 01/08/2015 11:28 AM, Jeff King wrote: On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote: ICON~714.PNG is a valid short name for a long name (such as 'icon.background.png') because it fits the shortening scheme (8.3 format, the base name ends in ~n). As this can clash with a validly shortened long name, Git for Windows refuses to check out such paths by default. If you want the old -- unsafe -- behavior back, just set your core.protectNTFS to false (this means that you agree that the incurred problems are your own responsibility and cannot be blamed on anybody else ;-)) I wonder if it is worth having a git-only mode for core.protectNTFS. Turning it off entirely would make him susceptible to GIT~1 attacks. -Peff There is something more then just the tilde protection going on, it seems: torstenbogershausen@TORBOGWM ~/projects/test_tilde (master) $ ~/projects/git/msysgit/git ls-files ICON~714.PNG torstenbogershausen@TORBOGWM ~/projects/test_tilde (master) $ ~/projects/git/msysgit/git status On branch master nothing to commit, working directory clean torstenbogershausen@TORBOGWM ~/projects/test_tilde (master) $ ~/projects/git/tb/git status On branch master nothing to commit, working directory clean torstenbogershausen@TORBOGWM ~/projects/test_tilde (master) $ ~/projects/git/msysgit/git --version git version 1.9.2.msysgit.0.2273.gc47d6ec torstenbogershausen@TORBOGWM ~/projects/test_tilde (master) $ ~/projects/git/tb/git --version git version 2.2.1.268.g1e6f5b2 Neither latest msygit nor latest git.git reports a problem with a single file within a short path. It may be, that the '~' is not accepted in a long path or there are problems when a directory is filled with many files, but that is speculation. Dimitry, is there a way to make the problem reproducible for other people ? Either a public demo-repo, or a step-by-step receipe ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Probably a bug with ~ symbol in filenames on Windows 7 x64 in git 1.9.5
On 01/08/2015 04:58 PM, Johannes Schindelin wrote: Hi Torsten, On Thu, 8 Jan 2015, Torsten Bögershausen wrote: There is something more then just the tilde protection going on, [...] Indeed. What is going on is that you build Git yourself, from git.git, while Dmitry obviously used Git for Windows -- which carries a couple of patches on top of upstream git.git. In this particular case, the tilde protection was introduced in https://github.com/msysgit/git/commit/2e2a2d12. Ciao, Johannes My bad, I was building the msysgit master branch, which didn't have the 2e2a2d12. However, I am wondering if 2e2a2d12 is really needed that much ? In the same spirit that we do not prevent the checkout of FILE when file is present, why do we prevent people from using ~ in file names ? When a file is visible under different file names, I assume that the user chooses only one representation to run git add on. But that is another discussion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Probably a bug with ~ symbol in filenames on Windows 7 x64 in git 1.9.5
Hi Torsten, On Thu, 8 Jan 2015, Torsten Bögershausen wrote: There is something more then just the tilde protection going on, [...] Indeed. What is going on is that you build Git yourself, from git.git, while Dmitry obviously used Git for Windows -- which carries a couple of patches on top of upstream git.git. In this particular case, the tilde protection was introduced in https://github.com/msysgit/git/commit/2e2a2d12. Ciao, Johannes
Re: [msysGit] Re: Announcing Git for Windows 1.9.5
On 2014-12-23 10.48, Pat Tressel wrote: Bugfixes - Safeguards against bogus file names on NTFS (CVE-2014-9390). Apologies, but...is it possible to get back an old version? I installed this version, and it no longer recognizes non-English characters that appear in some file names we have in our repo. I'm only guessing that this has to do with the vuln fix. (If you want, I can file a bug report -- this should be easy to reproduce, as all that's needed should be to clone our repo (https://github.com/flavour/eden) and do git status -- two files will appear as deleted, but they're not. Hmm, it may be necessary to do the git clone with an old version, if the new version is unable to handle those file names.) Thanks! -- Pat You may consider to convert the repo into unicode, and update all clients accessing this repo. https://github.com/kblees/git/wiki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Announcing Git for Windows 1.9.5
Hi Stanzilla, On Thu, 18 Dec 2014, Stanzilla wrote: Release notes at https://github.com/msysgit/msysgit/raw/master/share/WinGit/ReleaseNotes.rtf are *not* up to date. Yep, the 'master' branch is intentionally behind. It will be updated tomorrow, as well as the msysgit/git.git repository. The installer was updated, which you are welcome to download and install. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFC 3/4] engine.pl: split the .o and .obj processing
From: Johannes Schindelin johannes.schinde...@gmx.de
How about the following instead?
+ } elsif ($part eq 'invalidcontinue.obj') {
+ # ignore
} elsif ($part =~ /\.(o|obj)$/) {
Looks good, I'll use that (after deciding whether .obj files should
be
expected in a 'make' output anyway)
My idea to hardcode invalidcontinue.obj was that I'd rather see a
failure
if an unexpected .obj is seen there. But I realize that my suggested
change does not exactly accomplish that.
I've decided to include the hard code suggested, and after a few tests
decided it was probably worth keeping the .obj processing, even though
we don't expect any.
At least I've now managed to generate a .sln project, though it won't
compile because of a number of other changes, and I haven't got to the
bottom of them all.
Notes:
Revert Windows: correct detection of EISDIR in mingw_open()
git\compat\mingw.c(315) : error C2065: 'O_ACCMODE' : undeclared
identifier (neither VS2008 nor VS2010 declare 'O_ACCMODE'). add an
#ifdef
_MSC_VER to define this if we are in MSVC.
Revert mingw.h: add dummy functions for sigset_t operations commit
4e6d207c45. the Additional Note: to
http://www.spinics.net/lists/git/msg240248.html indicates that this
breaks MSVC. I think it will also need an #ifdef to see if we are in
MSVC.
I've also found a problem with my setup (msysgit 1.7.9 for make) barfing
on the commit/ee9be06 perl: detect new files in MakeMaker builds which
'make -n' says 'No rule to make target `PM.stamp', needed by `perl.mak'.
There was also LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts
with use of other libs; use /NODEFAULTLIB:library.
I've also got notes from way back that there was build order problem
with 'vcs-svn_lib.lib' - probably a sort order issue. IIRC at that time,
I had to compile the project twice so that the lib was visible the
second time.
So there's plenty to go at ;-) I'm going to be away this coming week, So
at least I have the whole next cycle to make some progress.
--
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: msysgit works on wine
Hi Michael, On Mon, 13 Oct 2014, Michael Stefaniuc wrote: On 10/10/2014 02:04 PM, Duy Nguyen wrote: On Fri, Oct 10, 2014 at 7:02 PM, Thomas Braun Are you compiling git.git or msysgit.git? git.git And how about the test suite? running right now, fingers crossed.. kinda slow, not sure if it's wine or it's the msys thing. We (Wine) are interested in bug reports for git tests failing on Wine that succeed on Windows/Linux. Performance issues compared to Windows are highly desired too. Awesome, thank you for the offer! I haven't tried this in a long time, mainly because at some stage Wine required a separate console from my terminal to run command-line programs. And it seemed to me as if in particular process-spawning and heavy-duty file system operations were the bottleneck. Hopefully I will find some time soon to perform those tests again. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 13/14] git-compat-util.h: fix integer overflow on IL32P64 systems
Hi Junio, On Wed, 8 Oct 2014, Junio C Hamano wrote: Marat Radchenko ma...@slonopotamus.org writes: #define DEFAULT_PACKED_GIT_LIMIT \ - ((1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256)) + ((size_t)(1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256)) 1024 * 1024 * 8192 overflows 32-bit unsigned, but is size_t always large enough? Just checking. The diff is a bit misleading as to what it *actually* changes. It *just* casts the result to size_t. The arithmetic is performed with longs (thanks to the l in 1024l) and it only overflows 32 bit iff the sizeof() test verifies that we're at least on 64 bit -- this arithmetic operation is the same as before the patch. I was fooled by the diff myself (adding another parenthesis just to add the cast would probably have helped, though). IMHO this is a good demonstration how a commit message that goes slightly beyond the necessary can help tons of time by avoiding to let every reviewer/reader go through the exact same steps of puzzlement. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 14/14] MINGW: config.mak.uname: auto-detect MinGW build from compiler
Hi Junio, On Thu, 9 Oct 2014, Junio C Hamano wrote: Marat Radchenko ma...@slonopotamus.org writes: On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote: ... What I am wondering is if it is a better solution to make it easier to allow somebody who is cross compiling to express Mr. Makefile, we know better than you and want you to do a MINGW build for us without checking with `uname -?` yourself, i.e. $ make uname_O=MINGW uname_S=MINGW which would hopefully allow cross-compilation into other environments, not just MINGW. So, do you really want this patch to be changed from 5-liner into a full-blow system detection rewrite based on `cc -dumpmachine` instead of `uname`? No, and I do not quite see why you even need to look at -dumbmachine Nice Freudian ;-) output when your goal is to make this command line $ make uname_O=MINGW uname_S=MINGW work sensibly. Wouldn't it be more like a series of ifndef uname_O uname_O := $(shell uname -o) endif or something like that? Or uname_O ?= $(shell uname -o) To clarify: it would be enough to look at CROSS_COMPILE to determine whether we're cross-compiling for MinGW. The output of -dumpmachine is still needed for the correct CFLAGS/LDFLAGS. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 14/14] MINGW: config.mak.uname: auto-detect MinGW build from compiler
Hi Junio, On Thu, 9 Oct 2014, Junio C Hamano wrote: Isn't the primary reason we use colon-assign to avoid running the same $(shell) over and over again every time $(uname_?) gets referenced? How would it work with ?= ??? I was under the impression that ?= would only define the variable once, the next time ?= would be encountered, no assignment (and actually, no evaluation) would take place because the variable already has a value? According to https://www.gnu.org/software/make/manual/make.html#index-_003f_003d FOO ?= bar is exactly equivalent to this (see The origin Function): ifeq ($(origin FOO), undefined) FOO = bar endif Pardon misspellings and grammos, typed on a tablet. No worries. But you really should use your tablet for reading books after midnight instead of doing work... ;-) Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 14/14] MINGW: config.mak.uname: auto-detect MinGW build from compiler
Hi Junio, On Thu, 9 Oct 2014, Junio C Hamano wrote: I didn't mean multiple uses of ?= for the same variable. I meant multiple uses of (references to) the variable. I.e. wouldn't FOO and BAR behave differently below? FOO := $(shell random) BAR = $(shell random) all:: echo $(FOO) and $(BAR) echo twice $(FOO) and $(BAR) You're correct, of course, my mistake. I just tested with this: R ?= $(shell echo $$RANDOM) all: echo The values of $(R), $(R) and $(R) and of course a make yields three different numbers. Sorry for missing that. So what we should do is something like ifeq ($(uname_S),) uname_S := $(shell uname -s) endif even if repeating that pattern is kind of ugly... Thanks for correcting my mistake, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
Hi Marat, On Wed, 8 Oct 2014, Marat Radchenko wrote: On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote: I wanted to verify that on msysgit but some patches fail to apply cleanly. Did you also had to tweak the patches? If yes, are these tweaked patches still available somewhere? msysgit != git-for-windows, as msysgit folks say. That's not what msysgit folks say (they say that msysgit is the development environment to build Git for Windows [*1*]), and Thomas is well aware of the situation because he is a busy contributor on the Windows side. I tested my patches by applying them to git.git/master and building inside msysgit. So the idea would be to rebase from git/git/master onto msysgit/git/master. Did you do that yet? Ciao, Johannes Footnote *1*: msysgit is about to be phased out. As soon as https://github.com/git-for-windows/sdk is able to produce a Git for Windows installer (it already able to build Git and pass the test suite), we will switch to the new development environment and mark msysgit as obsolete, keeping it around only for reference. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote: Hi Marat, On Wed, 8 Oct 2014, Marat Radchenko wrote: That's not what msysgit folks say (they say that msysgit is the development environment to build Git for Windows [*1*]). Aaargh! msys != msysgit != Git for Windows SDK != Git for Windows != mingwGitDevEnv and possibly != git-for-windows. Oh, there's also mingw-w64-git from msys2 [1]. I tested my patches by applying them to git.git/master and building inside msysgit. So the idea would be to rebase from git/git/master onto msysgit/git/master. Did you do that yet? No, what for? Windows flavors of Git are already fragmented too much, my patchset is deliberately targeted at Git upstream. [1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-git -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
Hi Thomas, On Wed, 8 Oct 2014, Thomas Braun wrote: I wanted to verify that on msysgit but some patches fail to apply cleanly. Did you also had to tweak the patches? I applied the patches to git-for-windows/git's master, manually fixing three of them, and pushed the result to the 'w64' branch in my fork. Please find them here: https://github.com/dscho/git/compare/git-for-windows:master...w64 and rebased onto msysgit's master: https://github.com/dscho/git/compare/msysgit:master...w64-msysgit Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
Hi Marat, On Wed, 8 Oct 2014, Marat Radchenko wrote: On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote: So the idea would be to rebase from git/git/master onto msysgit/git/master. Did you do that yet? No, what for? To work together? If you are not interested in working together to make Git on 64-bit Windows kick-ass, just say so. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v4] MinGW(-W64) compilation
Am 06.10.2014 um 07:17 schrieb Marat Radchenko: On Tue, Sep 30, 2014 at 11:02:29AM +0400, Marat Radchenko wrote: This patch series fixes building on modern MinGW and MinGW-W64 (including x86_64!). Junio, ping? Sorry, I forgot to report that this updated series works now for me. The patches all look reasonable. I don't have an opinion on the restriction that MSVC 2010 can't be used anymore (path 08/14). -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Hi Junio, On Mon, 21 Jul 2014, Junio C Hamano wrote: Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? I guess that is my mistake; when I introduced the use of NOT_MINGW I was simply unaware of the !MINGW syntax. Let's use the latter consistently? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Am 21.07.2014 19:45, schrieb Johannes Schindelin: Hi Junio, On Mon, 21 Jul 2014, Junio C Hamano wrote: Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? I guess that is my mistake; when I introduced the use of NOT_MINGW I was simply unaware of the !MINGW syntax. You can hardly be blamed. The first occurrence of NOT_MINGW was added much earlier than the ability to negate prerequisite tokens. Let's use the latter consistently? Of course! -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 00/13] mingw unicode environment
Hello Karsten, you wrote: However, if it *did* compile for you, I wonder where ALLOC_GROW (as of #02/13) and alloc_nr (as of #10/13) came from? Or did we recently remove '#include cache.h' from upstream mingw.c? you are right, the include needs to be added. To test my modifications, I rebased all the rest of msysGit collection, built and run the test suite. As you pointed out, https://github.com/msysgit/git/commit/d85d2b75 adds the include. Unfortunately, I won't get to this for several weeks. Could you or Hannes be so kind and post the fixup? Thank you for this comment. And big thanks for the orignal work. (I was only moving it and even that took some time. ;-) Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Topic sk/mingw-unicode-spawn-args breaks tests
Hi Stepan, On Sat, 12 Jul 2014, Stepan Kasal wrote: Am 10.07.2014 22:05, schrieb Johannes Sixt: It looks like I totally missed the topic sk/mingw-unicode-spawn-args. ... Am I doing something wrong? Does the topic depend on a particular version of MSYS (or DLL)? unfortunately, I paused my submissions at random point. ;-) I'm sorry for breaking your setup. I was not aware there is any working Windows setup beyond msysGit. There is one other, very notable development environment relevant to Git for Windows: https://github.com/sschuberth/mingwGitDevEnv. It is slated to be the development environment to produce Git for Windows starting with version 2.0.0. I have pretty concrete plans to work on that switch, which will most likely also affect Hannes (who has so far successfully resisted to develop Git using the msysGit environment). Those plans to step up my efforts regarding Git for Windows imply my spending more time on the project again, subject to a couple of things that are still being hashed out. Stay tuned, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Torsten Bögershausen tbo...@web.de writes: No, it hadn't, under my Linux box. (And I had a .gittatributes file on the Mac OS box, which I forgot about. OK, that explains the difference; thanks for double-checking. Files with mixed LF CRLF in the repo are not changed by Git, when the checkout out or checked in, unless the .gitattributes say that the file is text. Hmph, I would have thought, after reading the Does anybody do that crazy stuff comment in convert.c, that we refrain from attempting to convert a file with a mixed mess, even if the file is marked as text, because it is unclear what it means to have both LF and CRLF in a file that is text. Is A\rB\nC\r\n a line terminated with a CRLF that happens to have a lone CR and then LF in between? You may be looking at a bug in a corner case that is so irrelevant that nobody has even noticed, let alone attempted to fix. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
On 2014-06-20 18.33, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n In Documentation/config.txt, we find: core.eol:: Sets the line ending type to use in the working directory for files that have the `text` property set. Alternatives are ... Does that file $t in your practice have the `text` property set? No, it hadn't, under my Linux box. (And I had a .gittatributes file on the Mac OS box, which I forgot about. I am really sorry for the confusion and saying that Git behaves different under Linux and Mac OS). You are pointing into the right direction: Files with mixed LF CRLF in the repo are not changed by Git, when the checkout out or checked in, unless the .gitattributes say that the file is text. And libgit2 should do the same. However, I was confused by this https://www.kernel.org/pub/software/scm/git/docs/git-config.html (My comments inline with ##) --- core.autocrlf Setting this variable to true is almost the same as setting the text attribute to auto on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. ## And is this line still valid: Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. ## In 2010 the the new safer autocrlf handling was introduced, ## and it looks as if commits fd6cce9e and c4805393 are involved here. ## When the file in the repo has only LF, it will have CRLF in the work tree ## When the file in the repo has mixed LF and CRLF, it will not be changed in the work tree ## and will have mixed line endings in the work tree ## When the file in the repo has only CRLF, it will not be changed in the work tree ## and will have CRLF in the work tree as well as in the repo. ##Should this line simply be dropped in the documentation ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Wow! P.S. libgit2 just has a PR that try to be identical with official git. See https://github.com/libgit2/libgit2/pull/2432 Yue Lin Ho I am not sure how much problems Git/libgit2 have with files contains mixed LF-CRLF, as I have the same problem with the LF.txt The handling, according to my understandig, is: When core.eol is CRLF (or native under Windows) and core.autocrlf is true, and a file is checked out: If a file has CRLF in one line in the repo, nothing is changed. If a file has LF in one line in the repo, LF is converted into CRLF in the workspace. But here at my systems this doesn't seem to work as expected either for LF.txt: tb@mac:~/EOL_Test/TestAutoCrlf t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000L i n e 1 \r \n l i n e ( 2 ) 020 \r \n l i n e 3 . \r \n t h i s 040i s l i n e 4 \r \n l i n 060e N o . 5 \r \n L i n e N 100u m b e r 6 \r \n \r \n == tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Torsten Bögershausen tbo...@web.de writes: tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n In Documentation/config.txt, we find: core.eol:: Sets the line ending type to use in the working directory for files that have the `text` property set. Alternatives are ... Does that file $t in your practice have the `text` property set? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 0/7] Second part of msysgit/unicode
Am 18.06.2014 19:33, schrieb Junio C Hamano: In the meantime, are Windows folks happy with the four topics queued on 'pu' so far? I would like to start moving them down to 'next' and to 'master' soonish. They consist of these individual patches: $ git shortlog ^master \ sk/mingw-dirent \ sk/mingw-main \ sk/mingw-uni-console \ sk/mingw-unicode-spawn-args Topic sk/test-cmp-bin revealed a new breakage in t5000-tar-tree, specifically, the penultimate test remote tar.gz is allowed by default. I have yet to find out what it is (I suspect a LF-CRLF conversion issue) and whether it is in connection with one of these topics. I haven't had a chance to test the topics in the field. In particular, I have a few files with Shift-JIS content (but ASCII file names), and I would like to see how well I fare with the unicode topics in this situation. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 3/5] Warn if the Windows console font doesn't support Unicode
Hi, On Fri, Jun 06, 2014 at 10:18:43PM +0100, Peter Krefting wrote: Stepan Kasal: +switching to a TrueType font such as Lucida Console!); [...] modernizing the suggestion here to recomment Consolas. It is available Indeed. So, I'll keep this patch as it is, for the records, and apply your suggestion to the subsequent [PATCH 5/5] Win32: Thread-safe windows console output Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 0/5] First part of Unicode console support for msysgit
Hello Karsten, On Fri, Jun 06, 2014 at 07:44:33PM +0200, Karsten Blees wrote: Nicely done, thanks! thank you for your kind words. Please hold back, I will re-submit in a few days. Note: this one was submitted seperately on May 29 and May 1 (can't find it in the gmane archive, though). It was cc'ed to msysgit as usual and gmane selected it as the primary place to store it: http://thread.gmane.org/gmane.comp.version-control.msysgit/20324 regards, Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 0/5] First part of Unicode console support for msysgit
Hello, On Fri, Jun 06, 2014 at 07:44:33PM +0200, Karsten Blees wrote: Karsten Blees (5): Support Unicode console output on Windows [..] you could have squashed half of Win32: fix segfault in WriteConsoleW when debugging in gdb [2] (second half in [5/5]). Detect console streams more reliably on Windows Warn if the Windows console font doesn't support Unicode I think this one includes MSVC: fix winansi.c compile errors [3] and Unicode console: fix font warning on Vista and Win7 [4] [...] Win32: move main macro to a function Win32: Thread-safe windows console output [2] https://github.com/msysgit/git/commit/cd0792af [3] https://github.com/msysgit/git/commit/3abcb04d [4] https://github.com/msysgit/git/commit/981aa538 Indeed, you identified them correctly. And [2] is actually squashed in [5/5]; I think I can keep it that way. I'll add the missing fix, take care about original dates, improve the cover letter (the above links), and resubmit. Thanks for review this batch of your patches. Regards, Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi Karsten, On Thu, 5 Jun 2014, Karsten Blees wrote: After a bit of digging in the history and the old googlegroups issue tracker, I think this patch is completely unrelated to the non-ASCII problems. Actually, the non-ASCII problems were the trigger for my patch. In summary, this patch fixes 'git config' for the portable version only, and it only does so partially. Care to elaborate? Am 04.06.2014 17:46, schrieb Johannes Schindelin: I would be strongly in favor of fixing the problem by the root: avoiding to have Git rely on the HOME environment variable to be set, but instead add a clean API call that even says what it is supposed to do: gimme the user's home directory's path. And that is exactly what the patch does. By that argument we'd have to introduce API abstractions for every environment variable that could possibly resemble a path (PATH, TMPDIR, GIT_DIR, GIT_WORK_DIR, GIT_TRACE* etc.). But of course you are mixing things here. GIT_* are purely Git-specific constructs, so there is no possibility for confusion. PATH and TMPDIR need to be handled specially (as does HOME) because we are reusing environment variable concepts that pose their own set of problems on Windows because of the separator, the path separator and the encoding problems. I understand that it is easy to confuse my want for a API function for the home variable with handling for other environment variables. But that HOME is an environment variable is not the point at all! It just *happens* to be an environment variable on Linux/Unix. We already have similar fallback logic for TMPDIR that is completely non-intrusive to core git code (fully encapsulated in mingw.c, see mingw_getenv (upstream) or mingw_startup (msysgit)). IMO such a solution would be hugely preferable over adding an additional get_home_directory() API (and continuously checking that no new upstream code accidentally introduces another 'getenv(HOME)'). Well, since you mention that TMPDIR hack: this is a hack. We are bending over in order for upstream not having to accomodate non-POSIX operating systems. But how much cleaner would it be if there was an API call with varargs. After all, by the reasoning TMPDIR is a standard on Unix you would also have to special case /tmp/ in all the open/opendir/etc functions because the temporary directory is /tmp/ on Linux/Unix, right? Render me even more convinced that the API call is the cleanest way to go, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi, On Thu, Jun 05, 2014 at 02:03:39PM +0200, Johannes Schindelin wrote: Render me even more convinced that the API call is the cleanest way to go, But not me. In a paralel post, Duy Nguyen wrote: Thank you for working on pushing msysgit patches upstream. I don't use git on windows, but it's nice to see all windows-specific changes in one code base so we can try to workaround it when new patches/features are developed. ... but we should not obscure that more than necessary. If the API call is getenv(HOME); it helps. And the hack with mingw_getenv() is not that bad, so we should be pragmatic and accept it. Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Am 05.06.2014 14:03, schrieb Johannes Schindelin: Hi Karsten, On Thu, 5 Jun 2014, Karsten Blees wrote: After a bit of digging in the history and the old googlegroups issue tracker, I think this patch is completely unrelated to the non-ASCII problems. Actually, the non-ASCII problems were the trigger for my patch. The commit message explicitly claims that it fixes issue 482, which is: 'git config --global' in the portable version fails with fatal: $HOME not set (not unable to access '...', which you would get for a mangled path that doesn't exist). As outlined in the previous mail (analysis 1.), the non-ASCII problem is caused by a bug in msys.dll, and it is in fact impossible to fix in git (even if that was your intention). In summary, this patch fixes 'git config' for the portable version only, and it only does so partially. Care to elaborate? See previous mail analysis 3. In short: it doesn't work with disconnected home share (issue 259), and it doesn't setenv(HOME) (so child processes such as git-gui will most likely fail). Am 04.06.2014 17:46, schrieb Johannes Schindelin: I would be strongly in favor of fixing the problem by the root: avoiding to have Git rely on the HOME environment variable to be set, but instead add a clean API call that even says what it is supposed to do: gimme the user's home directory's path. And that is exactly what the patch does. By that argument we'd have to introduce API abstractions for every environment variable that could possibly resemble a path (PATH, TMPDIR, GIT_DIR, GIT_WORK_DIR, GIT_TRACE* etc.). But of course you are mixing things here. GIT_* are purely Git-specific constructs, so there is no possibility for confusion. PATH and TMPDIR need to be handled specially (as does HOME) because we are reusing environment variable concepts that pose their own set of problems on Windows because of the separator, the path separator and the encoding problems. I understand that it is easy to confuse my want for a API function for the home variable with handling for other environment variables. But that HOME is an environment variable is not the point at all! It just *happens* to be an environment variable on Linux/Unix. We already have similar fallback logic for TMPDIR that is completely non-intrusive to core git code (fully encapsulated in mingw.c, see mingw_getenv (upstream) or mingw_startup (msysgit)). IMO such a solution would be hugely preferable over adding an additional get_home_directory() API (and continuously checking that no new upstream code accidentally introduces another 'getenv(HOME)'). Well, since you mention that TMPDIR hack: this is a hack. We are bending over in order for upstream not having to accomodate non-POSIX operating systems. Exactly. In order to support different platforms, we need to agree on a common abstraction layer to access platform-specific functionality. For the git project, this common abstraction layer happens to be the POSIX standard (actually: the subset of the standard that is used by core git code). And compat/mingw.c implements that abstraction layer for the native Windows platform. There are cases where conforming to the standard is simply not feasible, e.g. fork() (we don't want to build another cygwin). So we sometimes need special handling for certain functionality in core-git (see run-command.c in case of fork()). However, getenv(HOME), getenv(TMPDIR) and getenv(PATH) are all fully POSIX compliant, including the standardised variable names. In this particular case, conforming to the standard (via special handling in mingw_getenv or mingw_startup) is actually even _simpler_ than inventing a new, non-standard, undocumented get_home_directory() API. But how much cleaner would it be if there was an API call with varargs. After all, by the reasoning TMPDIR is a standard on Unix you would also have to special case /tmp/ in all the open/opendir/etc functions because the temporary directory is /tmp/ on Linux/Unix, right? No, POSIX doesn't specify path names. The standard way to get the temp directory is 'getenv(TMPDIR)'. A hardcoded /tmp in core git code would be a bug. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] mingw: redefine the wrapper macro after the corresponding function
Hello Karsten, On Thu, Jun 05, 2014 at 04:51:39PM +0200, Karsten Blees wrote: In the current msysgit HEAD, most of these #undef's can simply be removed or have already been removed [...] not most of. According to my quick count, 6 of 20 have been removed, 2 more can be removed. The remaining 12 do play their role. (The point you overlooked is that there are several socket related, like bind().) If you apply this patch in msysgit, you'll most likely get compile errors due to redefining macros. It would be warnings only. But a quick test shows that redefining with identical definition does not trigger the warning. Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] mingw: redefine the wrapper macro after the corresponding function
Am 05.06.2014 17:13, schrieb Stepan Kasal: Hello Karsten, On Thu, Jun 05, 2014 at 04:51:39PM +0200, Karsten Blees wrote: In the current msysgit HEAD, most of these #undef's can simply be removed or have already been removed [...] not most of. According to my quick count, 6 of 20 have been removed, 2 more can be removed. The remaining 12 do play their role. (The point you overlooked is that there are several socket related, like bind().) Right, premature generalization on my part from looking at the first two or so entries. However, I suspect some of the remaining 12 could be improved so that no #undef is necessary. E.g. gethostbyname could probably be implemented using GetAddrInfoW (supports non-ASCII names and IPv6). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t5000, t5003: do not use test_cmp to compare binary files
Hi Stephan, Am 04.06.2014 14:42, schrieb Stepan Kasal: On Wed, Jun 04, 2014 at 02:13:44PM +0200, Thomas Braun wrote: Wouldn't a function like test_cmp_bin() be better suited for all? I also considered it. The advantage is that is shows that this intentionally differs from test_cmp. The windows folks can then use cmp inside test_cmp_bin() and all others ... would use cmp as well because it is better suited for the task than diff -u. So test_cmp_bin would be just an alias for cmp, on all platforms. Doesn't that sound weird? I actually like the idea that the test assertions follow a common naming scheme and can easily be overriden by $arbitrary-crazy-platform. Using test_cmp_bin instead of cmp would result in then four assertions for comparing arbitrary data test_cmp test_18ncmp test_cmp_text test_cmp_bin where I think the purpose of each function is clear from its name. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than get_home_directory(),
but that's really weak argument as the number of call sites has not
increased in 4 years.
Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in
/etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really
need one more place?
It seems some of these could be dropped...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Am 04.06.2014 16:05, schrieb Erik Faye-Lund:
On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than get_home_directory(),
but that's really weak argument as the number of call sites has not
increased in 4 years.
Setting the variable instead of wrapping getenv has the additional benefit that
it also affects child processes (read: scripted commands).
Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in
/etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really
need one more place?
...all of these also do the string concatenation correctly (i.e. not
C:/\Users\MyName as this patch does), fall back to %USERPROFILE% if
%HOMEPATH% is not set, and most (except git-wrapper) even check that the
directory exists. So IMO this patch has been superseded by more robust
solutions and should be dropped.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi Duy,
On Wed, 4 Jun 2014, Duy Nguyen wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than get_home_directory(),
but that's really weak argument as the number of call sites has not
increased in 4 years.
There is a good reason why we did not go for that (noticably cheaper)
solution. In fact, it used to be our solution until too many things got
broken by setting the HOME variable: Git is not the only program making
use of that variable (and IIRC Putty or a merge helper got seriously
confused when we set it).
So I am afraid, no, we cannot simply setenv(HOME).
Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi Erik,
On Wed, 4 Jun 2014, Erik Faye-Lund wrote:
On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than get_home_directory(),
but that's really weak argument as the number of call sites has not
increased in 4 years.
Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in
/etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really
need one more place?
It seems some of these could be dropped...
No. Git is not always called through Bash or the git-wrapper,
unfortunately.
Ciao,
Dscho
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
On Wed, Jun 4, 2014 at 5:14 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi Erik,
On Wed, 4 Jun 2014, Erik Faye-Lund wrote:
On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than get_home_directory(),
but that's really weak argument as the number of call sites has not
increased in 4 years.
Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in
/etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really
need one more place?
It seems some of these could be dropped...
No. Git is not always called through Bash or the git-wrapper,
unfortunately.
I'm aware of that. But you said in a previous e-mail that e.g putty
got confused when we set HOME. How is this a problem for git.exe, but
not when we set it in the shell?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi kusma,
On Wed, 4 Jun 2014, Erik Faye-Lund wrote:
On Wed, Jun 4, 2014 at 5:14 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Wed, 4 Jun 2014, Erik Faye-Lund wrote:
On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal ka...@ucw.cz wrote:
@@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
- char *home = getenv(HOME);
+ const char *home = get_home_directory();
char *to_free = NULL;
if (!home) {
Just checking. Instead of replace the call sites, can we check and
setenv(HOME) if it's missing instead? MinGW port already replaces
main(). Extra initialization should not be a problem. I feel
getenv(HOME) a tiny bit more familiar than
get_home_directory(), but that's really weak argument as the number
of call sites has not increased in 4 years.
Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in
/etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really
need one more place?
It seems some of these could be dropped...
No. Git is not always called through Bash or the git-wrapper,
unfortunately.
I'm aware of that. But you said in a previous e-mail that e.g putty got
confused when we set HOME. How is this a problem for git.exe, but not
when we set it in the shell?
The problem arises whenever git.exe calls subprocesses. You can pollute
the environment by setting HOME, I do not recall the details, but I
remember that we had to be very careful *not* to do that, hence the patch.
Sorry, has been a long time.
Ciao,
Dscho
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi dscho, On Wed, Jun 4, 2014 at 5:14 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: No. Git is not always called through Bash or the git-wrapper, unfortunately. but you have to admit, that in most cases it is called through bash or the git wrapper. The problem arises whenever git.exe calls subprocesses. You can pollute the environment by setting HOME, I do not recall the details, but I remember that we had to be very careful *not* to do that, hence the patch. Sorry, has been a long time. Yeah, memories. Is this experience still valid? How many users do profit from this, using c:/Program\ Files \(86\)/bin/git.exe instead of c:/Program\ Files \(86\)/cmd/git.exe, either by pure luck or intentionally? It seems that we should keep the patch, to minimize surprise if bin/git.exe is used directly. But we should probably make it consistent with other places: - $HOMEDRIVE$HOMEPATH (without the slash) - $USERPROFILE if the above dir does not exist. - setenv HOME instead of wrapper We can make this change for msysGit 2.0.0 only, so that we do not break 1.9.4 ;-) Does this make sense? Stepan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi kusma, On Wed, 4 Jun 2014, Johannes Schindelin wrote: The problem arises whenever git.exe calls subprocesses. You can pollute the environment by setting HOME, I do not recall the details, but I remember that we had to be very careful *not* to do that, hence the patch. Sorry, has been a long time. Actually, a quick search in my Applegate vaults^W^Wmail archives suggests that we had tons of troubles with non-ASCII characters in the path. Given that none of us really has time to recreate the problems, or to take care of them if there arises a new problem due to setting the HOME variable again (remember: while we have UTF-8 support in Git, thanks to Karsten's tireless efforts, and while that seems to fix the biggest bugs for us, other MinGW software does not have that luxury and will continue to barf on non-ASCII characters in the HOME variable), I would be strongly in favor of fixing the problem by the root: avoiding to have Git rely on the HOME environment variable to be set, but instead add a clean API call that even says what it is supposed to do: gimme the user's home directory's path. And that is exactly what the patch does. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi Stepan, On Wed, 4 Jun 2014, Stepan Kasal wrote: On Wed, Jun 4, 2014 at 5:14 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: No. Git is not always called through Bash or the git-wrapper, unfortunately. but you have to admit, that in most cases it is called through bash or the git wrapper. It would seem so. But the plan was always to make the user experience on Windows less abysmal than now (I just do not have enough time these days to pursue that goal myself), which includes the goal to make git.exe the main entrance point, not Bash nor the git-wrapper. The problem arises whenever git.exe calls subprocesses. You can pollute the environment by setting HOME, I do not recall the details, but I remember that we had to be very careful *not* to do that, hence the patch. Sorry, has been a long time. Yeah, memories. *Very* vague. Sorry. Is this experience still valid? How many users do profit from this, using c:/Program\ Files \(86\)/bin/git.exe instead of c:/Program\ Files \(86\)/cmd/git.exe, either by pure luck or intentionally? Keep in mind that the most problems were introduced by the fact that USERPROFILE disagrees with HOMEDRIVE\HOMEPATH at times. It seems that we should keep the patch, to minimize surprise if bin/git.exe is used directly. I am also in favor of keeping the patch because it introduces a bit of documentation. It says pretty precisely what it wants and allows platform-specific handling without having to play games with the environment, as was suggested earlier. And of course you cannot deny that it had four years of testing. The HOME problems never came back after we included this patch. But we should probably make it consistent with other places: - $HOMEDRIVE$HOMEPATH (without the slash) - $USERPROFILE if the above dir does not exist. - setenv HOME instead of wrapper Possibly. But again, it is hard to argue with four years of testing. Any change you make now will lack that kind of vetting. We can make this change for msysGit 2.0.0 only, so that we do not break 1.9.4 ;-) So we can break 2.0.0! ;-) Actually, 2.0.0 for Windows needs to wait a little longer (it is a little bit unfortunate that we could not coordinate it with upstream) because the plan is to switch to mingwGitDevEnv for said release. No more msysGit. Like, bu-bye. Thanks for all the fish. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi dscho, your arguments seem really strong. (Especially the four years of battle testing, with the memories of constant problems with HOME before.) I hope they are strong enough to convince Junio to accept this patch; that would help. Stepan PS (about mingwGitDevEnv): plan is to switch to mingwGitDevEnv for said release. No more msysGit. Like, bu-bye. Thanks for all the fish. Interesting. With msysgit, there is the net installer - first time I installed msys/mingw sucessfully, it was as easy as Cygwin, perhaps even easier. When I go to mingwGitDevEnv home page, I read about chickens, eggs, and upgrading Perl (which msysGit simply gives up, hinting that it is almost impossible). So I decided to wait for their Git 2.0.0 release before I try to install it (again). I apologize for being so cheeky, I hope it will help anyway... PPS: from marketing point of view, mingwGitDevEnv is far from usable name. Dscho, if you support the idea, would you mind franchising msysGit 2.0 for a decent amount? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Hi Stepan, On Wed, 4 Jun 2014, Stepan Kasal wrote: PS (about mingwGitDevEnv): plan is to switch to mingwGitDevEnv for said release. No more msysGit. Like, bu-bye. Thanks for all the fish. Interesting. With msysgit, there is the net installer - first time I installed msys/mingw sucessfully, it was as easy as Cygwin, perhaps even easier. When I go to mingwGitDevEnv home page, I read about chickens, eggs, and upgrading Perl (which msysGit simply gives up, hinting that it is almost impossible). So I decided to wait for their Git 2.0.0 release before I try to install it (again). I understand. And now that upstream Git 2.0.0 is out, it will be very hard to use that as a deadline to push against. So: don't hold your breath. PPS: from marketing point of view, mingwGitDevEnv is far from usable name. Dscho, if you support the idea, would you mind franchising msysGit 2.0 for a decent amount? Make me an offer :-P Seriously again, I am in favor of calling it the Git for Windows SDK. But really, it is bikeshedding at this point. There is real work to do, still, before we can switch. Lots of unaddressed questions. Too little time. Speaking of which... budget's depleted for today ;-) Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
On Wed, Jun 4, 2014 at 11:16 PM, Stepan Kasal ka...@ucw.cz wrote: Hi dscho, your arguments seem really strong. (Especially the four years of battle testing, with the memories of constant problems with HOME before.) I hope they are strong enough to convince Junio to accept this patch; that would help. I think you should include the problems Dscho described in the commit message too. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] Add a Windows-specific fallback to getenv(HOME);
Am 04.06.2014 17:46, schrieb Johannes Schindelin: Hi kusma, On Wed, 4 Jun 2014, Johannes Schindelin wrote: The problem arises whenever git.exe calls subprocesses. You can pollute the environment by setting HOME, I do not recall the details, but I remember that we had to be very careful *not* to do that, hence the patch. Sorry, has been a long time. Actually, a quick search in my Applegate vaults^W^Wmail archives suggests that we had tons of troubles with non-ASCII characters in the path. After a bit of digging in the history and the old googlegroups issue tracker, I think this patch is completely unrelated to the non-ASCII problems. In summary, this patch fixes 'git config' for the portable version only, and it only does so partially. Thus I don't think its ready for upstream, at least not in its current form. See below for the nasty details. I would be strongly in favor of fixing the problem by the root: avoiding to have Git rely on the HOME environment variable to be set, but instead add a clean API call that even says what it is supposed to do: gimme the user's home directory's path. And that is exactly what the patch does. By that argument we'd have to introduce API abstractions for every environment variable that could possibly resemble a path (PATH, TMPDIR, GIT_DIR, GIT_WORK_DIR, GIT_TRACE* etc.). We already have similar fallback logic for TMPDIR that is completely non-intrusive to core git code (fully encapsulated in mingw.c, see mingw_getenv (upstream) or mingw_startup (msysgit)). IMO such a solution would be hugely preferable over adding an additional get_home_directory() API (and continuously checking that no new upstream code accidentally introduces another 'getenv(HOME)'). Cheers, Karsten Analysis of $HOME-realted issues: 1. mangled non-ASCII characters in environment variables E.g. issue 491 [1], reportedly fixed in v1.7.10 ([1] comment #10). This is actually a bug in msys.dll, and there's nothing that can be done about it from within git.exe. It is also not a problem if git is launched from cmd.exe. The root cause is that the msys environment is initialized using GetEnvironmentStringsA(), which returns GetOEMCP()-encoded strings (e.g. cp850), rather than GetACP() (e.g. cp1252) as all other *A API functions do [2]. This adds one level of mangling whenever a native Windows program starts an msys program (so e.g. the call chain bash-git-bash-wish would mangle twice, see [1] comment #3). For the fixed GetEnvironmentStringsA(), see [3] lines 459ff. (As a side note, $HOMEDRIVE and $HOMEPATH originally did not have this problem, as they were separately initialized from NetUserGetInfoA(). This was changed in v1.6.3, however, at that time etc/profile was still using the broken $USERPROFILE. See [4], [5].) 2. 'git config' doesn't work with disconnected network drives Issues 259 [6], 497 [7] and 512 [8], fixed in v1.7.0.2 for bash and v1.7.2.3 for cmd. Apparently, $HOMEDRIVE$HOMEPATH is the home directory on the network, and $USERPROFILE is local. To be able to work offline, we need to check if $HOMEDRIVE$HOMEPATH exists and fall back to $USERPROFILE otherwise. Note that git-wrapper does _not_ check if $HOMEDRIVE$HOMEPATH actually exists, as the original git.cmd did. This is probably a regression wrt issue 259. 3. HOME is not set when using the portable version Issue 482 [9], partially fixed in v1.7.2.3 by this patch. 'Partially' because: - there's no fallback to $USERPROFILE, so it doesn't work with disconnected network drives (see problem 2.) - it doesn't setenv(HOME) for child processes (at least git-gui accesses $env(HOME) directly, but I haven't checked what happens if HOME is not set) Incidentally, this patch was first released with v1.7.2.3, which also sets $HOME correctly in both etc/profile and git.cmd. So I suspect that this patch has always been essentially dead code (except perhaps for the portable version, I've never used that). [1] https://code.google.com/p/msysgit/issues/detail?id=491 [2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683187%28v=vs.85%29.aspx [3] https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0013-msys.dll-basic-Unicode-support.patch [4] https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0007-only-override-the-variables-HOMEPATH-and-HOMEDRIVE-i.patch [5] https://github.com/msysgit/msysgit/commit/6b096c9 [6] https://code.google.com/p/msysgit/issues/detail?id=259 [7] https://code.google.com/p/msysgit/issues/detail?id=497 [8] https://code.google.com/p/msysgit/issues/detail?id=512 [9] https://code.google.com/p/msysgit/issues/detail?id=482 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v2] t5000, t5003: do not use test_cmp to compare binary files
I have the problem that the overridden test_cmp crashes on a couple of places where it is doing a binary compare, so this is definitely needed. I actually used cmp -q in my override as it's the return code that is most important. //. On Wed, 4 Jun 2014 11:22:56 AM Junio C Hamano wrote: Stepan Kasal ka...@ucw.cz writes: test_cmp() is primarily meant to compare text files (and display the difference for debug purposes). Raw cmp is better suited to compare binary files (tar, zip, etc.). On MinGW, test_cmp is a shell function mingw_test_cmp that tries to read both files into environment, stripping CR characters (introduced in commit 4d715ac0). This function usually speeds things up, as fork is extremly slow on Windows. But no wonder that this function is extremely slow and sometimes even crashes when comparing large tar or zip files. Signed-off-by: Stepan Kasal ka...@ucw.cz --- Hi Thomas, On Wed, Jun 04, 2014 at 02:59:44PM +0200, Thomas Braun wrote: Using test_cmp_bin instead of cmp would result in then four assertions for comparing arbitrary data test_cmp test_i18ncmp test_cmp_text test_cmp_bin where I think the purpose of each function is clear from its name. [test_cmp_text does not exist (yet)] OK, I agree, hence this modified version of the patch. Yeah, I think the above reasoning is sound. And I do not think we ever need to have test_cmp_text -- our payload and our messages compared by tests to make sure our expectations hold are text by default. Will queue; thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH/RFC] send-pack.c: Allow to disable side-band-64k
On Tue, May 20, 2014 at 10:46 AM, Thomas Braun
thomas.br...@byte-physics.de wrote:
Am 19.05.2014 22:29, schrieb Erik Faye-Lund:
[...]
Would we need to wrap both ends, shouldn't wrapping only reading be
good enough to prevent deadlocking?
compat/poll/poll.c already contains a function called IsSocketHandle
that is able to tell if a HANDLE points to a socket or not.
This very quick attempt did not work out :(
diff --git a/compat/mingw.c b/compat/mingw.c
index 0335958..ec1d81f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -370,6 +370,65 @@ int mingw_open (const char *filename, int oflags, ...)
return fd;
}
+#define is_console_handle(h) (((long) (h) 3) == 3)
+
+static int is_socket_handle(HANDLE h)
+{
+WSANETWORKEVENTS ev;
+
+if (is_console_handle(h))
+return 0;
+
+/*
+ * Under Wine, it seems that getsockopt returns 0 for pipes too.
+ * WSAEnumNetworkEvents instead distinguishes the two correctly.
+ */
+ev.lNetworkEvents = 0xDEADBEEF;
+WSAEnumNetworkEvents((SOCKET) h, NULL, ev);
+return ev.lNetworkEvents != 0xDEADBEEF;
+}
+
+#undef read
+ssize_t mingw_read(int fd, void *buf, size_t count)
+{
+int ret;
+HANDLE fh = (HANDLE)_get_osfhandle(fd);
+
+if (fh == INVALID_HANDLE_VALUE) {
+errno = EBADF;
+return -1;
+}
+
+if (!is_socket_handle(fh))
+return read(fd, buf, count);
+
+ret = recv((SOCKET)fh, buf, count, 0);
+if (ret 0)
+errno = WSAGetLastError();
+return ret;
+}
+
+#undef write
+ssize_t mingw_write(int fd, const void *buf, size_t count)
+{
+int ret;
+HANDLE fh = (HANDLE)_get_osfhandle(fd);
+
+if (fh == INVALID_HANDLE_VALUE) {
+errno = EBADF;
+return -1;
+}
+
+if (!is_socket_handle(fh))
+return write(fd, buf, count);
+
+return send((SOCKET)fh, buf, count, 0);
+if (ret 0)
+errno = WSAGetLastError();
+return ret;
+}
+
+
static BOOL WINAPI ctrl_ignore(DWORD type)
{
return TRUE;
diff --git a/compat/mingw.h b/compat/mingw.h
index 08b83fe..1690098 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -177,6 +177,12 @@ int mingw_rmdir(const char *path);
int mingw_open (const char *filename, int oflags, ...);
#define open mingw_open
+ssize_t mingw_read(int fd, void *buf, size_t count);
+#define read mingw_read
+
+ssize_t mingw_write(int fd, const void *buf, size_t count);
+#define write mingw_write
+
int mingw_fgetc(FILE *stream);
#define fgetc mingw_fgetc
According to [1] you also have to pass WSA_FLAG_OVERLAPPED to avoid the
deadlock.
With that change I don't get a hang anymore but a read error with
errno 10054 aka WSAECONNRESET.
[1]: https://groups.google.com/forum/#!msg/msysgit/at8D7J-h7mw/PM9w-d41cDYJ
Yeah, sorry, I noticed this right after sending and tested with that
as well. My results were the same :/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v2] config: preserve config file permissions on edits
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data such as imap.pass in
..git/config; making the file world-readable when git config
is called to edit means their password would be compromised
on a shared system.
[v2: updated for section renames, as noted by Junio]
Signed-off-by: Eric Wong normalper...@yhbt.net
---
config.c | 16
t/t1300-repo-config.sh | 10 ++
2 files changed, 26 insertions(+)
diff --git a/config.c b/config.c
index a30cb5c..c227aa8 100644
--- a/config.c
+++ b/config.c
@@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char
*config_filename,
MAP_PRIVATE, in_fd, 0);
close(in_fd);
+ if (fchmod(fd, st.st_mode 0) 0) {
+ error(fchmod on %s failed: %s,
+ lock-filename, strerror(errno));
+ ret = CONFIG_NO_WRITE;
+ goto out_free;
+ }
This introduces a severe failure in the Windows port because we do not
implement fchmod. Existing fchmod invocations do not check the return
value, and they are only interested in removing the write bits, and we
generally don't care a lot if files remain writable.
I'm not proficient enough to add any ACL fiddling to fchmod that would be
required by the above change, whose purpose is to be strict about
permissions. Nor am I interested (who the heck is sharing a Windows box
anyway? ;-)
Therefore, here's just a work-around patch to keep things going on
Windows. Any opinions from the Windows corner?
Since we use MSVCRT's chmod implementation directly which only checks
for S_IWRITE,and Get/SetFileAttributes to simply set or clear the
FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except
using Get/SetFileInformationByHandle instead? That takes us in a
better direction, IMO. Adding full ACL support seems like a bigger
project.
If there's no objection, I'll sketch up a patch for that...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v2] config: preserve config file permissions on edits
On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data such as imap.pass in
..git/config; making the file world-readable when git config
is called to edit means their password would be compromised
on a shared system.
[v2: updated for section renames, as noted by Junio]
Signed-off-by: Eric Wong normalper...@yhbt.net
---
config.c | 16
t/t1300-repo-config.sh | 10 ++
2 files changed, 26 insertions(+)
diff --git a/config.c b/config.c
index a30cb5c..c227aa8 100644
--- a/config.c
+++ b/config.c
@@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char
*config_filename,
MAP_PRIVATE, in_fd, 0);
close(in_fd);
+ if (fchmod(fd, st.st_mode 0) 0) {
+ error(fchmod on %s failed: %s,
+ lock-filename, strerror(errno));
+ ret = CONFIG_NO_WRITE;
+ goto out_free;
+ }
This introduces a severe failure in the Windows port because we do not
implement fchmod. Existing fchmod invocations do not check the return
value, and they are only interested in removing the write bits, and we
generally don't care a lot if files remain writable.
I'm not proficient enough to add any ACL fiddling to fchmod that would be
required by the above change, whose purpose is to be strict about
permissions. Nor am I interested (who the heck is sharing a Windows box
anyway? ;-)
Therefore, here's just a work-around patch to keep things going on
Windows. Any opinions from the Windows corner?
Since we use MSVCRT's chmod implementation directly which only checks
for S_IWRITE,and Get/SetFileAttributes to simply set or clear the
FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except
using Get/SetFileInformationByHandle instead? That takes us in a
better direction, IMO. Adding full ACL support seems like a bigger
project.
If there's no objection, I'll sketch up a patch for that...
OK, this turned out a bit more yucky than I assumed, because
SetFileInformationByHandle is only available on Windows Vista and up.
There's a static library (FileExtd.lib) that ships with MSVC that
emulates it for legacy support, I guess I should have a look at what
that does.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH v2] config: preserve config file permissions on edits
On 5/19/2014 2:44 AM, Erik Faye-Lund wrote: On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote: I'm not proficient enough to add any ACL fiddling to fchmod that would be required by the above change, whose purpose is to be strict about permissions. Nor am I interested (who the heck is sharing a Windows box anyway? ;-) Since we use MSVCRT's chmod implementation directly which only checks for S_IWRITE,and Get/SetFileAttributes to simply set or clear the FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except using Get/SetFileInformationByHandle instead? That takes us in a better direction, IMO. Adding full ACL support seems like a bigger project. If there's no objection, I'll sketch up a patch for that... IMO, try to stay away from full ACL support, as ACL is slow as hell. If it's only triggered in edge cases, that's fine, but be sure not to add any ACL in the main call-paths as it will surely kill performance. The major speedup which was done by circumventing MSYS/Cygwin standard posix implementations was bypassing much of the ACL slowness. -- .marius -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
