Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)

Beginning with the referenced commit, the git project cannot be checked 
out on Cygwin (and I assume cannot be checked out on Windows using 
msysgit, though I have not verified this) as this commit introduces the 
file "t/5100/nul." On Windows, the file name "nul" is reserved, 
regardless of path, and cannot be created or deleted. It serves 
essentially the same function as /dev/null.

As a for instance of the troubles:

git>git checkout -f origin/master
Previous HEAD position was a2f5be5... Merge branch 
'jk/maint-send-email-compose' into maint
error: git-checkout-index: unable to create file t/t5100/nul (File exists)

As this commit is part of the published master branch, I am not sure the 
correct resolution: leaving this commit in place means that any commit 
between it and a commit fixing this will always cause an error on Cygwin 
/ Windows. Of course, it *is* on the published master branch.

Mark

Hi,

On Mon, 26 May 2008, Mark Levedahl wrote:

Beginning with the referenced commit, the git project cannot be checked 
out on Cygwin (and I assume cannot be checked out on Windows using 
msysgit, though I have not verified this) as this commit introduces the 
file "t/5100/nul." On Windows, the file name "nul" is reserved, 
regardless of path, and cannot be created or deleted. It serves 
essentially the same function as /dev/null.

Even when referencing the full (or a relative) path?  That's bad!

As a for instance of the troubles:

git>git checkout -f origin/master
Previous HEAD position was a2f5be5... Merge branch
'jk/maint-send-email-compose' into maint
error: git-checkout-index: unable to create file t/t5100/nul (File exists)

As this commit is part of the published master branch, I am not sure the 
correct resolution: leaving this commit in place means that any commit 
between it and a commit fixing this will always cause an error on Cygwin 
/ Windows. Of course, it *is* on the published master branch.

That's the case for all regressions: we do not rewrite history for them.

As for the resolution, could you quickly try the 'my-next' branch of 
git://repo.or.cz/git/dscho.git?

If that works, I'll send a proper patch to Junio.

Ciao,
Dscho

Johannes Schindelin wrote:

quoted

As a for instance of the troubles:

git>git checkout -f origin/master
Previous HEAD position was a2f5be5... Merge branch
'jk/maint-send-email-compose' into maint
error: git-checkout-index: unable to create file t/t5100/nul (File exists)

As this commit is part of the published master branch, I am not sure the 
correct resolution: leaving this commit in place means that any commit 
between it and a commit fixing this will always cause an error on Cygwin 
/ Windows. Of course, it *is* on the published master branch.
    

That's the case for all regressions: we do not rewrite history for them.

  

I understand that, and the reasons: however, as this leads to a long 
sequence of commits pointing to *illegal* trees, not just trees with bad 
code, a different policy might be in order here. Or, it might not.

As for the resolution, could you quickly try the 'my-next' branch of 
git://repo.or.cz/git/dscho.git?

  

I can check that branch out, but don't get very far in the tests:

*** t0004-unwritable.sh ***
*   ok 1: setup
* FAIL 2: write-tree should notice unwritable repository


                (
                        chmod a-w .git/objects
                        test_must_fail git write-tree
                )
                status=$?
                chmod 775 .git/objects
                (exit $status)


* FAIL 3: commit should notice unwritable repository


                (
                        chmod a-w .git/objects
                        test_must_fail git commit -m second
                )
                status=$?
                chmod 775 .git/objects
                (exit $status)


* FAIL 4: update-index should notice unwritable repository


                (
                        echo a >file &&
                        chmod a-w .git/objects
                        test_must_fail git update-index file
                )
                status=$?
                chmod 775 .git/objects
                (exit $status)


* FAIL 5: add should notice unwritable repository


                (
                        echo b >file &&
                        chmod a-w .git/objects
                        test_must_fail git add file
                )
                status=$?
                chmod 775 .git/objects
                (exit $status)


* failed 4 among 5 test(s)
make[1]: *** [t0004-unwritable.sh] Error 1
make[1]: Leaving directory `/usr/src/dscho
make: *** [test] Error 2

I don't have access to a linux box today, so I can't manipulate master 
to find if that branch with your patch would work right now.

Mark

Hi,

On Mon, 26 May 2008, Mark Levedahl wrote:

Johannes Schindelin wrote:

quoted

You wrote:

quoted

As this commit is part of the published master branch, I am not sure 
the correct resolution: leaving this commit in place means that any 
commit between it and a commit fixing this will always cause an 
error on Cygwin / Windows. Of course, it *is* on the published 
master branch.

That's the case for all regressions: we do not rewrite history for 
them.

I understand that, and the reasons: however, as this leads to a long 
sequence of commits pointing to *illegal* trees, not just trees with bad 
code, a different policy might be in order here. Or, it might not.

I fail to see how Cygwin is so special as to merit a falsification of 
history.

quoted

As for the resolution, could you quickly try the 'my-next' branch of 
git://repo.or.cz/git/dscho.git?

I can check that branch out, but don't get very far in the tests:

*** t0004-unwritable.sh ***
*   ok 1: setup
* FAIL 2: write-tree should notice unwritable repository

Sorry.  Was worth a try.

I don't have access to a linux box today, so I can't manipulate master 
to find if that branch with your patch would work right now.

Sure you can.  You should be able to "git mv t/t5100/nul t/t5100/nul-file" 
and then editing t/t5100-*.sh to refer to nul-file instead of nul.

Hth,
Dscho

Johannes Schindelin wrote:

Hi,


  
I fail to see how Cygwin is so special as to merit a falsification of 
history.

  

quoted

I don't have access to a linux box today, so I can't manipulate master 
to find if that branch with your patch would work right now.
    

Sure you can.  You should be able to "git mv t/t5100/nul t/t5100/nul-file" 
and then editing t/t5100-*.sh to refer to nul-file instead of nul.

Hth,
Dscho
  

The above two points are related: the current master causes git to abort 
before writing the index:

 >git checkout -f origin/master
error: git-checkout-index: unable to create file t/t5100/nul (File exists)
 >git mv t/t5100/nul t/t5100/nul-file
fatal: not under version control, source=t/t5100/nul, 
destination=t/t5100/nul-file

So, there is now a range of git's history that is unusable (and 
non-bisectable) on Windows, at least from the porcelain. And apparently, 
somewhere in that unusable history, a change was introduced that causes 
test failure on Cygwin. Great...

Mark

Hi,

On Mon, 26 May 2008, Mark Levedahl wrote:

So, there is now a range of git's history that is unusable (and 
non-bisectable) on Windows, at least from the porcelain. And apparently, 
somewhere in that unusable history, a change was introduced that causes 
test failure on Cygwin. Great...

Oh, for the love of God!  It is not like we will not fix this problem 
eventually!  Screwing a lot of users by rewriting history, just because of 
Windows, which we need too many ugly work-arounds in Git's source code for 
anyway, is _not_ an option.

Or would you suggest to scrap almost the complete history of Git just 
because most of it does not compile on platform XYZ, while the initial 
revision did?  Exactly.

Ciao,
Dscho

Hi,

On Mon, 26 May 2008, Mark Levedahl wrote:

quoted

git checkout -f origin/master

error: git-checkout-index: unable to create file t/t5100/nul (File exists)

quoted

git mv t/t5100/nul t/t5100/nul-file

fatal: not under version control, source=t/t5100/nul,
destination=t/t5100/nul-file

I should not do this, because you cost me already too much time with your 
outrageous proposal to rewrite history just for that stupid platform 
called Windows, whose users seem to complain more than actually 
contribute, but here it goes:

http://repo.or.cz/w/git/dscho.git?a=shortlog;h=refs/heads/nul-fix

The corresponding patch:

-- snipsnap --
[PATCH] Fix t5100 for Windows

On Windows, "nul" is not allowed as a file name.  So bend over for that
platform even more than we do already.

Signed-off-by: Johannes Schindelin <redacted>
---
 t/t5100-mailinfo.sh        |    4 ++--
 t/t5100/{nul => nul-plain} |  Bin 91 -> 91 bytes
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename t/t5100/{nul => nul-plain} (100%)

diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index a8b78eb..577ecc2 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh

@@ -27,8 +27,8 @@ done
 
 test_expect_success 'respect NULs' '
 
-	git mailsplit -d3 -o. ../t5100/nul &&
-	cmp ../t5100/nul 001 &&
+	git mailsplit -d3 -o. ../t5100/nul-plain &&
+	cmp ../t5100/nul-plain 001 &&
 	(cat 001 | git mailinfo msg patch) &&
 	test 4 = $(wc -l < patch)
 

diff --git a/t/t5100/nul b/t/t5100/nul-plain
similarity index 100%
rename from t/t5100/nul
rename to t/t5100/nul-plain
-- 
1.5.6.rc0.175.gdd78

Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:

On Mon, 26 May 2008, Mark Levedahl wrote:

quoted

Beginning with the referenced commit, the git project cannot be checked 
out on Cygwin (and I assume cannot be checked out on Windows using 
msysgit, though I have not verified this) as this commit introduces the 
file "t/5100/nul." On Windows, the file name "nul" is reserved, 
regardless of path, and cannot be created or deleted. It serves 
essentially the same function as /dev/null.

Even when referencing the full (or a relative) path?  That's bad!

Yes.  And it is not limited to the case-insensitive name NUL; it also covers
names like "aux".  See the very last paragraph in this section:
http://www.gnu.org/software/autoconf/manual/html_node/File-System-Conventions.html#File-System-Conventions

This will affect all versions of MSYS.  However, with cygwin 1.5.x, you can use
the workaround of a managed mount which intentionally (and transparently) munges
such invalid file names so that you can appear to name a file "nul" in spite of
Windows (at the expense of making an already short PATH_MAX of 256 even
shorter).  And if you are willing to experiment with the (still-in-development)
cygwin 1.7.0, this munging is done without even needing a managed mount and
without any penalty to the larger PATH_MAX of 4k.

At any rate, I agree with your patch to rename the file, as well as with your
aversion to rewriting history just so that a checkout on MSYS or a non-managed
mount on older cygwin can do a 'git bisect' that hits the small window of
commits with an invalid tree.

-- 
Eric Blake