Re: [PATCH] worktree: stop supporting moving worktrees manually

[Eric Sunshine]

On Tue, Dec 29, 2015 at 8:55 AM, Duy Nguyen  wrote:
> On Mon, Dec 28, 2015 at 1:22 PM, Eric Sunshine  
> wrote:
>> On Sun, Dec 27, 2015 at 10:43:16AM +0700, Nguyễn Thái Ngọc Duy wrote:
>>>  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.
>
> The prune logic is there. But this hard link is not created by
> 'worktree add'. I think calling link() was done at some point but then
> it got dropped. Ah found it, it wasn't a big "no" so maybe we can
> revive it at some point.
>
> http://article.gmane.org/gmane.comp.version-control.git/243475

Hmm, yes...

>>> +$GIT_DIR/worktrees//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//gitdir in the
>> "DETAILS" section.
>>
>> Perhaps something like this, on top of your patch (assuming that the
>> "hard links" feature is not implemented):
>
> Looks good.
>
> How about something like this at the end of the last new paragraph?
> "alternatively if your file system supports hard link and the worktree
> and $GIT_DIR are on the same file system, you can create a hard link
> named "link" back to the .git file. See gitrepository-layout.txt for
> more information".

That makes sense, however...

If I understand correctly, while it's true that the 'link' file will
inhibit pruning, don't we still have the problem that "git worktree
list" will show an outdated path if the user fails to update 'gitdir'?
And doesn't the "branch already checked out in some other worktree"
interrogation also depend upon 'gitdir' being up-to-date?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] worktree: stop supporting moving worktrees manually

[Duy Nguyen]

On Mon, Dec 28, 2015 at 1:22 PM, Eric Sunshine  wrote:
> 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 
>> ---
>> 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.

The prune logic is there. But this hard link is not created by
'worktree add'. I think calling link() was done at some point but then
it got dropped. Ah found it, it wasn't a big "no" so maybe we can
revive it at some point.

http://article.gmane.org/gmane.comp.version-control.git/243475

>> +$GIT_DIR/worktrees//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//gitdir in the
> "DETAILS" section.
>
> Perhaps something like this, on top of your patch (assuming that the
> "hard links" feature is not implemented):

Looks good.

How about something like this at the end of the last new paragraph?
"alternatively if your file system supports hard link and the worktree
and $GIT_DIR are on the same file system, you can create a hard link
named "link" back to the .git file. See gitrepository-layout.txt for
more information".

>
> --- 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//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< ---



-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] worktree: stop supporting moving worktrees manually

[Eric Sunshine]

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 
> ---
> 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//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//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//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< ---
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html