From: Eric Sunshine <sunshine@sunshineco.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
peff@peff.net, rappazzo@gmail.com, kyle@kyleam.com
Subject: Re: [PATCH] worktree: stop supporting moving worktrees manually
Date: Mon, 28 Dec 2015 01:22:06 -0500 [thread overview]
Message-ID: <20151228062206.GA4621@flurp.local> (raw)
In-Reply-To: <1451187796-31138-1-git-send-email-pclouds@gmail.com>
On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:
> The current update_linked_gitdir() has a bug that can create "gitdir"
> file in non-multi-worktree setup. Instead of fixing this, we step back a
> bit. The original design was probably not well thought out. For now, if
> the user manually moves a worktree, they have to fix up "gitdir" file
> manually or the worktree will get pruned. In future, we probably will
> add "git worktree mv" to support this use case.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -33,10 +33,8 @@ The working tree's administrative files in the repository (see
> If you move a linked working tree to another file system, or
> -within a file system that does not support hard links, you need to run
> -at least one git command inside the linked working tree
> -(e.g. `git status`) in order to update its administrative files in the
> -repository so that they do not get automatically pruned.
> +within a file system that does not support hard links, you need to update
Hmm, is this "hard links" feature implemented? If not, then this
documentation is a bit outdated.
> +$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.
Following the example of af189b4 (Documentation/git-worktree: split
technical info from general description, 2015-07-06), it might be a
good idea to keep this high-level overview free of such low-level
details and instead mention $GIT_DIR/worktrees/<id>/gitdir in the
"DETAILS" section.
Perhaps something like this, on top of your patch (assuming that the
"hard links" feature is not implemented):
--- 8< ---
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 4814f48..62c76c1 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -32,9 +32,9 @@ The working tree's administrative files in the repository (see
`git worktree prune` in the main or any linked working tree to
clean up any stale administrative files.
-If you move a linked working tree to another file system, or
-within a file system that does not support hard links, you need to update
-$GIT_DIR/worktrees/<id>/gitdir so that they do not get automatically pruned.
+If you move a linked working tree, you need to manually update the
+administrative files so that they do not get pruned automatically. See
+section "DETAILS" for more information.
If a linked working tree is stored on a portable device or network share
which is not always mounted, you can prevent its administrative files from
@@ -135,6 +135,13 @@ thumb is do not make any assumption about whether a path belongs to
$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
+If you move a linked working tree, you need to update the 'gitdir' file
+in the entry's directory. For example, if a linked working tree is moved
+to `/newpath/test-next` and its `.git` file points to
+`/path/main/.git/worktrees/test-next`, then update
+`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next`
+instead.
+
To prevent a $GIT_DIR/worktrees entry from being pruned (which
can be useful in some situations, such as when the
entry's working tree is stored on a portable device), add a file named
--- 8< ---
next prev parent reply other threads:[~2015-12-28 6:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-27 22:04 What's the ".git/gitdir" file? Kyle Meyer
2015-10-27 22:22 ` Stefan Beller
2015-10-27 22:42 ` Randall S. Becker
2015-10-27 22:54 ` Stefan Beller
2015-10-27 22:54 ` Junio C Hamano
2015-10-27 23:26 ` Mike Rappazzo
2015-10-28 16:23 ` Junio C Hamano
2015-11-02 19:08 ` [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X Nguyễn Thái Ngọc Duy
2015-11-02 20:01 ` Eric Sunshine
2015-11-02 20:35 ` Jeff King
2015-11-02 20:51 ` Junio C Hamano
2015-11-02 20:52 ` Jeff King
2015-11-03 5:48 ` Duy Nguyen
2015-11-03 19:54 ` Junio C Hamano
2015-12-27 3:43 ` [PATCH] worktree: stop supporting moving worktrees manually Nguyễn Thái Ngọc Duy
2015-12-28 6:22 ` Eric Sunshine [this message]
2015-12-29 13:55 ` Duy Nguyen
2015-12-31 5:59 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151228062206.GA4621@flurp.local \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kyle@kyleam.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=rappazzo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.