{"thread":{"id":"13672","subject":"Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","startedAt":"2008-05-26T14:01:50Z","lastAt":"2008-06-01T19:07:44Z","messageCount":42,"participants":["Mark Levedahl","Johannes Schindelin","Junio C Hamano","Eric Blake","Wincent Colaiuta","Lea Wiemann","Avery Pennarun","Sverre Rabbelier","Daniel Barkalow","Jakub Narebski","Marius Storm-Olsen","Steffen Prohaska","Kay Sievers"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77776","messageId":"483AC2CE.7090801@gmail.com","threadId":"13672","inReplyTo":null,"subject":"Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2008-05-26T14:01:50Z","receivedAt":"2008-05-26T14:01:50Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Beginning with the referenced commit, the git project cannot be checked \nout on Cygwin (and I assume cannot be checked out on Windows using \nmsysgit, though I have not verified this) as this commit introduces the \nfile \"t/5100/nul.\" On Windows, the file name \"nul\" is reserved, \nregardless of path, and cannot be created or deleted. It serves \nessentially the same function as /dev/null.\n\nAs a for instance of the troubles:\n\ngit>git checkout -f origin/master\nPrevious HEAD position was a2f5be5... Merge branch \n'jk/maint-send-email-compose' into maint\nerror: git-checkout-index: unable to create file t/t5100/nul (File exists)\n\nAs this commit is part of the published master branch, I am not sure the \ncorrect resolution: leaving this commit in place means that any commit \nbetween it and a commit fixing this will always cause an error on Cygwin \n/ Windows. Of course, it *is* on the published master branch.\n\nMark\n"},{"id":"77778","messageId":"alpine.DEB.1.00.0805261521130.30431@racer","threadId":"13672","inReplyTo":"483AC2CE.7090801@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T14:25:58Z","receivedAt":"2008-05-26T14:25:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 May 2008, Mark Levedahl wrote:\n\n> Beginning with the referenced commit, the git project cannot be checked \n> out on Cygwin (and I assume cannot be checked out on Windows using \n> msysgit, though I have not verified this) as this commit introduces the \n> file \"t/5100/nul.\" On Windows, the file name \"nul\" is reserved, \n> regardless of path, and cannot be created or deleted. It serves \n> essentially the same function as /dev/null.\n\nEven when referencing the full (or a relative) path? That's bad!\n\n> As a for instance of the troubles:\n> \n> git>git checkout -f origin/master\n> Previous HEAD position was a2f5be5... Merge branch\n> 'jk/maint-send-email-compose' into maint\n> error: git-checkout-index: unable to create file t/t5100/nul (File exists)\n> \n> As this commit is part of the published master branch, I am not sure the \n> correct resolution: leaving this commit in place means that any commit \n> between it and a commit fixing this will always cause an error on Cygwin \n> / Windows. Of course, it *is* on the published master branch.\n\nThat's the case for all regressions: we do not rewrite history for them.\n\nAs for the resolution, could you quickly try the 'my-next' branch of \ngit://repo.or.cz/git/dscho.git?\n\nIf that works, I'll send a proper patch to Junio.\n\nCiao,\nDscho\n"},{"id":"77785","messageId":"483AF570.9000609@gmail.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805261521130.30431@racer","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2008-05-26T17:37:52Z","receivedAt":"2008-05-26T17:37:52Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Johannes Schindelin wrote:\n>> As a for instance of the troubles:\n>>\n>> git>git checkout -f origin/master\n>> Previous HEAD position was a2f5be5... Merge branch\n>> 'jk/maint-send-email-compose' into maint\n>> error: git-checkout-index: unable to create file t/t5100/nul (File exists)\n>>\n>> As this commit is part of the published master branch, I am not sure the \n>> correct resolution: leaving this commit in place means that any commit \n>> between it and a commit fixing this will always cause an error on Cygwin \n>> / Windows. Of course, it *is* on the published master branch.\n>> \n>\n> That's the case for all regressions: we do not rewrite history for them.\n>\n> \nI understand that, and the reasons: however, as this leads to a long \nsequence of commits pointing to *illegal* trees, not just trees with bad \ncode, a different policy might be in order here. Or, it might not.\n> As for the resolution, could you quickly try the 'my-next' branch of \n> git://repo.or.cz/git/dscho.git?\n>\n> \nI can check that branch out, but don't get very far in the tests:\n\n*** t0004-unwritable.sh ***\n* ok 1: setup\n* FAIL 2: write-tree should notice unwritable repository\n\n\n (\n chmod a-w .git/objects\n test_must_fail git write-tree\n )\n status=$?\n chmod 775 .git/objects\n (exit $status)\n\n\n* FAIL 3: commit should notice unwritable repository\n\n\n (\n chmod a-w .git/objects\n test_must_fail git commit -m second\n )\n status=$?\n chmod 775 .git/objects\n (exit $status)\n\n\n* FAIL 4: update-index should notice unwritable repository\n\n\n (\n echo a >file &&\n chmod a-w .git/objects\n test_must_fail git update-index file\n )\n status=$?\n chmod 775 .git/objects\n (exit $status)\n\n\n* FAIL 5: add should notice unwritable repository\n\n\n (\n echo b >file &&\n chmod a-w .git/objects\n test_must_fail git add file\n )\n status=$?\n chmod 775 .git/objects\n (exit $status)\n\n\n* failed 4 among 5 test(s)\nmake[1]: *** [t0004-unwritable.sh] Error 1\nmake[1]: Leaving directory `/usr/src/dscho\nmake: *** [test] Error 2\n\nI don't have access to a linux box today, so I can't manipulate master \nto find if that branch with your patch would work right now.\n\nMark\n"},{"id":"77797","messageId":"alpine.DEB.1.00.0805262220160.30431@racer","threadId":"13672","inReplyTo":"483ADA17.3080401@viscovery.net","subject":"[PATCH] Makefile: wt-status.h is also a lib header","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T21:21:10Z","receivedAt":"2008-05-26T21:21:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a struct in wt-status.h changes, many files need to be rebuilt.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tHannes noticed that this patch was not yet accepted (or not\n\teven submitted, I do not remember).\n\n Makefile | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex dbfa2b6..aced19b 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -376,6 +376,7 @@ LIB_H += tree-walk.h\n LIB_H += unpack-trees.h\n LIB_H += utf8.h\n LIB_H += levenshtein.h\n+LIB_H += wt-status.h\n \n LIB_OBJS += alias.o\n LIB_OBJS += alloc.o\n@@ -1129,7 +1130,6 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n \n $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)\n $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)\n-builtin-revert.o wt-status.o: wt-status.h\n \n $(LIB_FILE): $(LIB_OBJS)\n \t$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIB_OBJS)\n-- \n1.5.6.rc0.175.gdd78\n"},{"id":"77798","messageId":"alpine.DEB.1.00.0805262226400.30431@racer","threadId":"13672","inReplyTo":"483AF570.9000609@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T21:28:48Z","receivedAt":"2008-05-26T21:28:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 May 2008, Mark Levedahl wrote:\n\n> Johannes Schindelin wrote:\n>\n> > You wrote:\n> >\n> > > As this commit is part of the published master branch, I am not sure \n> > > the correct resolution: leaving this commit in place means that any \n> > > commit between it and a commit fixing this will always cause an \n> > > error on Cygwin / Windows. Of course, it *is* on the published \n> > > master branch.\n> >\n> > That's the case for all regressions: we do not rewrite history for \n> > them.\n>\n> I understand that, and the reasons: however, as this leads to a long \n> sequence of commits pointing to *illegal* trees, not just trees with bad \n> code, a different policy might be in order here. Or, it might not.\n\nI fail to see how Cygwin is so special as to merit a falsification of \nhistory.\n\n> > As for the resolution, could you quickly try the 'my-next' branch of \n> > git://repo.or.cz/git/dscho.git?\n>\n> I can check that branch out, but don't get very far in the tests:\n> \n> *** t0004-unwritable.sh ***\n> * ok 1: setup\n> * FAIL 2: write-tree should notice unwritable repository\n\nSorry. Was worth a try.\n\n> I don't have access to a linux box today, so I can't manipulate master \n> to find if that branch with your patch would work right now.\n\nSure you can. You should be able to \"git mv t/t5100/nul t/t5100/nul-file\" \nand then editing t/t5100-*.sh to refer to nul-file instead of nul.\n\nHth,\nDscho\n"},{"id":"77807","messageId":"7vlk1w4tp9.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805262220160.30431@racer","subject":"Re: [PATCH] Makefile: wt-status.h is also a lib header","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-26T21:54:42Z","receivedAt":"2008-05-26T21:54:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> When a struct in wt-status.h changes, many files need to be rebuilt.\n\nWhat project, that has levenshtein.h, is this patch is for ;-)?\n"},{"id":"77810","messageId":"483B3E86.5020100@gmail.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805262226400.30431@racer","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2008-05-26T22:49:42Z","receivedAt":"2008-05-26T22:49:42Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n>\n>\n> \n> I fail to see how Cygwin is so special as to merit a falsification of \n> history.\n>\n> \n>> I don't have access to a linux box today, so I can't manipulate master \n>> to find if that branch with your patch would work right now.\n>> \n>\n> Sure you can. You should be able to \"git mv t/t5100/nul t/t5100/nul-file\" \n> and then editing t/t5100-*.sh to refer to nul-file instead of nul.\n>\n> Hth,\n> Dscho\n> \nThe above two points are related: the current master causes git to abort \nbefore writing the index:\n\n >git checkout -f origin/master\nerror: git-checkout-index: unable to create file t/t5100/nul (File exists)\n >git mv t/t5100/nul t/t5100/nul-file\nfatal: not under version control, source=t/t5100/nul, \ndestination=t/t5100/nul-file\n\nSo, there is now a range of git's history that is unusable (and \nnon-bisectable) on Windows, at least from the porcelain. And apparently, \nsomewhere in that unusable history, a change was introduced that causes \ntest failure on Cygwin. Great...\n\nMark\n"},{"id":"77811","messageId":"alpine.DEB.1.00.0805270001050.30431@racer","threadId":"13672","inReplyTo":"7vlk1w4tp9.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Makefile: wt-status.h is also a lib header","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T23:03:29Z","receivedAt":"2008-05-26T23:03:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 May 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > When a struct in wt-status.h changes, many files need to be rebuilt.\n> \n> What project, that has levenshtein.h, is this patch is for ;-)?\n\nHeh. Missed that one. There was a discussion some time ago that the \nrename detection should prefer names with a smaller Levenshtein distance, \nso I implemented that (back when I still had some time).\n\nThis one is on top of the current 'next':\n\n-- snipsnap --\n[PATCH v2] Makefile: wt-status.h is also a lib header\n\nWhen a struct in wt-status.h changes, many files need to be rebuilt.\n\nSigned-off-by: Johannes Schindelin \n---\n Makefile | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex ef5ce5e..ab358b2 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -375,6 +375,7 @@ LIB_H += tree.h\n LIB_H += tree-walk.h\n LIB_H += unpack-trees.h\n LIB_H += utf8.h\n+LIB_H += wt-status.h\n \n LIB_OBJS += alias.o\n LIB_OBJS += alloc.o\n@@ -1127,7 +1128,6 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n \n $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)\n $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)\n-builtin-revert.o wt-status.o: wt-status.h\n \n $(LIB_FILE): $(LIB_OBJS)\n \t$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIB_OBJS)\n-- \n1.5.6.rc0.175.gdd78\n"},{"id":"77813","messageId":"alpine.DEB.1.00.0805270007430.30431@racer","threadId":"13672","inReplyTo":"483B3E86.5020100@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T23:10:19Z","receivedAt":"2008-05-26T23:10:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 May 2008, Mark Levedahl wrote:\n\n> So, there is now a range of git's history that is unusable (and \n> non-bisectable) on Windows, at least from the porcelain. And apparently, \n> somewhere in that unusable history, a change was introduced that causes \n> test failure on Cygwin. Great...\n\nOh, for the love of God! It is not like we will not fix this problem \neventually! Screwing a lot of users by rewriting history, just because of \nWindows, which we need too many ugly work-arounds in Git's source code for \nanyway, is _not_ an option.\n\nOr would you suggest to scrap almost the complete history of Git just \nbecause most of it does not compile on platform XYZ, while the initial \nrevision did? Exactly.\n\nCiao,\nDscho\n"},{"id":"77816","messageId":"alpine.DEB.1.00.0805270012240.30431@racer","threadId":"13672","inReplyTo":"483B3E86.5020100@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-26T23:15:06Z","receivedAt":"2008-05-26T23:15:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 May 2008, Mark Levedahl wrote:\n\n> >git checkout -f origin/master\n> error: git-checkout-index: unable to create file t/t5100/nul (File exists)\n> >git mv t/t5100/nul t/t5100/nul-file\n> fatal: not under version control, source=t/t5100/nul,\n> destination=t/t5100/nul-file\n\nI should not do this, because you cost me already too much time with your \noutrageous proposal to rewrite history just for that stupid platform \ncalled Windows, whose users seem to complain more than actually \ncontribute, but here it goes:\n\nhttp://repo.or.cz/w/git/dscho.git?a=shortlog;h=refs/heads/nul-fix\n\nThe corresponding patch:\n\n-- snipsnap --\n[PATCH] Fix t5100 for Windows\n\nOn Windows, \"nul\" is not allowed as a file name. So bend over for that\nplatform even more than we do already.\n\nSigned-off-by: Johannes Schindelin \n---\n t/t5100-mailinfo.sh | 4 ++--\n t/t5100/{nul => nul-plain} | Bin 91 -> 91 bytes\n 2 files changed, 2 insertions(+), 2 deletions(-)\n rename t/t5100/{nul => nul-plain} (100%)\n\ndiff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh\nindex a8b78eb..577ecc2 100755\n--- a/t/t5100-mailinfo.sh\n+++ b/t/t5100-mailinfo.sh\n@@ -27,8 +27,8 @@ done\n \n test_expect_success 'respect NULs' '\n \n-\tgit mailsplit -d3 -o. ../t5100/nul &&\n-\tcmp ../t5100/nul 001 &&\n+\tgit mailsplit -d3 -o. ../t5100/nul-plain &&\n+\tcmp ../t5100/nul-plain 001 &&\n \t(cat 001 | git mailinfo msg patch) &&\n \ttest 4 = $(wc -l < patch)\n \ndiff --git a/t/t5100/nul b/t/t5100/nul-plain\nsimilarity index 100%\nrename from t/t5100/nul\nrename to t/t5100/nul-plain\n-- \n1.5.6.rc0.175.gdd78\n"},{"id":"77854","messageId":"loom.20080527T131535-95@post.gmane.org","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805261521130.30431@racer","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Eric Blake","fromEmail":"ebb9@byu.net","sentAt":"2008-05-27T13:26:10Z","receivedAt":"2008-05-27T13:26:10Z","isPatch":false,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"Johannes Schindelin gmx.de> writes:\n\n> On Mon, 26 May 2008, Mark Levedahl wrote:\n> \n> > Beginning with the referenced commit, the git project cannot be checked \n> > out on Cygwin (and I assume cannot be checked out on Windows using \n> > msysgit, though I have not verified this) as this commit introduces the \n> > file \"t/5100/nul.\" On Windows, the file name \"nul\" is reserved, \n> > regardless of path, and cannot be created or deleted. It serves \n> > essentially the same function as /dev/null.\n> \n> Even when referencing the full (or a relative) path? That's bad!\n\nYes. And it is not limited to the case-insensitive name NUL; it also covers\nnames like \"aux\". See the very last paragraph in this section:\nhttp://www.gnu.org/software/autoconf/manual/html_node/File-System-Conventions.html#File-System-Conventions\n\nThis will affect all versions of MSYS. However, with cygwin 1.5.x, you can use\nthe workaround of a managed mount which intentionally (and transparently) munges\nsuch invalid file names so that you can appear to name a file \"nul\" in spite of\nWindows (at the expense of making an already short PATH_MAX of 256 even\nshorter). And if you are willing to experiment with the (still-in-development)\ncygwin 1.7.0, this munging is done without even needing a managed mount and\nwithout any penalty to the larger PATH_MAX of 4k.\n\nAt any rate, I agree with your patch to rename the file, as well as with your\naversion to rewriting history just so that a checkout on MSYS or a non-managed\nmount on older cygwin can do a 'git bisect' that hits the small window of\ncommits with an invalid tree.\n\n-- \nEric Blake\n"},{"id":"77914","messageId":"7vy75vvtxo.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"483AC2CE.7090801@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T06:12:03Z","receivedAt":"2008-05-28T06:12:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Levedahl writes:\n\n> As this commit is part of the published master branch, I am not sure\n> the correct resolution: leaving this commit in place means that any\n> commit between it and a commit fixing this will always cause an error\n> on Cygwin / Windows. Of course, it *is* on the published master branch.\n\nSome broken filesystems may not be capable of checking out and using\nproject files. Too bad.\n\nIt's not a big deal. It is not limited to this project. We just fix them\nor work them around and move on.\n\nPerhaps we should remove the infamous gitweb/test/Märchen file while we\nare at it? I do not think the file is ever used.\n"},{"id":"77927","messageId":"100A0CFD-EB6F-48F1-B917-811310CCFB6E@wincent.com","threadId":"13672","inReplyTo":"7vy75vvtxo.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-05-28T09:46:24Z","receivedAt":"2008-05-28T09:46:24Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n> Mark Levedahl writes:\n>\n>> As this commit is part of the published master branch, I am not sure\n>> the correct resolution: leaving this commit in place means that any\n>> commit between it and a commit fixing this will always cause an error\n>> on Cygwin / Windows. Of course, it *is* on the published master \n>> branch.\n>\n> Some broken filesystems may not be capable of checking out and using\n> project files. Too bad.\n>\n> It's not a big deal. It is not limited to this project. We just \n> fix them\n> or work them around and move on.\n>\n> Perhaps we should remove the infamous gitweb/test/Märchen file while \n> we\n> are at it? I do not think the file is ever used.\n\nI for one would love to see it go, seeing as I live in the ghetto that \nis HFS+ and am constantly annoyed by it cluttering up my status output \nwith spurious content.\n\nI understand that the reason it lives in the tree is precisely to \ndiscover problems with such filesystems, but the problem is well and \ntruly discovered by now and I'd much rather see this kind of thing \ntested from within the test suite rather than every time I do \"git \nstatus\" or \"git checkout\".\n\nCheers,\nWincent\n"},{"id":"77944","messageId":"483D7FE9.5000207@gmail.com","threadId":"13672","inReplyTo":"100A0CFD-EB6F-48F1-B917-811310CCFB6E@wincent.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-05-28T15:53:13Z","receivedAt":"2008-05-28T15:53:13Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Wincent Colaiuta wrote:\n> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>> Perhaps we should remove the infamous gitweb/test/Märchen file\n> \n> [...] I'd much rather see this kind of thing \n> tested from within the test suite rather than every time I do \"git \n> status\" or \"git checkout\".\n\nI don't believe the Märchen file is actually used in any test code, so \nremoving it should be fine. If/when we actually write test code for \ngitweb, it seems to me that we might as well generate such test files on \nthe fly from within the test suite, rather than having them in the file \nsystem permanently.\n\nBest,\n\n Lea\n"},{"id":"77946","messageId":"CB1B699D-8DC6-4FF5-96E1-072FA91F70CF@wincent.com","threadId":"13672","inReplyTo":"483D7FE9.5000207@gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-05-28T15:58:52Z","receivedAt":"2008-05-28T15:58:52Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 28/5/2008, a las 17:53, Lea Wiemann escribió:\n> Wincent Colaiuta wrote:\n>> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>>> Perhaps we should remove the infamous gitweb/test/Märchen file\n>> [...] I'd much rather see this kind of thing tested from within \n>> the test suite rather than every time I do \"git status\" or \"git \n>> checkout\".\n>\n> I don't believe the Märchen file is actually used in any test code, \n> so removing it should be fine. If/when we actually write test code \n> for gitweb, it seems to me that we might as well generate such test \n> files on the fly from within the test suite, rather than having them \n> in the file system permanently.\n\nYes, that's exactly what I intended my comment to imply. Test at test \ntime, not every time I do \"git status\" and \"git checkout\" etc.\n\nCheers,\nWincent\n"},{"id":"77948","messageId":"32541b130805280933r573d59d0mf9cdc09f5e5a6a17@mail.gmail.com","threadId":"13672","inReplyTo":"7vy75vvtxo.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-05-28T16:33:10Z","receivedAt":"2008-05-28T16:33:10Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 5/28/08, Junio C Hamano wrote:\n> Mark Levedahl writes:\n>\n> > As this commit is part of the published master branch, I am not sure\n> > the correct resolution: leaving this commit in place means that any\n> > commit between it and a commit fixing this will always cause an error\n> > on Cygwin / Windows. Of course, it *is* on the published master branch.\n>\n> Some broken filesystems may not be capable of checking out and using\n> project files. Too bad.\n>\n> It's not a big deal. It is not limited to this project. We just fix them\n> or work them around and move on.\n>\n> Perhaps we should remove the infamous gitweb/test/Märchen file while we\n> are at it? I do not think the file is ever used.\n\nAs an unhappy Windows user myself (sometimes), I think it might be\nbetter to simply fix git to *survive* failing to create files like\n'nul' on Win32, rather than trying to *fix* such files in the repo.\nIt sounds (from the original post) like git has a *fatal* error\n(\"cannot be checked out on cygwin\") when trying to create 'nul', which\nmight be overkill.\n\nThe argument about rewriting the git history for this one file is\nmostly predicated on the fact that you can't git-bisect if this file\nexists. Rather than making the file not exist, it might be better to\nmake git work when it does.\n\nHave fun,\n\nAvery\n"},{"id":"77957","messageId":"7vfxs2uytm.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"32541b130805280933r573d59d0mf9cdc09f5e5a6a17@mail.gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T17:24:05Z","receivedAt":"2008-05-28T17:24:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> As an unhappy Windows user myself (sometimes), I think it might be\n> better to simply fix git to *survive* failing to create files like\n> 'nul' on Win32, rather than trying to *fix* such files in the repo.\n> It sounds (from the original post) like git has a *fatal* error\n> (\"cannot be checked out on cygwin\") when trying to create 'nul'.\n\nPlease learn to think before typing, let alone sending such a message to\nwaste other people's time.\n\nWe give the user an error message, and signal error by exiting with\nnon-zero. You cannot have that path on the system, and we are being\nhonest about it. It is not like we are suddenly painting the screen in\nblue and refusing to get any more user input when you try to check out\nsuch a tree. Which part of that is _not_ surviving?\n\nThe system with a *fatal* error is not git but the one that does not want\nan not-so-unreasonable name \"NUL\" on it. Git survives on such a system\nand tells you what happened --- you cannot do certain things, such as\nchecking out such a tree. You live with it, or get a better system ;-)\n\nWhat alternatives do you want to implement? Certainly not silently\ncreating \"nul-garbage\" file instead and pretend that nothing bad happened,\nas that would lead to madness.\n"},{"id":"77958","messageId":"bd6139dc0805281046n3d811b83l1a1c15cc6e2d8122@mail.gmail.com","threadId":"13672","inReplyTo":"7vfxs2uytm.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-28T17:46:15Z","receivedAt":"2008-05-28T17:46:15Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Wed, May 28, 2008 at 7:24 PM, Junio C Hamano wrote:\n> Please learn to think before typing, let alone sending such a message to\n> waste other people's time.\n\nWhy so harsh?\n\n> What alternatives do you want to implement? Certainly not silently\n> creating \"nul-garbage\" file instead and pretend that nothing bad happened,\n> as that would lead to madness.\n\nOr instead we could have a '-f' switch or such with checkout that\nallows you to checkout a revision that contains a bad file, but with\nthat file missing. Of course this needn't happen silently, a big\nwarning saying \"could not checkout file %s because of %s\" may still be\nissued.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"77959","messageId":"32541b130805281052o2a56f00m4b64299737d27091@mail.gmail.com","threadId":"13672","inReplyTo":"7vfxs2uytm.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-05-28T17:52:56Z","receivedAt":"2008-05-28T17:52:56Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 5/28/08, Junio C Hamano wrote:\n> Please learn to think before typing, let alone sending such a message to\n> waste other people's time.\n\nPhew, just mentioning Windows on this list seems to get people flamed.\n\nReading over my message, I'm not sure what I would have written to\nhave it interpreted as being negative. I was simply suggesting that\ngit could fail more gracefully here.\n\n> We give the user an error message, and signal error by exiting with\n> non-zero. You cannot have that path on the system, and we are being\n> honest about it. It is not like we are suddenly painting the screen in\n> blue and refusing to get any more user input when you try to check out\n> such a tree. Which part of that is _not_ surviving?\n\nThe part that's not surviving is git-bisect, which is a valid problem\nthat resulted in someone asking to rewrite the history. Clearly\nrewriting the history is not a good solution, thus no good solution\nhas yet been proposed, which is why I wrote my message.\n\n> The system with a *fatal* error is not git but the one that does not want\n> an not-so-unreasonable name \"NUL\" on it.\n\nThat is clearly true. But knowing that doesn't seem to be making this\nuser's problem go away.\n\n> What alternatives do you want to implement? Certainly not silently\n> creating \"nul-garbage\" file instead and pretend that nothing bad happened,\n> as that would lead to madness.\n\nIf the file failed to be created (with a warning), but we treated it\nas having been deleted in 'git status' instead of throwing an error,\nit would work much like the case sensitivity problem: the index is\nannoyingly dirty, but you can still get work done. I think that\n(perhaps with a little patch) would allow git-bisect to work.\n\nHave fun,\n\nAvery\n"},{"id":"77962","messageId":"alpine.LNX.1.00.0805281326520.19665@iabervon.org","threadId":"13672","inReplyTo":"7vfxs2uytm.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-28T18:19:17Z","receivedAt":"2008-05-28T18:19:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 May 2008, Junio C Hamano wrote:\n\n> \"Avery Pennarun\" writes:\n> \n> > As an unhappy Windows user myself (sometimes), I think it might be\n> > better to simply fix git to *survive* failing to create files like\n> > 'nul' on Win32, rather than trying to *fix* such files in the repo.\n> > It sounds (from the original post) like git has a *fatal* error\n> > (\"cannot be checked out on cygwin\") when trying to create 'nul'.\n> \n> Please learn to think before typing, let alone sending such a message to\n> waste other people's time.\n> \n> We give the user an error message, and signal error by exiting with\n> non-zero. You cannot have that path on the system, and we are being\n> honest about it. It is not like we are suddenly painting the screen in\n> blue and refusing to get any more user input when you try to check out\n> such a tree. Which part of that is _not_ surviving?\n> \n> The system with a *fatal* error is not git but the one that does not want\n> an not-so-unreasonable name \"NUL\" on it. Git survives on such a system\n> and tells you what happened --- you cannot do certain things, such as\n> checking out such a tree. You live with it, or get a better system ;-)\n> \n> What alternatives do you want to implement? Certainly not silently\n> creating \"nul-garbage\" file instead and pretend that nothing bad happened,\n> as that would lead to madness.\n\nReport a non-fatal error, mark in the index that that entry is not \nreflected in the working directory, and allow the user to manipulate it \nwith commands that don't really need the working directory content.\n\n$ git checkout origin/master\nWarning: couldn't create 't/t5100/nul' in your working directory; ignoring \nworking directory for this filename.\n$ git mv t/t5100/nul t/t5100/nul-plain\n$ ls t/t5100/nul-plain\nt/t5100/nul-plain\n\nThe working directory doesn't really have to be absolutely vital to git's \nfunctioning (of course, the project you've checked out is going to have \nproblems unless you fix things). In particular, it should be possible, on \na machine with a broken filesystem, to modify a project that triggers the \nfilesystem breakage to not trigger it, rather than having to rely on \neither read-tree/update-index --cachinfo/write-tree or a helpful user of a \nnon-broken system to get things working again.\n\nGit should, I think, even be able to figure out by itself when to not \ntrust the filesystem; if open gives EEXIST, but readdir doesn't list it, \nit's a filesystem problem and we should work around it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"77964","messageId":"7vwslethca.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"32541b130805281052o2a56f00m4b64299737d27091@mail.gmail.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T18:27:01Z","receivedAt":"2008-05-28T18:27:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> On 5/28/08, Junio C Hamano wrote:\n>> Please learn to think before typing, let alone sending such a message to\n>> waste other people's time.\n>\n> Phew, just mentioning Windows on this list seems to get people flamed.\n\nI did not flame Windows.\n\n> Reading over my message, I'm not sure what I would have written to\n> have it interpreted as being negative....\n> The part that's not surviving is git-bisect, which is a valid problem\n> that resulted in someone asking to rewrite the history. Clearly\n> rewriting the history is not a good solution, thus no good solution\n> has yet been proposed, which is why I wrote my message.\n\nHere is what you wrote:\n\n As an unhappy Windows user myself (sometimes), I think it might be\n better to simply fix git to *survive* failing to create files like\n 'nul' on Win32, rather than trying to *fix* such files in the repo.\n It sounds (from the original post) like git has a *fatal* error\n (\"cannot be checked out on cygwin\") when trying to create 'nul', which\n might be overkill.\n\n\"Survive failing to create files\"? \"Fatal error when trying to create\n'nul', which might be overkill\"? \n\nIf you cannot faithfully recreate the work tree state, you cannot test\nthat revision. You cannot bisect and test that revision on that system.\nToo bad, but you still have \"git reset --hard\". You reset to some other\nrevision that you _can_ checkout and do sensible tests and move on.\n\nHow would you know to reset to recover from your system's deficiency\nunless git gives \"fatal error\"?\n\nThat's why I asked you to think before type, which again you did not do,\nand that is what got you get \"flamed\", even though I do not think it was\nparticularly harsh.\n"},{"id":"77967","messageId":"7vskw2tgu2.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"alpine.LNX.1.00.0805281326520.19665@iabervon.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T18:37:57Z","receivedAt":"2008-05-28T18:37:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Report a non-fatal error, mark in the index that that entry is not \n> reflected in the working directory, and allow the user to manipulate it \n> with commands that don't really need the working directory content.\n>\n> $ git checkout origin/master\n> Warning: couldn't create 't/t5100/nul' in your working directory; ignoring \n> working directory for this filename.\n> $ git mv t/t5100/nul t/t5100/nul-plain\n> $ ls t/t5100/nul-plain\n> t/t5100/nul-plain\n>\n> The working directory doesn't really have to be absolutely vital to git's \n> functioning (of course, the project you've checked out is going to have \n> problems unless you fix things). In particular, it should be possible, on \n> a machine with a broken filesystem, to modify a project that triggers the \n> filesystem breakage to not trigger it,...\n\nNow that is somebody who thinks before types.\n\nMarking that the filesystem does not match what's in index is already\ndone, so you could argue that an alternative would be not to stop in the\nmiddle of checkout_entry() loop and instead check out as much as we could,\nwrite out the index perhaps, and signal error, _AFTER_ updating everything\nelse, including the HEAD. We try to be atomic when able (e.g. on a broken\npatch, \"apply\" does not apply early half the patch and fail but rejects\nthe whole thing), but checkout_entry() loop is not something you can\nsanely make atomic (it needs to first remove existing files and even\ndirectories before writing new files), so that alternative approach might\nbe easier to work with.\n\nCare to follow it up with a patch?\n"},{"id":"77974","messageId":"alpine.LNX.1.00.0805281455100.19665@iabervon.org","threadId":"13672","inReplyTo":"7vskw2tgu2.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-28T20:06:40Z","receivedAt":"2008-05-28T20:06:40Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 May 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Report a non-fatal error, mark in the index that that entry is not \n> > reflected in the working directory, and allow the user to manipulate it \n> > with commands that don't really need the working directory content.\n> >\n> > $ git checkout origin/master\n> > Warning: couldn't create 't/t5100/nul' in your working directory; ignoring \n> > working directory for this filename.\n> > $ git mv t/t5100/nul t/t5100/nul-plain\n> > $ ls t/t5100/nul-plain\n> > t/t5100/nul-plain\n> >\n> > The working directory doesn't really have to be absolutely vital to git's \n> > functioning (of course, the project you've checked out is going to have \n> > problems unless you fix things). In particular, it should be possible, on \n> > a machine with a broken filesystem, to modify a project that triggers the \n> > filesystem breakage to not trigger it,...\n> \n> Now that is somebody who thinks before types.\n\nWell, and I've got the background to know what's possible and how git can \nkeep things straight.\n\n> Marking that the filesystem does not match what's in index is already\n> done, so you could argue that an alternative would be not to stop in the\n> middle of checkout_entry() loop and instead check out as much as we could,\n> write out the index perhaps, and signal error, _AFTER_ updating everything\n> else, including the HEAD. We try to be atomic when able (e.g. on a broken\n> patch, \"apply\" does not apply early half the patch and fail but rejects\n> the whole thing), but checkout_entry() loop is not something you can\n> sanely make atomic (it needs to first remove existing files and even\n> directories before writing new files), so that alternative approach might\n> be easier to work with.\n\nAh, yes, CE_VALID. But it doesn't quite work as well as I'd like, because \nit doesn't ignore fstat/readdir not finding anything on the filesystem, so \nit comes out looking deleted, at least if you're actually on Linux (with a \nhack in create_file to refuse to create certain filenames for testing).\n\nAlso \"git mv CE_VALID-source dest\" doesn't ignore the filesystem like it \nshould (for this use, anyway). Perhaps we need an additional flag for \"the \nfilesystem is irrelevant for this entry\".\n\n> Care to follow it up with a patch?\n\nUnfortunately, I don't think I'll have a chance for a while to actually \nwork on git code. But if someone else (Avery?) wants to try it, I think \ngiving a big warning, setting CE_VALID, and returning 0 in entry.c before \nthe \"unable to create file\" message is the right thing to start with. And \nsomeone with Windows access should figure out what happens next.\n\nI think the right test for this is if create_file() returns EEXIST, but \nreaddir doesn't show anything. For that matter, it might be useful to have \nlogic that notes the situation where you seem to have file A instead of \nfile B, but fstat(\"B\") returns A's inode, and marks the index to say that \nentry B is listed in the filesystem as A instead.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"77975","messageId":"7v7idetb1h.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"alpine.LNX.1.00.0805281455100.19665@iabervon.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T20:43:06Z","receivedAt":"2008-05-28T20:43:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Ah, yes, CE_VALID. But it doesn't quite work as well as I'd like, because \n\nNo, I do not think we should involve CE_VALID here. It means something\ncompletely different. What I meant was that through \"git status\" the user\ncan tell there is an unexpected breakage in the work tree, _if_ we make\ncheckout to finish with \"best effort\" (and still report an error).\n\n> I think the right test for this is if create_file() returns EEXIST, but \n> readdir doesn't show anything.\n\nI think relying on EEXIST is too specific for this particular breakage,\neven though such a test may catch it. A checkout may fail in the middle\nif a filesystem refuses to create a pathname that has certain characters\nin it (e.g. dosen't NTFS refuse a path with :|<\"?*> in it, or is it just\nthe Explorer UI layer rejecting them?), or perhaps one leading directory\nmay be unwritable. We would want to catch and cope with such a brokage\nthe same way.\n\nThe checkout \"unpack-trees\" codepath does:\n\n - Make sure things can be checked out safely with the internal data\n before doing anything to the filesystem, i.e. no lost local changes, no\n lost untracked files, etc.\n\n - For each path:\n\n - make room for it, removing directory at the place as necessary where\n a blob must sit and removing an existing blob as needed;\n\n - create a new file or symlink;\n\nAnd currently I think we stop on any failure. The thing is, stopping on a\nfailure during the internal checking is fine --- no external damage has\nbeen made yet. But once we started updating the work tree, we _are_\ncommitted and not aborting in the middle for a single failure would be the\nsaner thing to do. In addition, even after such a failure after we are\ncommitted, we probably should update the HEAD and the index.\n\n\"status\" would then show the difference between what should have been\nchecked out and what is. It might be enough to improve the issue of \"git\nbisect hitting a checkout failure --- the work tree is half checked-out\nstate, and the index, the HEAD, and the work tree are in a very\ninconsistent state\".\n\nWe would probably signal such an error from git-checkout differently from\nan early refusal that does not do anything, to tell the callers, such as\n\"git-bisect\", that the checkout _has been_ already done, even though there\nmay be breakages in the work tree.\n\n> ... that notes the situation where you seem to have file A instead of \n> file B, but fstat(\"B\") returns A's inode, and marks the index to say that \n> entry B is listed in the filesystem as A instead.\n\nI personally do not think such auto-substution is a way to go --- what\nmakes you trust inode information from such an untrustworthy filesystem\nthat does not do what it was told to do? I suspect that stopping at the\nerror site and not automatically making the damage yet larger by doing\nsuch magic would keep the recovery procedure simpler.\n\nBut I wouldn't keep people from experimenting. Perhaps the end result\ncould be even readable and mergeable, although I am quite pessimistic.\n"},{"id":"77978","messageId":"7vtzgirus5.fsf_-_@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"7v7idetb1h.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] \"git checkout -- paths...\" should signal error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-28T21:19:38Z","receivedAt":"2008-05-28T21:19:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When \"git checkout -- paths...\" cannot update work tree for whatever\nreason, checkout_entry() correctly issued an error message for the path to\nthe end user, but the command ignored the error, causing the entire\ncommand to succeed. This fixes it.\n\nSigned-off-by: Junio C Hamano \n---\n\n * Now that we detect this failure, post-checkout-hook _might_ want to\n know that what we have is an incomplete checkout. Not calling the hook\n in such a case may be another option, but we always called the hook and\n that would be a change in behaviour.\n\n builtin-checkout.c | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex 1ea017f..00dc8ca 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -84,6 +84,7 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec)\n \tunsigned char rev[20];\n \tint flag;\n \tstruct commit *head;\n+\tint errs = 0;\n \n \tint newfd;\n \tstruct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));\n@@ -106,13 +107,14 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec)\n \tif (report_path_error(ps_matched, pathspec, 0))\n \t\treturn 1;\n \n+\t/* Now we are committed to check them out */\n \tmemset(&state, 0, sizeof(state));\n \tstate.force = 1;\n \tstate.refresh_cache = 1;\n \tfor (pos = 0; pos < active_nr; pos++) {\n \t\tstruct cache_entry *ce = active_cache[pos];\n \t\tif (pathspec_match(pathspec, NULL, ce->name, 0)) {\n-\t\t\tcheckout_entry(ce, &state, NULL);\n+\t\t\terrs |= checkout_entry(ce, &state, NULL);\n \t\t}\n \t}\n \n@@ -123,7 +125,8 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec)\n \tresolve_ref(\"HEAD\", rev, 0, &flag);\n \thead = lookup_commit_reference_gently(rev, 1);\n \n-\treturn post_checkout_hook(head, head, 0);\n+\terrs |= post_checkout_hook(head, head, 0);\n+\treturn errs;\n }\n \n static void show_local_changes(struct object *head)\n"},{"id":"77979","messageId":"g1kjeg$1ig$1@ger.gmane.org","threadId":"13672","inReplyTo":"CB1B699D-8DC6-4FF5-96E1-072FA91F70CF@wincent.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-28T21:39:31Z","receivedAt":"2008-05-28T21:39:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Wincent Colaiuta wrote:\n\n> El 28/5/2008, a las 17:53, Lea Wiemann escribió:\n>> Wincent Colaiuta wrote:\n>>> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>>>>\n>>>> Perhaps we should remove the infamous gitweb/test/Märchen file\n>>>\n>>> [...] I'd much rather see this kind of thing tested from within \n>>> the test suite rather than every time I do \"git status\" or \"git \n>>> checkout\".\n>>\n>> I don't believe the Märchen file is actually used in any test code, \n>> so removing it should be fine. If/when we actually write test code \n>> for gitweb, it seems to me that we might as well generate such test \n>> files on the fly from within the test suite, rather than having them \n>> in the file system permanently.\n> \n> Yes, that's exactly what I intended my comment to imply. Test at test \n> time, not every time I do \"git status\" and \"git checkout\" etc.\n\nI think it is remainder (the whole gitweb/test/ directory) from the\ntimes when gitweb was separate project, and not part of git.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"77980","messageId":"alpine.LNX.1.00.0805281649310.19665@iabervon.org","threadId":"13672","inReplyTo":"7v7idetb1h.fsf@gitster.siamese.dyndns.org","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-28T21:41:18Z","receivedAt":"2008-05-28T21:41:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 May 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Ah, yes, CE_VALID. But it doesn't quite work as well as I'd like, because \n> \n> No, I do not think we should involve CE_VALID here. It means something\n> completely different. What I meant was that through \"git status\" the user\n> can tell there is an unexpected breakage in the work tree, _if_ we make\n> checkout to finish with \"best effort\" (and still report an error).\n\nI think there are two separate issues here: (1) you've gotten partway \nthrough a checkout, and something fails, and we want to leave things in as \ngood shape as possible; (2) you're trying to check out a tree that can't \nbe accurately represented on your filesystem. In case (2), there's a good \nchance that you want to leave the unrepresentable stuff alone or modify it \nin the index without going through the filesystem.\n\nCase (2) is very much like working on a filesystem without +x bits, where \nyou'd really like to ignore what the filesystem reports and only diverge \nfrom what was read into the index from a tree object when the user makes \nexplicit modifications to the index, rather than updating the index from \nthe working directory state.\n\n> > I think the right test for this is if create_file() returns EEXIST, but \n> > readdir doesn't show anything.\n> \n> I think relying on EEXIST is too specific for this particular breakage,\n> even though such a test may catch it. \n\nIt's not just EEXIST; it's EEXIST for a filename with no struct dirent.\n\n> A checkout may fail in the middle if a filesystem refuses to create a \n> pathname that has certain characters in it (e.g. dosen't NTFS refuse a \n> path with :|<\"?*> in it, or is it just the Explorer UI layer rejecting \n> them?), or perhaps one leading directory may be unwritable. We would \n> want to catch and cope with such a brokage the same way.\n\nI think the leading directory thing is qualitatively different; you're \nprobably not going to want to create a patch to rename all of the files in \nthat directory to be in a directory that's not owned by a different user \non your machine, while you are likely to try to get a project to use less \nodd names if there's a filename with a : in it or something. I'm not sure \nwhat error open() will give you for that.\n\nThe other interesting case is when the filesystem is case insensative and \nthe project contains files that differ only in case; again, the filesystem \nwill report EEXIST on open for a path that readdir doesn't list.\n\n> The checkout \"unpack-trees\" codepath does:\n> \n> - Make sure things can be checked out safely with the internal data\n> before doing anything to the filesystem, i.e. no lost local changes, no\n> lost untracked files, etc.\n> \n> - For each path:\n> \n> - make room for it, removing directory at the place as necessary where\n> a blob must sit and removing an existing blob as needed;\n> \n> - create a new file or symlink;\n> \n> And currently I think we stop on any failure. The thing is, stopping on a\n> failure during the internal checking is fine --- no external damage has\n> been made yet. But once we started updating the work tree, we _are_\n> committed and not aborting in the middle for a single failure would be the\n> saner thing to do. In addition, even after such a failure after we are\n> committed, we probably should update the HEAD and the index.\n> \n> \"status\" would then show the difference between what should have been\n> checked out and what is. It might be enough to improve the issue of \"git\n> bisect hitting a checkout failure --- the work tree is half checked-out\n> state, and the index, the HEAD, and the work tree are in a very\n> inconsistent state\".\n\nFor case (1), things are in an inconsistant state; for case (2), the index \nand HEAD agree, and there are known gaps in the work tree.\n\n> We would probably signal such an error from git-checkout differently from\n> an early refusal that does not do anything, to tell the callers, such as\n> \"git-bisect\", that the checkout _has been_ already done, even though there\n> may be breakages in the work tree.\n> \n> > ... that notes the situation where you seem to have file A instead of \n> > file B, but fstat(\"B\") returns A's inode, and marks the index to say that \n> > entry B is listed in the filesystem as A instead.\n> \n> I personally do not think such auto-substution is a way to go --- what\n> makes you trust inode information from such an untrustworthy filesystem\n> that does not do what it was told to do? I suspect that stopping at the\n> error site and not automatically making the damage yet larger by doing\n> such magic would keep the recovery procedure simpler.\n\nPeople seem to use Windows and OS X despite the filesystems being broken. \nThere seems to be a space of filesystems which aren't corrupted, but do \nunexpected things with respect to filenames. If we can find appropriate \nfilenames, the content is stored reliably (or the open O_EXCL is refused). \nWe should be able to identify that the user isn't trying to make a change \nby way of the working directory when the difference we see is something \nthat isn't clearly representable by the filesystem.\n\n> But I wouldn't keep people from experimenting. Perhaps the end result\n> could be even readable and mergeable, although I am quite pessimistic.\n\nI think, in any case, that it should be pretty clean to have a \"filesystem \nis inadaquate\" CE flag, which mean that we just ignore the filesystem. \nFinding things that are reported with the wrong name is probably harder.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"78019","messageId":"483E4D09.1070400@trolltech.com","threadId":"13672","inReplyTo":"7vtzgirus5.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] \"git checkout -- paths...\" should signal error","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2008-05-29T06:28:25Z","receivedAt":"2008-05-29T06:28:25Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Junio C Hamano said the following on 28.05.2008 23:19:\n> When \"git checkout -- paths...\" cannot update work tree for whatever\n> reason, checkout_entry() correctly issued an error message for the path to\n> the end user, but the command ignored the error, causing the entire\n> command to succeed. This fixes it.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> * Now that we detect this failure, post-checkout-hook _might_ want to\n> know that what we have is an incomplete checkout. Not calling the hook\n> in such a case may be another option, but we always called the hook and\n> that would be a change in behaviour.\n> \n> builtin-checkout.c | 7 +++++--\n> 1 files changed, 5 insertions(+), 2 deletions(-)\n> \n> diff --git a/builtin-checkout.c b/builtin-checkout.c\n\nI'd like to just chip in that you actually _can_ create those files \n(nul, con, prn, all which are \"special\" filenames on Windows), but \nneed a slight different construct to create them. That, and most tools \nwill break on _using_ them, since they's also have to refer to them in \na certain way.\n\nSo, certainly msysgit could write a workaround to handle such cases. \n(Git would also know how to remove these files on Windows)\n\nThough, I still think that your patch is a Good Thing(tm).\n\n\nFor example, if you:\n\nD:\\some\\path> echo foo > nul # Ok, an no output, nor file created\nD:\\some\\path> echo foo > .\\nul # Same thing\nD:\\some\\path> echo foo > \\\\.\\d:\\some\\path\\nul # Creates the nul file\n\n Directory of D:\\some\\path\n\n29.05.2008 08:23 .\n29.05.2008 08:23 ..\n29.05.2008 08:23 6 con\n29.05.2008 08:22 6 nul\n29.05.2008 08:23 6 prn\n 3 File(s) 18 bytes\n\nD:\\some\\path> del .\\nul\nThe filename, directory name, or volume label syntax is incorrect.\n\nD:\\some\\path> del \\\\.\\d:\\some\\path\\nul # Success\n\n-- \n.marius [@trolltech.com]\n'if you know what you're doing, it's not research'\n\n"},{"id":"78037","messageId":"alpine.LNX.1.00.0805290905020.19665@iabervon.org","threadId":"13672","inReplyTo":"7vtzgirus5.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH] \"git checkout -- paths...\" should signal error","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-05-29T13:05:43Z","receivedAt":"2008-05-29T13:05:43Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 May 2008, Junio C Hamano wrote:\n\n> When \"git checkout -- paths...\" cannot update work tree for whatever\n> reason, checkout_entry() correctly issued an error message for the path to\n> the end user, but the command ignored the error, causing the entire\n> command to succeed. This fixes it.\n\nAcked-by: Daniel Barkalow \n"},{"id":"78041","messageId":"alpine.DEB.1.00.0805291422210.13507@racer.site.net","threadId":"13672","inReplyTo":"100A0CFD-EB6F-48F1-B917-811310CCFB6E@wincent.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-29T13:22:48Z","receivedAt":"2008-05-29T13:22:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 May 2008, Wincent Colaiuta wrote:\n\n> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>\n> >Perhaps we should remove the infamous gitweb/test/Märchen file while we \n> >are at it? I do not think the file is ever used.\n> \n> I for one would love to see it go, seeing as I live in the ghetto that \n> is HFS+ and am constantly annoyed by it cluttering up my status output \n> with spurious content.\n> \n> I understand that the reason it lives in the tree is precisely to \n> discover problems with such filesystems, but the problem is well and \n> truly discovered by now and I'd much rather see this kind of thing \n> tested from within the test suite rather than every time I do \"git \n> status\" or \"git checkout\".\n\nProbably you are not enoyed enough to just go and fix it.\n\nCiao,\nDscho\n"},{"id":"78050","messageId":"29FDE86E-5B83-4736-8CC6-9C5697B91B2C@wincent.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805291422210.13507@racer.site.net","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-05-29T14:58:21Z","receivedAt":"2008-05-29T14:58:21Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 29/5/2008, a las 15:22, Johannes Schindelin escribió:\n> Hi,\n>\n> On Wed, 28 May 2008, Wincent Colaiuta wrote:\n>\n>> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>>\n>>> Perhaps we should remove the infamous gitweb/test/Märchen file \n>>> while we\n>>> are at it? I do not think the file is ever used.\n>>\n>> I for one would love to see it go, seeing as I live in the ghetto \n>> that\n>> is HFS+ and am constantly annoyed by it cluttering up my status \n>> output\n>> with spurious content.\n>>\n>> I understand that the reason it lives in the tree is precisely to\n>> discover problems with such filesystems, but the problem is well and\n>> truly discovered by now and I'd much rather see this kind of thing\n>> tested from within the test suite rather than every time I do \"git\n>> status\" or \"git checkout\".\n>\n> Probably you are not enoyed enough to just go and fix it.\n\nNo, that's not actually the case. In reality I was pleasantly \nsurprised when Junio commented that \"perhaps we should remove\" that \nfile; I had always gotten the impression from this list that such a \nchange would be unwelcome because it's easier to just blame the users \nof bad filesystems for choosing those filesystems. I also remember a \ncomment from Linus to the effect that that file was kept in the tree \nprecisely _because_ it helped us discover such file systems. \nUnfortunately I can't find that message right now but I think it was \nabout 6 months ago.\n\nIf the powers that be will accept a change that removes Märchen I'll \nbe more than happy to whip up a patch.\n\nWincent\n"},{"id":"78055","messageId":"alpine.DEB.1.00.0805291704280.13507@racer.site.net","threadId":"13672","inReplyTo":"29FDE86E-5B83-4736-8CC6-9C5697B91B2C@wincent.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-29T16:05:53Z","receivedAt":"2008-05-29T16:05:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 May 2008, Wincent Colaiuta wrote:\n\n> El 29/5/2008, a las 15:22, Johannes Schindelin escribió:\n>\n> >Probably you are not enoyed enough to just go and fix it.\n> \n> No, that's not actually the case. In reality I was pleasantly surprised \n> when Junio commented that \"perhaps we should remove\" that file;\n\nYou misunderstood me. I was not talking about \"fixing\" it by removing the \nfile, and papering over the UTF-8 issue on HFS+.\n\nI was talking about fixing it by handling UTF-8 in a way that is \ncompatible with (maybe stupid, but that cannot be helped) HFS+.\n\nCiao,\nDscho"},{"id":"78057","messageId":"39D76264-2051-4751-85BC-F79956FE9D57@wincent.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0805291704280.13507@racer.site.net","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-05-29T16:15:00Z","receivedAt":"2008-05-29T16:15:00Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 29/5/2008, a las 18:05, Johannes Schindelin escribió:\n> Hi,\n>\n> On Thu, 29 May 2008, Wincent Colaiuta wrote:\n>\n>> El 29/5/2008, a las 15:22, Johannes Schindelin escribió:\n>>\n>>> Probably you are not enoyed enough to just go and fix it.\n>>\n>> No, that's not actually the case. In reality I was pleasantly \n>> surprised\n>> when Junio commented that \"perhaps we should remove\" that file;\n>\n> You misunderstood me. I was not talking about \"fixing\" it by \n> removing the\n> file, and papering over the UTF-8 issue on HFS+.\n>\n> I was talking about fixing it by handling UTF-8 in a way that is\n> compatible with (maybe stupid, but that cannot be helped) HFS+.\n\nAh, ok. That's way beyond my skill set and a completely different \nsubject. I was responding to Junio's comment about _removing_ the file.\n\nWincent\n"},{"id":"78237","messageId":"28EDBE43-6E55-4EC9-97C6-8AC8D949E82D@zib.de","threadId":"13672","inReplyTo":"29FDE86E-5B83-4736-8CC6-9C5697B91B2C@wincent.com","subject":"Re: Commit cce8d6fdb introduces file t/t5100/nul, git tree is now incompatible with Cygwin (and probably Windows)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-05-31T17:37:48Z","receivedAt":"2008-05-31T17:37:48Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn May 29, 2008, at 4:58 PM, Wincent Colaiuta wrote:\n\n> El 29/5/2008, a las 15:22, Johannes Schindelin escribió:\n>>\n>>\n>> On Wed, 28 May 2008, Wincent Colaiuta wrote:\n>>\n>>> El 28/5/2008, a las 8:12, Junio C Hamano escribió:\n>>>\n>>>> Perhaps we should remove the infamous gitweb/test/Märchen file \n>>>> while we\n>>>> are at it? I do not think the file is ever used.\n>>>\n>>> I for one would love to see it go, seeing as I live in the ghetto \n>>> that\n>>> is HFS+ and am constantly annoyed by it cluttering up my status \n>>> output\n>>> with spurious content.\n>>>\n>>> I understand that the reason it lives in the tree is precisely to\n>>> discover problems with such filesystems, but the problem is well and\n>>> truly discovered by now and I'd much rather see this kind of thing\n>>> tested from within the test suite rather than every time I do \"git\n>>> status\" or \"git checkout\".\n>>\n>> Probably you are not enoyed enough to just go and fix it.\n>\n\n[...]\n\n>\n> If the powers that be will accept a change that removes Märchen I'll \n> be more than happy to whip up a patch.\n\n\nUnicode normalization is tested in t/t0050-filesystem.sh, which\nreports on HFS+:\n\n* still broken 8: rename (silent unicode normalization)\n* still broken 9: merge (silent unicode normalization)\n\nI believe there is no value in keeping gitweb/test/Märchen for the\nreason of testing HFS+, so I vote for removing it, unless there\nis another good reason for keeping it.\n\n\tSteffen\n"},{"id":"78240","messageId":"20080531182555.1646.47950.stgit@localhost.localdomain","threadId":"13672","inReplyTo":"28EDBE43-6E55-4EC9-97C6-8AC8D949E82D@zib.de","subject":"[PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-31T18:28:18Z","receivedAt":"2008-05-31T18:28:18Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Testing if gitweb handles filenames with spaces, filenames with plus\nsign ('+') which encodes spaces in CGI parameters (in URLs), and\nfilenames with Unicode characters should be handled by gitweb tests.\n\nThose files are remainder of the time when gitweb was project on its\nown, not a part of git (with its testsuite).\n\nSigned-off-by: Jakub Narebski \n---\nOn Sat, 31 May 2008 19:37:48 +0200, Steffen Prohaska wrote:\n> On May 29, 2008, at 4:58 PM, Wincent Colaiuta wrote:\n>\n[...]\n>> If the powers that be will accept a change that removes M�rchen I'll \n>> be more than happy to whip up a patch.\n> \n> Unicode normalization is tested in t/t0050-filesystem.sh, which\n> reports on HFS+:\n> \n> * still broken 8: rename (silent unicode normalization)\n> * still broken 9: merge (silent unicode normalization)\n> \n> I believe there is no value in keeping gitweb/test/M�rchen for the\n> reason of testing HFS+, so I vote for removing it, unless there\n> is another good reason for keeping it.\n\nSo here it is, the patch to remove offending file; well: the whole\ngitweb/test/ directory. \n\n \"gitweb/test/M\\303\\244rchen\" | 2 --\n gitweb/test/file with spaces | 4 ----\n gitweb/test/file+plus+sign | 6 ------\n 3 files changed, 0 insertions(+), 12 deletions(-)\n delete mode 100644 gitweb/test/Märchen\n delete mode 100644 gitweb/test/file with spaces\n delete mode 100644 gitweb/test/file+plus+sign\n\ndiff --git \"a/gitweb/test/M\\303\\244rchen\" \"b/gitweb/test/M\\303\\244rchen\"\ndeleted file mode 100644\nindex 8f7a1d3..0000000\n--- \"a/gitweb/test/M\\303\\244rchen\"\n+++ /dev/null\n@@ -1,2 +0,0 @@\n-Märchen\n-M�rchen\ndiff --git a/gitweb/test/file with spaces b/gitweb/test/file with spaces\ndeleted file mode 100644\nindex f108543..0000000\n--- a/gitweb/test/file with spaces\t\n+++ /dev/null\n@@ -1,4 +0,0 @@\n-This\n-filename\n-contains\n-spaces.\ndiff --git a/gitweb/test/file+plus+sign b/gitweb/test/file+plus+sign\ndeleted file mode 100644\nindex fd05278..0000000\n--- a/gitweb/test/file+plus+sign\n+++ /dev/null\n@@ -1,6 +0,0 @@\n-This\n-filename\n-contains\n-+\n-plus\n-chars.\n"},{"id":"78242","messageId":"5DBABAFE-C447-4E5D-A7E8-0C16B4D1D960@wincent.com","threadId":"13672","inReplyTo":"20080531182555.1646.47950.stgit@localhost.localdomain","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-05-31T18:49:04Z","receivedAt":"2008-05-31T18:49:04Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 31/5/2008, a las 20:28, Jakub Narebski escribió:\n\n> Testing if gitweb handles filenames with spaces, filenames with plus\n> sign ('+') which encodes spaces in CGI parameters (in URLs), and\n> filenames with Unicode characters should be handled by gitweb tests.\n>\n> Those files are remainder of the time when gitweb was project on its\n> own, not a part of git (with its testsuite).\n>\n> Signed-off-by: Jakub Narebski \n\nAck.\nWincent\n"},{"id":"78255","messageId":"alpine.DEB.1.00.0806010018300.13507@racer.site.net","threadId":"13672","inReplyTo":"5DBABAFE-C447-4E5D-A7E8-0C16B4D1D960@wincent.com","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-31T23:19:02Z","receivedAt":"2008-05-31T23:19:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 31 May 2008, Wincent Colaiuta wrote:\n\n> El 31/5/2008, a las 20:28, Jakub Narebski escribió:\n> \n> > Testing if gitweb handles filenames with spaces, filenames with plus \n> > sign ('+') which encodes spaces in CGI parameters (in URLs), and \n> > filenames with Unicode characters should be handled by gitweb tests.\n> >\n> > Those files are remainder of the time when gitweb was project on its \n> > own, not a part of git (with its testsuite).\n> >\n> > Signed-off-by: Jakub Narebski \n> \n> Ack.\n\nAnd I thought \"Ack\" was reserved for the people who are considered the \nprimary authors of the patched code...\n\nCiao,\nDscho\n"},{"id":"78259","messageId":"200806010219.16773.jnareb@gmail.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0806010018300.13507@racer.site.net","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-01T00:19:15Z","receivedAt":"2008-06-01T00:19:15Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 1 Jan 2008, Johannes Schindelin wrote:\n> On Sat, 31 May 2008, Wincent Colaiuta wrote:\n>> El 31/5/2008, a las 20:28, Jakub Narebski escribió:\n>> \n>>> Testing if gitweb handles filenames with spaces, filenames with plus \n>>> sign ('+') which encodes spaces in CGI parameters (in URLs), and \n>>> filenames with Unicode characters should be handled by gitweb tests.\n>>>\n>>> Those files are remainder of the time when gitweb was project on its \n>>> own, not a part of git (with its testsuite).\n>>>\n>>> Signed-off-by: Jakub Narebski \n>> \n>> Ack.\n> \n> And I thought \"Ack\" was reserved for the people who are considered the \n> primary authors of the patched code...\n\nUnfortunately, as far as I know, primary and only author of those\nlines of code, maintainer of gitweb when it was separate project,\nKay Sievers, is no longer active in git development.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"78261","messageId":"7v7idadkv0.fsf@gitster.siamese.dyndns.org","threadId":"13672","inReplyTo":"20080531182555.1646.47950.stgit@localhost.localdomain","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-01T01:06:43Z","receivedAt":"2008-06-01T01:06:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Testing if gitweb handles filenames with spaces, filenames with plus\n> sign ('+') which encodes spaces in CGI parameters (in URLs), and\n> filenames with Unicode characters should be handled by gitweb tests.\n>\n> Those files are remainder of the time when gitweb was project on its\n> own, not a part of git (with its testsuite).\n>\n> Signed-off-by: Jakub Narebski \n> ---\n> ...\n> \"gitweb/test/M\\303\\244rchen\" | 2 --\n> gitweb/test/file with spaces | 4 ----\n> gitweb/test/file+plus+sign | 6 ------\n> 3 files changed, 0 insertions(+), 12 deletions(-)\n> delete mode 100644 gitweb/test/Märchen\n> delete mode 100644 gitweb/test/file with spaces\n> delete mode 100644 gitweb/test/file+plus+sign\n\nI do not think Kay minds, but it would not hurt to give him a courtesy\ncopy of this before finally applying such a patch.\n\n-jc\n"},{"id":"78262","messageId":"200806010359.43264.jnareb@gmail.com","threadId":"13672","inReplyTo":"7v7idadkv0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-01T01:59:42Z","receivedAt":"2008-06-01T01:59:42Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 1 Jun 2008, Junio C Hamano wrote:\n\n> I do not think Kay minds, but it would not hurt to give him a courtesy\n> copy of this before finally applying such a patch.\n\nDone.\n-- \nJakub Narebski\nPoland\n"},{"id":"78283","messageId":"1212313361.2446.21.camel@linux.site","threadId":"13672","inReplyTo":"200806010219.16773.jnareb@gmail.com","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Kay Sievers","fromEmail":"kay.sievers@suse.de","sentAt":"2008-06-01T09:42:41Z","receivedAt":"2008-06-01T09:42:41Z","isPatch":true,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Sun, 2008-06-01 at 02:19 +0200, Jakub Narebski wrote:\n> On Sun, 1 Jan 2008, Johannes Schindelin wrote:\n> > On Sat, 31 May 2008, Wincent Colaiuta wrote:\n> >> El 31/5/2008, a las 20:28, Jakub Narebski escribió:\n> >> \n> >>> Testing if gitweb handles filenames with spaces, filenames with plus \n> >>> sign ('+') which encodes spaces in CGI parameters (in URLs), and \n> >>> filenames with Unicode characters should be handled by gitweb tests.\n> >>>\n> >>> Those files are remainder of the time when gitweb was project on its \n> >>> own, not a part of git (with its testsuite).\n> >>>\n> >>> Signed-off-by: Jakub Narebski \n> >> \n> >> Ack.\n> > \n> > And I thought \"Ack\" was reserved for the people who are considered the \n> > primary authors of the patched code...\n> \n> Unfortunately, as far as I know, primary and only author of those\n> lines of code, maintainer of gitweb when it was separate project,\n> Kay Sievers, is no longer active in git development.\n\nSure, feel free to do whatever makes sense, there is no reason to get my\nACK, as I'm not actively working on it anymore. I'm glad, you guys take\ncare of gitweb these days, and it has improved a lot since then.\n\nThanks,\nKay\n"},{"id":"78304","messageId":"97942300-E8AC-4AC6-AD4D-6EEA2198E5D9@wincent.com","threadId":"13672","inReplyTo":"alpine.DEB.1.00.0806010018300.13507@racer.site.net","subject":"Re: [PATCH] gitweb: Remove gitweb/test/ directory","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-01T19:07:44Z","receivedAt":"2008-06-01T19:07:44Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 1/6/2008, a las 1:19, Johannes Schindelin escribió:\n\n> Hi,\n>\n> On Sat, 31 May 2008, Wincent Colaiuta wrote:\n>\n>> El 31/5/2008, a las 20:28, Jakub Narebski escribió:\n>>\n>>> Testing if gitweb handles filenames with spaces, filenames with plus\n>>> sign ('+') which encodes spaces in CGI parameters (in URLs), and\n>>> filenames with Unicode characters should be handled by gitweb tests.\n>>>\n>>> Those files are remainder of the time when gitweb was project on its\n>>> own, not a part of git (with its testsuite).\n>>>\n>>> Signed-off-by: Jakub Narebski \n>>\n>> Ack.\n>\n> And I thought \"Ack\" was reserved for the people who are considered the\n> primary authors of the patched code...\n\nI had no idea. Thanks for letting me know.\n\nWincent\n"}]}