{"thread":{"id":"41363","subject":"update_linked_gitdir writes relative path to .git/worktrees//gitdir","startedAt":"2016-02-06T20:12:28Z","lastAt":"2016-02-09T21:02:11Z","messageCount":10,"participants":["Matt McCutchen","Junio C Hamano","Duy Nguyen","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"277681","messageId":"1454789548.23898.223.camel@mattmccutchen.net","threadId":"41363","inReplyTo":null,"subject":"update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-02-06T20:12:28Z","receivedAt":"2016-02-06T20:12:28Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"I noticed that when update_linked_gitdir chooses to update\n.git/worktrees//gitdir, the path it writes is relative, at least\nunder some circumstances.  This contradicts the gitrepository-layout\nman page, which says:\n\nworktrees//gitdir::\n        A text file containing the absolute path back to the .git file\n        that points to here.\n\nIIUC, this behavior defeats one of the three safeguards that is\nsupposed to prevent \"git worktree prune\" from pruning information for\nworktrees that still exist.\n\nA simple script to reproduce:\n\n#!/bin/bash\nset -e -x\nrm -rf repo worktree2\ngit init repo\ncd repo\ntouch foo\ngit add foo\ngit commit -m 'dummy commit'\ngit worktree add ../worktree2 -b branch2\ncat .git/worktrees/worktree2/gitdir\ntouch -d '2 days ago' .git/worktrees/worktree2/gitdir\n(cd ../worktree2 && git status)\ncat .git/worktrees/worktree2/gitdir\n\nTrying this on master as of earlier today (ff4ea60), I get:\n\n[...]\n/PATH/REDACTED/worktree2/.git\n[...]\n.git\n\nMatt\n"},{"id":"277703","messageId":"xmqqlh6w9isp.fsf@gitster.mtv.corp.google.com","threadId":"41363","inReplyTo":"1454789548.23898.223.camel@mattmccutchen.net","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-07T23:56:06Z","receivedAt":"2016-02-07T23:56:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt McCutchen writes:\n\n> I noticed that when update_linked_gitdir chooses to update\n> .git/worktrees//gitdir, the path it writes is relative, at least\n> under some circumstances.  This contradicts the gitrepository-layout\n> man page, which says:\n\nDuy, is it safe to say that the fix has already been cooking in\n'next' as nd/do-not-move-worktree-manually topic, we are about to\nsolve this by merging down to 'master', _and_ it is very much\nappreciated when reporting bugs people check if a presumed fix is\nalready cooking in 'next', try it to verify if it really fixes their\nproblem, and send in a \"OK fix is good\" / \"No that does not fix my\ncase\"?\n\n>\n> worktrees//gitdir::\n>         A text file containing the absolute path back to the .git file\n>         that points to here.\n>\n> IIUC, this behavior defeats one of the three safeguards that is\n> supposed to prevent \"git worktree prune\" from pruning information for\n> worktrees that still exist.\n>\n> A simple script to reproduce:\n>\n> #!/bin/bash\n> set -e -x\n> rm -rf repo worktree2\n> git init repo\n> cd repo\n> touch foo\n> git add foo\n> git commit -m 'dummy commit'\n> git worktree add ../worktree2 -b branch2\n> cat .git/worktrees/worktree2/gitdir\n> touch -d '2 days ago' .git/worktrees/worktree2/gitdir\n> (cd ../worktree2 && git status)\n> cat .git/worktrees/worktree2/gitdir\n>\n> Trying this on master as of earlier today (ff4ea60), I get:\n>\n> [...]\n> /PATH/REDACTED/worktree2/.git\n> [...]\n> .git\n>\n> Matt\n"},{"id":"277706","messageId":"1454893478.2511.5.camel@mattmccutchen.net","threadId":"41363","inReplyTo":"xmqqlh6w9isp.fsf@gitster.mtv.corp.google.com","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-02-08T01:04:38Z","receivedAt":"2016-02-08T01:04:38Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:\n> Matt McCutchen writes:\n> \n> > I noticed that when update_linked_gitdir chooses to update\n> > .git/worktrees//gitdir, the path it writes is relative, at\n> > least\n> > under some circumstances.  This contradicts the gitrepository-\n> > layout\n> > man page, which says:\n> \n> Duy, is it safe to say that the fix has already been cooking in\n> 'next' as nd/do-not-move-worktree-manually topic,\n\nYes, looks like that topic removes the buggy functionality.\n\n> it is very much\n> appreciated when reporting bugs people check if a presumed fix is\n> already cooking in 'next', try it to verify if it really fixes their\n> problem, and send in a \"OK fix is good\" / \"No that does not fix my\n> case\"?\n\nSorry to waste your time.  This wasn't documented where I looked,\nnamely the \"Bug Reporting\" section on http://git-scm.com/community .\n Here's a straw-man proposed update to that page:\n\nhttps://github.com/mattmccutchen/git-scm.com/compare/master...bug-reporting-next\n\nIf you like it, I will submit it as a pull request.  I can propose a\nsimilar update to the \"REPORTING BUGS\" section of the git(1) man page\nif you like.\n\nMatt\n"},{"id":"277710","messageId":"CACsJy8D-dk7aHttHxeGYPuqRUQFx40AJyQQ39gVQvmM2Ttr1pA@mail.gmail.com","threadId":"41363","inReplyTo":"1454893478.2511.5.camel@mattmccutchen.net","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-08T04:56:59Z","receivedAt":"2016-02-08T04:56:59Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 8, 2016 at 8:04 AM, Matt McCutchen wrote:\n> On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:\n>> Matt McCutchen writes:\n>>\n>> > I noticed that when update_linked_gitdir chooses to update\n>> > .git/worktrees//gitdir, the path it writes is relative, at\n>> > least\n>> > under some circumstances. This contradicts the gitrepository-\n>> > layout\n>> > man page, which says:\n>>\n>> Duy, is it safe to say that the fix has already been cooking in\n>> 'next' as nd/do-not-move-worktree-manually topic,\n>\n> Yes, looks like that topic removes the buggy functionality.\n\nI'm also pretty sure it's update_linked_gitdir() that writes relative\npath. So yes nd/do-not-move-worktree-manually should \"fix\" it. We\ndon't have a way to recover broken gitdir files though.\n-- \nDuy\n"},{"id":"277728","messageId":"20160208135607.GB27054@sigill.intra.peff.net","threadId":"41363","inReplyTo":"1454893478.2511.5.camel@mattmccutchen.net","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-08T13:56:07Z","receivedAt":"2016-02-08T13:56:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 07, 2016 at 08:04:38PM -0500, Matt McCutchen wrote:\n\n> > it is very much\n> > appreciated when reporting bugs people check if a presumed fix is\n> > already cooking in 'next', try it to verify if it really fixes their\n> > problem, and send in a \"OK fix is good\" / \"No that does not fix my\n> > case\"?\n> \n> Sorry to waste your time.  This wasn't documented where I looked,\n> namely the \"Bug Reporting\" section on http://git-scm.com/community .\n>  Here's a straw-man proposed update to that page:\n> \n> https://github.com/mattmccutchen/git-scm.com/compare/master...bug-reporting-next\n> \n> If you like it, I will submit it as a pull request.  I can propose a\n> similar update to the \"REPORTING BUGS\" section of the git(1) man page\n> if you like.\n\nFWIW, as the person who wrote that section, I think that is a good\naddition. We do have a link to Simon Tatham's bug-reporting guide, but\nthis is a good place to put project-specific advice.\n\nIn addition to \"try it on next\" you may want to also mention \"try it on\nthe latest version of git\". That is another frequently given pointer to\nbug reporters. Trying \"next\" is obviously a superset, but I suspect\ntrying a released version may be an easier first step for some people.\n\n-Peff\n"},{"id":"277777","messageId":"xmqqziva6e6e.fsf@gitster.mtv.corp.google.com","threadId":"41363","inReplyTo":"20160208135607.GB27054@sigill.intra.peff.net","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-08T22:16:25Z","receivedAt":"2016-02-08T22:16:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> FWIW, as the person who wrote that section, I think that is a good\n> addition. We do have a link to Simon Tatham's bug-reporting guide, but\n> this is a good place to put project-specific advice.\n>\n> In addition to \"try it on next\" you may want to also mention \"try it on\n> the latest version of git\". That is another frequently given pointer to\n> bug reporters. Trying \"next\" is obviously a superset, but I suspect\n> trying a released version may be an easier first step for some people.\n\nYes, definitely.\n\nI agree that testing with the latest released version would\ntypically be much easier to end users than building from the source.\nIt would reduce the need for \"Ah, that's ancient issue, we know it\nwas fixed a few releases ago.\" responses by us; I do not recall many\nof such responses in the recent history on the list, though.\n\nFor the ones who are more into the spirit of helping each other who\ncan build from the source to help us even more, checking 'master'\nand finding regressions before it gets too late is a very good\nthing. Checking 'next' and confirming an upcoming fix is equally\nvaluable.\n"},{"id":"277816","messageId":"1455048415.2511.200.camel@mattmccutchen.net","threadId":"41363","inReplyTo":"20160208135607.GB27054@sigill.intra.peff.net","subject":"[PATCH] git.txt: encourage bug reporters to test recent versions","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-02-09T00:34:25Z","receivedAt":"2016-02-09T00:34:25Z","isPatch":true,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"Specifically, the latest released version or the \"next\" branch, as\nreporters are willing. This is based on:\n\n http://marc.info/?l=git&m=145496979420513&w=2\n\nSigned-off-by: Matt McCutchen \n---\n Documentation/git.txt | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex d987ad2..1a148bc 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -1226,7 +1226,11 @@ Reporting Bugs\n \n Report bugs to the Git mailing list where the\n development and maintenance is primarily done. You do not have to be\n-subscribed to the list to send a message there.\n+subscribed to the list to send a message there. You can help us out by\n+attempting to reproduce the bug in the latest released version of git,\n+or if you're willing to build git from source, the `next` branch.\n+Sometimes an attempted fix may be pending in this branch, in which case\n+your feedback as to whether the fix worked for you will be appreciated.\n \n SEE ALSO\n --------\n-- \n2.5.0\n"},{"id":"277815","messageId":"1455048354.2511.199.camel@mattmccutchen.net","threadId":"41363","inReplyTo":"xmqqziva6e6e.fsf@gitster.mtv.corp.google.com","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-02-09T20:05:54Z","receivedAt":"2016-02-09T20:05:54Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > FWIW, as the person who wrote that section, I think that is a good\n> > addition.  We do have a link to Simon Tatham's bug-reporting guide, but\n> > this is a good place to put project-specific advice.\n> > \n> > In addition to \"try it on next\" you may want to also mention \"try it on\n> > the latest version of git\". That is another frequently given pointer to\n> > bug reporters.  Trying \"next\" is obviously a superset, but I suspect\n> > trying a released version may be an easier first step for some people.\n> \n> Yes, definitely.\n> \n> I agree that testing with the latest released version would\n> typically be much easier to end users than building from the source.\n> It would reduce the need for \"Ah, that's ancient issue, we know it\n> was fixed a few releases ago.\" responses by us; I do not recall many\n> of such responses in the recent history on the list, though.\n> \n> For the ones who are more into the spirit of helping each other who\n> can build from the source to help us even more, checking 'master'\n> and finding regressions before it gets too late is a very good\n> thing.  Checking 'next' and confirming an upcoming fix is equally\n> valuable.\n\nOK, so this testing is an encouragement, not an expectation per se,\neven if bug reports may be less likely to get attention without it (I'm\nnot familiar with the degree to which this may have been the case\nrecently).  See my revised proposed text here:\n\nhttps://github.com/git/git-scm.com/pull/676/files\n\nI'll send an analogous patch for the git(1) man page in a moment.\n\nI left a mention of providing feedback on pending fixes but thought it\nwould be too much to go into the details of how to identify whether\nthere is a pending fix.  Is this sensible?\n\nMatt\n"},{"id":"277818","messageId":"1455049839.2511.208.camel@mattmccutchen.net","threadId":"41363","inReplyTo":"xmqqziva6e6e.fsf@gitster.mtv.corp.google.com","subject":"Making the \"Note from the maintainer\" information discoverable","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-02-09T20:30:39Z","receivedAt":"2016-02-09T20:30:39Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > FWIW, as the person who wrote that section, I think that is a good\n> > addition.  We do have a link to Simon Tatham's bug-reporting guide,\n> > but\n> > this is a good place to put project-specific advice.\n> > \n> > In addition to \"try it on next\" you may want to also mention \"try\n> > it on\n> > the latest version of git\". That is another frequently given\n> > pointer to\n> > bug reporters.  Trying \"next\" is obviously a superset, but I\n> > suspect\n> > trying a released version may be an easier first step for some\n> > people.\n> \n> Yes, definitely.\n> \n> I agree that testing with the latest released version would\n> typically be much easier to end users than building from the source.\n> It would reduce the need for \"Ah, that's ancient issue, we know it\n> was fixed a few releases ago.\" responses by us; I do not recall many\n> of such responses in the recent history on the list, though.\n> \n> For the ones who are more into the spirit of helping each other who\n> can build from the source to help us even more, checking 'master'\n> and finding regressions before it gets too late is a very good\n> thing.  Checking 'next' and confirming an upcoming fix is equally\n> valuable.\n\nWhile researching an unrelated issue, I stumbled upon\nhttp://marc.info/?l=git&m=142714670111063&w=2, which seems to have even\nmore valuable information about community processes.  Is there any\ninterest in making this information discoverable from\nhttps://git-scm.com/community and/or the man pages?  I'm happy to file\nan issue or to write a patch that adds a link, but I don't see myself\nspending more time on it than that.\n\nMatt\n"},{"id":"277829","messageId":"xmqqoabp38do.fsf@gitster.mtv.corp.google.com","threadId":"41363","inReplyTo":"1455048354.2511.199.camel@mattmccutchen.net","subject":"Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-09T21:02:11Z","receivedAt":"2016-02-09T21:02:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt McCutchen writes:\n\n> See my revised proposed text here:\n>\n> https://github.com/git/git-scm.com/pull/676/files\n\nIf somebody says \"The ancient version I use has this bug, it does\nnot reproduce with 'next'\", the first thing we would ask would be\n\"Does it still happen on 'master'?\" Even though it is often clear\nfrom the context and the nature of the bug which topic in 'next' is\nlikely to have fixed it, if the reporter skipped 'master', we would\nend up scratching our head which topic in 'next' that is not\n'master' fixed it as a side effect. And because not everything on\n'next' is ready for 'master', we cannot just merge everything ;-)\n\nOn the other hand, if somebody says \"The ancient version I use has\nthis bug, it does not reproduce with 'master'\", we would likely not\nto say anything other than \"Oh, that's good for you.\".\n\nIf somebody says \"The ancient version I use has this bug, it still\nreproduces with 'master'\", then we would ask 'next' to be tried.\n\nFor these reasons, I'd say \"try the 'master' branch\". Trying 'next'\nis highly appreciated, but not without trying 'master'.\n\n> I left a mention of providing feedback on pending fixes but thought it\n> would be too much to go into the details of how to identify whether\n> there is a pending fix.\n\nWhat is in 'master' relative to the version of Git the bug reporter\nhas can be seen by reading through RelNotes of the released versions\nsince the version reporter used, and RelNotes in the 'master'.\nEvery time an updated 'master' is pushed out, the changes made by\nthe topics merged to it are added to update RelNotes.\n\n\"What's cooking\" report, issued once or twice a week, summarizes the\ntopics that are still not in 'master' (the description in there are\nused to update RelNotes when topics graduate to 'master').\n\nAlso \"Git Rev News\" may cover recent efforts on tackling interesting\nbugs.\n\nThanks.\n"}]}