{"thread":{"id":"49180","subject":"[PATCH] SubmittingPatches: mention doc-diff","startedAt":"2018-08-21T19:23:25Z","lastAt":"2018-08-27T19:40:06Z","messageCount":11,"participants":["Jeff King","Derrick Stolee","Eric Sunshine","Duy Nguyen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"356194","messageId":"20180821192321.GA720@sigill.intra.peff.net","threadId":"49180","inReplyTo":null,"subject":"[PATCH] SubmittingPatches: mention doc-diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-21T19:23:22Z","receivedAt":"2018-08-21T19:23:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We already advise people to make sure their documentation\nformats correctly. Let's point them at the doc-diff script,\nwhich can help with that.\n\nLet's also put a brief note in the script about its purpose,\nsince that otherwise can only be found in the original\ncommit message. Along with the existing -h/usage text,\nthat's hopefully enough for developers to make use of it.\n\nSigned-off-by: Jeff King \n---\nJust a finishing touch on the jk/diff-rendered-docs topic.\n\n Documentation/SubmittingPatches | 4 +++-\n Documentation/doc-diff | 8 ++++++++\n 2 files changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex b44fd51f27..ec8b205145 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -80,7 +80,9 @@ GitHub-Travis CI hints section for details.\n \n Do not forget to update the documentation to describe the updated\n behavior and make sure that the resulting documentation set formats\n-well. It is currently a liberal mixture of US and UK English norms for\n+well (try the Documentation/doc-diff script).\n+\n+We currently have a liberal mixture of US and UK English norms for\n spelling and grammar, which is somewhat unfortunate. A huge patch that\n touches the files all over the place only to correct the inconsistency\n is not welcome, though. Potential clashes with other changes that can\ndiff --git a/Documentation/doc-diff b/Documentation/doc-diff\nindex f483fe427c..6e285e648c 100755\n--- a/Documentation/doc-diff\n+++ b/Documentation/doc-diff\n@@ -1,4 +1,12 @@\n #!/bin/sh\n+#\n+# Build two documentation trees and diff the resulting formatted output.\n+# Compared to a source diff, this can reveal mistakes in the formatting.\n+# For example:\n+#\n+# ./doc-diff origin/master HEAD\n+#\n+# would show the differences introduced by a branch based on master.\n \n OPTIONS_SPEC=\"\\\n doc-diff [options] [-- ]\n-- \n2.19.0.rc0.398.g138a08f6f6\n"},{"id":"356201","messageId":"20180821193556.GA859@sigill.intra.peff.net","threadId":"49180","inReplyTo":"20180821192321.GA720@sigill.intra.peff.net","subject":"worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-21T19:35:56Z","receivedAt":"2018-08-21T19:35:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 21, 2018 at 03:23:21PM -0400, Jeff King wrote:\n\n> We already advise people to make sure their documentation\n> formats correctly. Let's point them at the doc-diff script,\n> which can help with that.\n> \n> Let's also put a brief note in the script about its purpose,\n> since that otherwise can only be found in the original\n> commit message. Along with the existing -h/usage text,\n> that's hopefully enough for developers to make use of it.\n> \n> Signed-off-by: Jeff King \n> ---\n> Just a finishing touch on the jk/diff-rendered-docs topic.\n\nI noticed one other oddity with this script, but I actually think the\nfix lies elsewhere.\n\nThe script does basically this to set up the temporary tree:\n\n test -d $tmp || git worktree add $tmp ...\n\nThe script never cleans up the worktree (since its results can often be\nreused between runs), but you may do so with \"rm\" or \"git clean\". That\ncreates an interesting situation if the script is run again before\n\"worktree prune\" runs. We identify the directory as a \"new\" worktree,\nand add it to the list. So you may end up with several copies:\n\n $ git worktree list\n /home/peff/compile/git eee785d2e0 [jk/doc-diff]\n /home/peff/compile/git/.git/tmp-ci 290f16acda (detached HEAD)\n /home/peff/compile/git/Documentation/tmp-doc-diff/worktree cc6237c051 (detached HEAD)\n /home/peff/compile/git/Documentation/tmp-doc-diff/worktree e55de40950 (detached HEAD)\n /home/peff/compile/git/Documentation/tmp-doc-diff/worktree e55de40950 (detached HEAD)\n\nIf I then run \"git worktree prune\", those duplicates don't go away\n(because the directory is still there; it just corresponds to only the\nfinal entry). If I delete the tmp-doc-diff directory and then run \"git\nworktree prune\", they do all go away.\n\nSo I'm not sure:\n\n 1. Should the script be doing something else to indicate that the\n worktree may be reused? I tried \"git worktree remove\", but it's\n unhappy that the directory doesn't exist. Should it quietly handle\n ignore that and remove any leftover cruft in $GIT_DIR/worktrees?\n\n 2. Should \"git worktree add\" be more clever about realizing that an\n existing entry in $GIT_DIR/worktrees points to this directory? That\n would be fine for my use, but I wonder if there's some potential\n for loss (e.g., you blew away the work tree but until you do a\n \"worktree prune\", the refs are still there, objects reachable,\n etc).\n\n 3. Should \"git worktree prune\" be more clever about dropping\n duplicates? I think it should be easy to identify them: they are\n entries in $GIT_DIR/worktrees for which:\n\n - the directory in $entry/gitdir does exist, but\n\n - $(cat $entry/gitdir)/.git does not point back to $entry\n\nI could see any of them being plausible fixes, but people who have given\nworktrees a lot of thought may have stronger opinions.\n\n-Peff\n"},{"id":"356202","messageId":"2d03be9e-fa89-f740-0c50-3c2d93a29b09@gmail.com","threadId":"49180","inReplyTo":"20180821192321.GA720@sigill.intra.peff.net","subject":"Re: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2018-08-21T19:38:32Z","receivedAt":"2018-08-21T19:38:43Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/21/2018 3:23 PM, Jeff King wrote:\n> We already advise people to make sure their documentation\n> formats correctly. Let's point them at the doc-diff script,\n> which can help with that.\n>\n> Let's also put a brief note in the script about its purpose,\n> since that otherwise can only be found in the original\n> commit message. Along with the existing -h/usage text,\n> that's hopefully enough for developers to make use of it.\n\nThis is helpful, thanks!\n\n> Signed-off-by: Jeff King \n> ---\n> Just a finishing touch on the jk/diff-rendered-docs topic.\n>\n> Documentation/SubmittingPatches | 4 +++-\n> Documentation/doc-diff | 8 ++++++++\n> 2 files changed, 11 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index b44fd51f27..ec8b205145 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -80,7 +80,9 @@ GitHub-Travis CI hints section for details.\n> \n> Do not forget to update the documentation to describe the updated\n> behavior and make sure that the resulting documentation set formats\n> -well. It is currently a liberal mixture of US and UK English norms for\n> +well (try the Documentation/doc-diff script).\n> +\n> +We currently have a liberal mixture of US and UK English norms for\n> spelling and grammar, which is somewhat unfortunate. A huge patch that\n> touches the files all over the place only to correct the inconsistency\n> is not welcome, though. Potential clashes with other changes that can\n> diff --git a/Documentation/doc-diff b/Documentation/doc-diff\n> index f483fe427c..6e285e648c 100755\n> --- a/Documentation/doc-diff\n> +++ b/Documentation/doc-diff\n> @@ -1,4 +1,12 @@\n> #!/bin/sh\n> +#\n> +# Build two documentation trees and diff the resulting formatted output.\n> +# Compared to a source diff, this can reveal mistakes in the formatting.\n> +# For example:\n> +#\n> +# ./doc-diff origin/master HEAD\n> +#\n> +# would show the differences introduced by a branch based on master.\n> \n> OPTIONS_SPEC=\"\\\n> doc-diff [options] [-- ]\n"},{"id":"356211","messageId":"CAPig+cT+LBSJHoR1kUi+S2h96y_qmVEpK0xAy6sRUGQj6GQEyg@mail.gmail.com","threadId":"49180","inReplyTo":"20180821193556.GA859@sigill.intra.peff.net","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-08-21T20:22:08Z","receivedAt":"2018-08-21T20:22:22Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:\n> The script does basically this to set up the temporary tree:\n>\n> test -d $tmp || git worktree add $tmp ...\n>\n> The script never cleans up the worktree (since its results can often be\n> reused between runs), but you may do so with \"rm\" or \"git clean\". That\n> creates an interesting situation if the script is run again before\n> \"worktree prune\" runs.\n\nAside from the problems you enumerate below, leaving worktrees sitting\naround which the user did not create explicitly does seem a bit\nunfriendly, which leads me to think that worktrees may not be the best\ntool for this task. How about using \"git clone --shared\" instead?\n\nMore below...\n\n> We identify the directory as a \"new\" worktree,\n> and add it to the list. So you may end up with several copies:\n>\n> $ git worktree list\n> [...]\n> /home/peff/compile/git/Documentation/tmp-doc-diff/worktree cc6237c051 (detached HEAD)\n> /home/peff/compile/git/Documentation/tmp-doc-diff/worktree e55de40950 (detached HEAD)\n> /home/peff/compile/git/Documentation/tmp-doc-diff/worktree e55de40950 (detached HEAD)\n>\n> If I then run \"git worktree prune\", those duplicates don't go away\n> (because the directory is still there; it just corresponds to only the\n> final entry). If I delete the tmp-doc-diff directory and then run \"git\n> worktree prune\", they do all go away.\n>\n> 1. Should the script be doing something else to indicate that the\n> worktree may be reused? I tried \"git worktree remove\", but it's\n> unhappy that the directory doesn't exist. Should it quietly handle\n> ignore that and remove any leftover cruft in $GIT_DIR/worktrees?\n\nThat's a weird case. There are multiple entries in\n.git/worktrees/*/gitdir pointing at the same worktree directory, which\nI don't think was considered when the machinery was being designed.\n\"git worktree remove\" refusing to delete the worktree in this case\nseems a good safety measure since something is obviously askew in the\nbookkeeping and it doesn't want to lose potential work.\n\nThe solution to this problem might be to upgrade \"prune\" as you\ndescribe in #3 and then ensure that that sort of aggressive pruning\nhappens automatically at \"git worktree add\" time.\n\n> 2. Should \"git worktree add\" be more clever about realizing that an\n> existing entry in $GIT_DIR/worktrees points to this directory? That\n> would be fine for my use, but I wonder if there's some potential\n> for loss (e.g., you blew away the work tree but until you do a\n> \"worktree prune\", the refs are still there, objects reachable,\n> etc).\n\nIn the case that you've already blown away the directory, then having\n\"git worktree add\" prune away the old worktree bookkeeping would make\nsense and wouldn't lose anything (you've already thrown it away\nmanually). However, it could be lossy for the case when the directory\nis only temporarily missing (because it's on removable media or a\nnetwork share).\n\nIn this case, it might make sense for \"git worktree add\" to refuse to\noperate if an existing worktree entry still points at the directory\nthat you're trying to add. That should prevent those duplicate\nworktree entries you saw.\n\n> 3. Should \"git worktree prune\" be more clever about dropping\n> duplicates? I think it should be easy to identify them: they are\n> entries in $GIT_DIR/worktrees for which:\n>\n> - the directory in $entry/gitdir does exist, but\n> - $(cat $entry/gitdir)/.git does not point back to $entry\n\nSeems a sensible improvement to the pruning logic.\n\nHowever, upon further consideration, any of the proposed \"fixes\" could\npotentially be lossy. Consider a case like this:\n\n% git worktree add foo\n... make some changes in 'foo' ...\n% mv foo bar # (fogetting to do \"git worktree move foo bar\")\n% git worktree add foo\n\nAs currently implemented, one can \"correct\" the situation by manually\nfixing the bookkeeping file in .git/worktrees for the worktree created\nfirst. If it gets pruned automatically, then the state of those\nchanges in \"bar\" (nee \"foo\") could be lost.\n\nSo, I'm not sure what, if any, fix is appropriate.\n\nSuch uncertainty also further argues in favor of \"git clone --shared\"\nfor your particular use-case, I think.\n"},{"id":"356213","messageId":"20180821204341.GA24431@sigill.intra.peff.net","threadId":"49180","inReplyTo":"CAPig+cT+LBSJHoR1kUi+S2h96y_qmVEpK0xAy6sRUGQj6GQEyg@mail.gmail.com","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-21T20:43:41Z","receivedAt":"2018-08-21T20:43:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 21, 2018 at 04:22:08PM -0400, Eric Sunshine wrote:\n\n> On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:\n> > The script does basically this to set up the temporary tree:\n> >\n> > test -d $tmp || git worktree add $tmp ...\n> >\n> > The script never cleans up the worktree (since its results can often be\n> > reused between runs), but you may do so with \"rm\" or \"git clean\". That\n> > creates an interesting situation if the script is run again before\n> > \"worktree prune\" runs.\n> \n> Aside from the problems you enumerate below, leaving worktrees sitting\n> around which the user did not create explicitly does seem a bit\n> unfriendly, which leads me to think that worktrees may not be the best\n> tool for this task. How about using \"git clone --shared\" instead?\n\nThat seems even more dangerous to me, since the created clone can become\ncorrupt when the parent prunes. Probably not huge for a single\noperation, but you may be surprised when you run the script a few days\nlater and it barfs horribly due to a missing object.\n\nWe could do a local filesystem clone which would make a hardlink. But\neventually those hardlinks would be broken, and we'd be wasting a lot of\nextra space (and there's no provision for repacking or maintenance of\nthe temp repo; again, OK for a day or two, but if maybe not if you leave\nthis thing lying around for months).\n\nI also considered just using \"git archive | tar xf -\" to create the\ncheckouts. But we really would like to move between trees without\nupdating files unnecessarily (to avoid triggering rebuilds via make).\n\nWe could do that without a full-on worktree by just keeping our own\ntemporary index. But I think that potentially ends up with similar\nproblems to the \"clone --shared\" one: at some point objects in the\nparent go away, and it has no idea about our custom index.\n\nI think a worktree with a detached HEAD is roughly the same concept, but\nwith an officially-approved mechanism by which the parent knows about\nour worktree.\n\n> > 1. Should the script be doing something else to indicate that the\n> > worktree may be reused? I tried \"git worktree remove\", but it's\n> > unhappy that the directory doesn't exist. Should it quietly handle\n> > ignore that and remove any leftover cruft in $GIT_DIR/worktrees?\n> \n> That's a weird case. There are multiple entries in\n> .git/worktrees/*/gitdir pointing at the same worktree directory, which\n> I don't think was considered when the machinery was being designed.\n> \"git worktree remove\" refusing to delete the worktree in this case\n> seems a good safety measure since something is obviously askew in the\n> bookkeeping and it doesn't want to lose potential work.\n> \n> The solution to this problem might be to upgrade \"prune\" as you\n> describe in #3 and then ensure that that sort of aggressive pruning\n> happens automatically at \"git worktree add\" time.\n\nI would feel funny about running \"git worktree prune\" in my script,\nsince it may also delete _other_ worktrees. But if \"worktree prune\"\nhandled this case, I'd be OK just ignoring occasional duplicates, and\nperiodic \"git gc\" would clean up the cruft.\n\n> > 2. Should \"git worktree add\" be more clever about realizing that an\n> > existing entry in $GIT_DIR/worktrees points to this directory? That\n> > would be fine for my use, but I wonder if there's some potential\n> > for loss (e.g., you blew away the work tree but until you do a\n> > \"worktree prune\", the refs are still there, objects reachable,\n> > etc).\n> \n> In the case that you've already blown away the directory, then having\n> \"git worktree add\" prune away the old worktree bookkeeping would make\n> sense and wouldn't lose anything (you've already thrown it away\n> manually). However, it could be lossy for the case when the directory\n> is only temporarily missing (because it's on removable media or a\n> network share).\n\nI think the removable ones already suffer from that problem (an auto-gc\ncan prune them). And they should already be marked with \"git worktree\nlock\". That said, people don't always do what they should, and I'd\nrather not make the problem worse. :)\n\n> In this case, it might make sense for \"git worktree add\" to refuse to\n> operate if an existing worktree entry still points at the directory\n> that you're trying to add. That should prevent those duplicate\n> worktree entries you saw.\n\nYes, but then what's the next step for my script? I can't \"remove\" since\nthe worktree isn't there. I can't blow away any directory that I know\nabout, since there isn't one. I need to somehow know that an existing\n\"$GIT_DIR/worktrees/foo\" is the problem. But \"foo\" is not even\ndeterministic. Looking at the duplicates, it seems to be the basename of\nthe working tree, but then mutated to avoid collisions with other\nworktrees.\n\nWhat about refusing by default, but forcing an overwrite with \"-f\"?\n\nThat should keep the existing case as safe as now, but give an outlet\nfor this kind of case where the caller is in charge of the worktree and\nknows that any prior contents are trashable.\n\n> However, upon further consideration, any of the proposed \"fixes\" could\n> potentially be lossy. Consider a case like this:\n> \n> % git worktree add foo\n> ... make some changes in 'foo' ...\n> % mv foo bar # (fogetting to do \"git worktree move foo bar\")\n> % git worktree add foo\n> \n> As currently implemented, one can \"correct\" the situation by manually\n> fixing the bookkeeping file in .git/worktrees for the worktree created\n> first. If it gets pruned automatically, then the state of those\n> changes in \"bar\" (nee \"foo\") could be lost.\n\nTrue, though again, you're already in danger with:\n\n $ git worktree add foo\n $ mv foo bar ;# forget to \"git worktree move\"\n $ git fetch ;# oops, we ran auto-gc!\n\n-Peff\n"},{"id":"356390","messageId":"CAPig+cTghgbBo5VfZN+VP2VM00nPkhUqm0dOUqO37arxraxBKw@mail.gmail.com","threadId":"49180","inReplyTo":"20180821204341.GA24431@sigill.intra.peff.net","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-08-23T18:19:08Z","receivedAt":"2018-08-23T18:19:22Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Aug 21, 2018 at 4:43 PM Jeff King wrote:\n> On Tue, Aug 21, 2018 at 04:22:08PM -0400, Eric Sunshine wrote:\n> > On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:\n> > How about using \"git clone --shared\" instead?\n>\n> That seems even more dangerous to me, since the created clone can become\n> corrupt when the parent prunes. Probably not huge for a single\n> operation, but you may be surprised when you run the script a few days\n> later and it barfs horribly due to a missing object.\n\nOkay. I had thought that doc-diff was never doing anything other than\nread-only operations on the checked-out worktree after the initial\ncreation, but, looking more closely at the script, I now see that it\ncan perform other Git-based operations, so what you say makes sense.\n\n> > In the case that you've already blown away the directory, then having\n> > \"git worktree add\" prune away the old worktree bookkeeping would make\n> > sense and wouldn't lose anything (you've already thrown it away\n> > manually). However, it could be lossy for the case when the directory\n> > is only temporarily missing (because it's on removable media or a\n> > network share).\n>\n> I think the removable ones already suffer from that problem (an auto-gc\n> can prune them). And they should already be marked with \"git worktree\n> lock\". That said, people don't always do what they should, and I'd\n> rather not make the problem worse. :)\n\nHmph. I thought that \"git worktree prune\" had a sensible \"expire\"\ndefault to protect against such cases of removable media for which\n\"git worktree lock\" wasn't invoked, but, looking at the code, I see\nthat the default is TIME_MAX.\n\n> > In this case, it might make sense for \"git worktree add\" to refuse to\n> > operate if an existing worktree entry still points at the directory\n> > that you're trying to add. That should prevent those duplicate\n> > worktree entries you saw.\n>\n> Yes, but then what's the next step for my script? I can't \"remove\" since\n> the worktree isn't there. I can't blow away any directory that I know\n> about, since there isn't one.\n\nI was thinking that \"worktree add\" could start respecting the --force\noption as an escape hatch.\n\n> I need to somehow know that an existing\n> \"$GIT_DIR/worktrees/foo\" is the problem. But \"foo\" is not even\n> deterministic. Looking at the duplicates, it seems to be the basename of\n> the working tree, but then mutated to avoid collisions with other\n> worktrees.\n\nIf the worktree directory still existed, \"git -C rev-parse --git-dir\"\ninside the worktree would give you the proper path of\n$GIT_DIR/worktrees/foo, but the directory doesn't exist, so...\nnothing.\n\n> What about refusing by default, but forcing an overwrite with \"-f\"?\n\nMy thought, also.\n"},{"id":"356460","messageId":"CACsJy8BxxyRxqCj5ZoOmPaiwmFRKHU72yTxyC_eHXS+cEa94zw@mail.gmail.com","threadId":"49180","inReplyTo":"CAPig+cTghgbBo5VfZN+VP2VM00nPkhUqm0dOUqO37arxraxBKw@mail.gmail.com","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-08-24T14:46:58Z","receivedAt":"2018-08-24T14:47:28Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Jeff, you're doing crazy things beyond my (admittedly very limited)\nimagination :P I did not see this at all when I implemented the\nworktree stuff.\n\nOn Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine wrote:\n> > > In this case, it might make sense for \"git worktree add\" to refuse to\n> > > operate if an existing worktree entry still points at the directory\n> > > that you're trying to add. That should prevent those duplicate\n> > > worktree entries you saw.\n> >\n> > Yes, but then what's the next step for my script? I can't \"remove\" since\n> > the worktree isn't there. I can't blow away any directory that I know\n> > about, since there isn't one.\n>\n> I was thinking that \"worktree add\" could start respecting the --force\n> option as an escape hatch.\n>\n> > I need to somehow know that an existing\n> > \"$GIT_DIR/worktrees/foo\" is the problem. But \"foo\" is not even\n> > deterministic. Looking at the duplicates, it seems to be the basename of\n> > the working tree, but then mutated to avoid collisions with other\n> > worktrees.\n>\n> If the worktree directory still existed, \"git -C rev-parse --git-dir\"\n> inside the worktree would give you the proper path of\n> $GIT_DIR/worktrees/foo, but the directory doesn't exist, so...\n> nothing.\n>\n> > What about refusing by default, but forcing an overwrite with \"-f\"?\n>\n> My thought, also.\n\nSounds good. Eric are you going to implement this? Just checking so\nthat I can (hopefully) cross this off my backlog ;-)\n-- \nDuy\n"},{"id":"356497","messageId":"CAPig+cQNkMEUj=6e=6czbkWeozJQ-Go09C6bZwVJUTpM3JJiiw@mail.gmail.com","threadId":"49180","inReplyTo":"CACsJy8BxxyRxqCj5ZoOmPaiwmFRKHU72yTxyC_eHXS+cEa94zw@mail.gmail.com","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-08-24T22:55:24Z","receivedAt":"2018-08-24T22:55:37Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen wrote:\n> On Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine wrote:\n> > Peff wrote:\n> > > Yes, but then what's the next step for my script? I can't \"remove\" since\n> > > the worktree isn't there. I can't blow away any directory that I know\n> > > about, since there isn't one.\n> >\n> > I was thinking that \"worktree add\" could start respecting the --force\n> > option as an escape hatch.\n> >\n> > > What about refusing by default, but forcing an overwrite with \"-f\"?\n> >\n> > My thought, also.\n>\n> Sounds good. Eric are you going to implement this? Just checking so\n> that I can (hopefully) cross this off my backlog ;-)\n\nIt wasn't something I was planning on working on (at least not\nimmediately) since it's still a bit fuzzy for me whether this is\nenough to help Peff's use-case (and because I have several other\nthings in my queue, already).\n\nHowever, before even considering implementing it, there's at least one\nquestion (and possibly others) needing answering. For instance, how\nshould \"add --force\" interact with a locked (not-present) worktree?\nShould it blast it despite the lock? Or would that need --force\nspecified twice (\"git worktree add -f -f foo\")?\n\nAs for the actual implementation, I haven't yet looked at how much\nsurgery will be needed to make 'add' respect --force.\n"},{"id":"356499","messageId":"20180824232502.GA21265@sigill.intra.peff.net","threadId":"49180","inReplyTo":"CAPig+cQNkMEUj=6e=6czbkWeozJQ-Go09C6bZwVJUTpM3JJiiw@mail.gmail.com","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-24T23:25:02Z","receivedAt":"2018-08-24T23:25:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 24, 2018 at 06:55:24PM -0400, Eric Sunshine wrote:\n\n> On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen wrote:\n> > On Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine wrote:\n> > > Peff wrote:\n> > > > Yes, but then what's the next step for my script? I can't \"remove\" since\n> > > > the worktree isn't there. I can't blow away any directory that I know\n> > > > about, since there isn't one.\n> > >\n> > > I was thinking that \"worktree add\" could start respecting the --force\n> > > option as an escape hatch.\n> > >\n> > > > What about refusing by default, but forcing an overwrite with \"-f\"?\n> > >\n> > > My thought, also.\n> >\n> > Sounds good. Eric are you going to implement this? Just checking so\n> > that I can (hopefully) cross this off my backlog ;-)\n> \n> It wasn't something I was planning on working on (at least not\n> immediately) since it's still a bit fuzzy for me whether this is\n> enough to help Peff's use-case (and because I have several other\n> things in my queue, already).\n\nI'm pretty sure it would just be a one-liner to \"worktree add -f\" in the\ndoc-diff script. So I think it does solve the problem.\n\n> However, before even considering implementing it, there's at least one\n> question (and possibly others) needing answering. For instance, how\n> should \"add --force\" interact with a locked (not-present) worktree?\n> Should it blast it despite the lock? Or would that need --force\n> specified twice (\"git worktree add -f -f foo\")?\n\nYes, I think that should probably be two forces.\n\n> As for the actual implementation, I haven't yet looked at how much\n> surgery will be needed to make 'add' respect --force.\n\nMe either. I may take a look this weekend. I got sucked into an asm and\ncoccinelle rabbit hole the last few days.\n\n-Peff\n"},{"id":"356570","messageId":"CAPig+cQMv=ByvmH=+V3hZ1NC-=eT+CShuM7g+Y4evD1nVFr4XQ@mail.gmail.com","threadId":"49180","inReplyTo":"20180824232502.GA21265@sigill.intra.peff.net","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-08-27T09:55:43Z","receivedAt":"2018-08-27T09:55:57Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Aug 24, 2018 at 7:25 PM Jeff King wrote:\n> On Fri, Aug 24, 2018 at 06:55:24PM -0400, Eric Sunshine wrote:\n> > On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen wrote:\n> > > > I was thinking that \"worktree add\" could start respecting the --force\n> > > > option as an escape hatch.\n> > >\n> > > Sounds good. Eric are you going to implement this? Just checking so\n> > > that I can (hopefully) cross this off my backlog ;-)\n> >\n> > It wasn't something I was planning on working on (at least not\n> > immediately) [...]\n> > As for the actual implementation, I haven't yet looked at how much\n> > surgery will be needed to make 'add' respect --force.\n>\n> Me either. I may take a look this weekend. [...]\n\nOkay, I got an implementation up and running. It didn't require too\nmuch code, but neither was it a simple 1- or 2-liner.\n\nI still need to update documentation, write tests, and compose the\nactual patch series (which will probably run to about 5 patches), so\nit's not quite ready to send out, but hopefully soon.\n"},{"id":"356607","messageId":"20180827194002.GA27158@sigill.intra.peff.net","threadId":"49180","inReplyTo":"CAPig+cQMv=ByvmH=+V3hZ1NC-=eT+CShuM7g+Y4evD1nVFr4XQ@mail.gmail.com","subject":"Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-27T19:40:02Z","receivedAt":"2018-08-27T19:40:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 27, 2018 at 05:55:43AM -0400, Eric Sunshine wrote:\n\n> On Fri, Aug 24, 2018 at 7:25 PM Jeff King wrote:\n> > On Fri, Aug 24, 2018 at 06:55:24PM -0400, Eric Sunshine wrote:\n> > > On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen wrote:\n> > > > > I was thinking that \"worktree add\" could start respecting the --force\n> > > > > option as an escape hatch.\n> > > >\n> > > > Sounds good. Eric are you going to implement this? Just checking so\n> > > > that I can (hopefully) cross this off my backlog ;-)\n> > >\n> > > It wasn't something I was planning on working on (at least not\n> > > immediately) [...]\n> > > As for the actual implementation, I haven't yet looked at how much\n> > > surgery will be needed to make 'add' respect --force.\n> >\n> > Me either. I may take a look this weekend. [...]\n> \n> Okay, I got an implementation up and running. It didn't require too\n> much code, but neither was it a simple 1- or 2-liner.\n> \n> I still need to update documentation, write tests, and compose the\n> actual patch series (which will probably run to about 5 patches), so\n> it's not quite ready to send out, but hopefully soon.\n\nGreat, and thanks for letting me know before we duplicated effort.\n\n-Peff\n"}]}