[PATCH 0/3] git worktree prune improvements

[PATCH 0/3] git worktree prune improvements

[Nguyễn Thái Ngọc Duy]

This is something we could do to improve the situation when a user
manually moves a worktree and not follow the update process (we have
had the first reported case [1]). Plus a bit cleanup in gc.

I think this is something we should do until we somehow make the user
aware that the worktree is broken as soon as they move a worktree
manually. But there's some more work to get there.

[1] http://public-inbox.org/git/%3Caa98f187-4b1a-176d-2a1b-826c995776cd@aegee.org%3E

Nguyễn Thái Ngọc Duy (3):
  gc.txt: more details about what gc does
  worktree: delete dead code
  worktree prune: improve prune logic when worktree is moved

 Documentation/git-gc.txt               | 12 ++++++++++--
 Documentation/gitrepository-layout.txt |  5 -----
 builtin/worktree.c                     | 11 +++--------
 3 files changed, 13 insertions(+), 15 deletions(-)

-- 
2.16.1.435.g8f24da2e1a

[PATCH 1/3] gc.txt: more details about what gc does

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-gc.txt | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 571b5a7e3c..862c931104 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -15,8 +15,9 @@ DESCRIPTION
 -----------
 Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
-performance) and removing unreachable objects which may have been
-created from prior invocations of 'git add'.
+performance), removing unreachable objects which may have been
+created from prior invocations of 'git add', packing refs, pruning
+reflog, rerere or stale working trees.
 
 Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
@@ -59,6 +60,10 @@ then existing packs (except those marked with a `.keep` file)
 are consolidated into a single pack by using the `-A` option of
 'git repack'. Setting `gc.autoPackLimit` to 0 disables
 automatic consolidation of packs.
++
+If `git gc --auto` goes ahead because of either too loose objects or
+packs, all other housekeeping tasks (e.g. rerere, working trees,
+reflog...) will also be be performed.
 
 --prune=<date>::
 	Prune loose objects older than date (default is 2 weeks ago,
@@ -133,6 +138,9 @@ The optional configuration variable `gc.pruneExpire` controls how old
 the unreferenced loose objects have to be before they are pruned.  The
 default is "2 weeks ago".
 
+The optional gc.worktreePruneExpire controls how old a stale working
+tree before `git worktree prune` deletes it. The default is "3 months
+ago".
 
 Notes
 -----
-- 
2.16.1.435.g8f24da2e1a

Re: [PATCH 1/3] gc.txt: more details about what gc does

[Eric Sunshine]

On Fri, Mar 2, 2018 at 10:39 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
> @@ -15,8 +15,9 @@ DESCRIPTION
>  -----------
>  Runs a number of housekeeping tasks within the current repository,
>  such as compressing file revisions (to reduce disk space and increase
> -performance) and removing unreachable objects which may have been
> -created from prior invocations of 'git add'.
> +performance), removing unreachable objects which may have been
> +created from prior invocations of 'git add', packing refs, pruning
> +reflog, rerere or stale working trees.

s/rerere/& metadata/

>  Users are encouraged to run this task on a regular basis within
>  each repository to maintain good disk space utilization and good
> @@ -59,6 +60,10 @@ then existing packs (except those marked with a `.keep` file)
>  are consolidated into a single pack by using the `-A` option of
>  'git repack'. Setting `gc.autoPackLimit` to 0 disables
>  automatic consolidation of packs.
> ++
> +If `git gc --auto` goes ahead because of either too loose objects or
> +packs, all other housekeeping tasks (e.g. rerere, working trees,
> +reflog...) will also be be performed.

s/be be/be/

Perhaps this new paragraph should be moved up by one paragraph; the
result feels a bit more cohesive.

Minor rewrite:

    If `git gc --auto` finds that housekeeping is required due to too
    many loose objects or packs, all other housekeeping tasks (e.g.
    rerere, working trees, reflog...) will be performed, as well.

> @@ -133,6 +138,9 @@ The optional configuration variable `gc.pruneExpire` controls how old
>  the unreferenced loose objects have to be before they are pruned.  The
>  default is "2 weeks ago".
>
> +The optional gc.worktreePruneExpire controls how old a stale working
> +tree before `git worktree prune` deletes it. The default is "3 months
> +ago".
>
>  Notes
>  -----

Missing backticks around "gc.worktreePruneExpire".

s/tree before/tree should be before/

You lost a blank line before the "Notes" section.

With minor fixes:

    Optional configuration variable `gc.worktreePruneExpire` controls
    how old a stale working tree should be before `git worktree prune`
    deletes it. Default is "3 months ago".

[PATCH 2/3] worktree: delete dead code

[Nguyễn Thái Ngọc Duy]

This "link" was a feature in early iterations of multiple worktree
functionality but for some reason it was dropped. Since nobody creates
this "link", there's no need to check it.

This is mostly used to let the user moves a worktree manually [1]. If
you move a worktree within the same file system, this hard link count
lets us know the worktree is still there even if we don't know where it
is.

We're having proper worktree move support now and don't need this
anymore.

[1] 23af91d102 (prune: strategies for linked checkouts - 2014-11-30)

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/gitrepository-layout.txt | 5 -----
 builtin/worktree.c                     | 8 --------
 2 files changed, 13 deletions(-)

diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index c60bcad44a..e85148f05e 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -275,11 +275,6 @@ worktrees/<id>/locked::
 	or manually by `git worktree prune`. The file may contain a string
 	explaining why the repository is locked.
 
-worktrees/<id>/link::
-	If this file exists, it is a hard link to the linked .git
-	file. It is used to detect if the linked repository is
-	manually removed.
-
 SEE ALSO
 --------
 linkgit:git-init[1],
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 4e7c98758f..60440c4106 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -99,15 +99,7 @@ static int prune_worktree(const char *id, struct strbuf *reason)
 	}
 	path[len] = '\0';
 	if (!file_exists(path)) {
-		struct stat st_link;
 		free(path);
-		/*
-		 * the repo is moved manually and has not been
-		 * accessed since?
-		 */
-		if (!stat(git_path("worktrees/%s/link", id), &st_link) &&
-		    st_link.st_nlink > 1)
-			return 0;
 		if (st.st_mtime <= expire) {
 			strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
 			return 1;
-- 
2.16.1.435.g8f24da2e1a

[PATCH 3/3] worktree prune: improve prune logic when worktree is moved

[Nguyễn Thái Ngọc Duy]

Worktree manual move support is actually gone in 618244e160 (worktree:
stop supporting moving worktrees manually - 2016-01-22). Before that,
this gitdir could be updated often when the worktree is accessed. That
keeps the worktree from being pruned by this logic.

"git worktree move" is coming so we don't really need this, but since
it's easy to do, perhaps we could keep supporting manual worktree move a
bit longer. Notice that when a worktree is active, the "index" file
should be updated pretty often in common case. The logic is updated to
check for index mtime to see if the worktree is alive.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/worktree.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/builtin/worktree.c b/builtin/worktree.c
index 60440c4106..4d4404e97f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -101,6 +101,9 @@ static int prune_worktree(const char *id, struct strbuf *reason)
 	if (!file_exists(path)) {
 		free(path);
 		if (st.st_mtime <= expire) {
+			if (!stat(git_path("worktrees/%s/index", id), &st) &&
+			    st.st_mtime > expire)
+				return 0;
 			strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
 			return 1;
 		} else {
-- 
2.16.1.435.g8f24da2e1a

Re: [PATCH 3/3] worktree prune: improve prune logic when worktree is moved

[Eric Sunshine]

On Fri, Mar 2, 2018 at 10:39 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Worktree manual move support is actually gone in 618244e160 (worktree:
> stop supporting moving worktrees manually - 2016-01-22). Before that,
> this gitdir could be updated often when the worktree is accessed. That
> keeps the worktree from being pruned by this logic.

I had a bit of trouble digesting this paragraph. Possible rewrite:

    Automatic detection of worktree relocation by a user (via 'mv',
    for instance) was removed by 618244e160 (worktree: stop supporting
    moving worktrees manually - 2016-01-22). Prior to that,
    .git/worktrees/<tag>/gitdir was updated whenever the worktree was
    accessed in order to let the pruning logic know that the worktree
    was "active" even if it disappeared for a while (due to being
    located on removable media, for instance).

> "git worktree move" is coming so we don't really need this, but since
> it's easy to do, perhaps we could keep supporting manual worktree move a
> bit longer. Notice that when a worktree is active, the "index" file
> should be updated pretty often in common case. The logic is updated to
> check for index mtime to see if the worktree is alive.

Seems like a reasonable approximation of the pre-618244e160 way things worked.

> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -101,6 +101,9 @@ static int prune_worktree(const char *id, struct strbuf *reason)
>         if (!file_exists(path)) {
>                 free(path);
>                 if (st.st_mtime <= expire) {

This st.st_mtime is that of 'gitdir'...

> +                       if (!stat(git_path("worktrees/%s/index", id), &st) &&
> +                           st.st_mtime > expire)

...and this st.st_mtime is of 'index'.

I wonder if it the 'gitdir' mtime check is really that useful anymore
considering that 'index' mtime will almost certainly be more recent.

> +                               return 0;
>                         strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
>                         return 1;

RE: [PATCH 0/3] git worktree prune improvements

[Randall S. Becker]

On March 2, 2018 10:39 PM, Nguy?n Thái Ng?c Duy wrote:
> This is something we could do to improve the situation when a user manually
> moves a worktree and not follow the update process (we have had the first
> reported case [1]). Plus a bit cleanup in gc.
> 
> I think this is something we should do until we somehow make the user
> aware that the worktree is broken as soon as they move a worktree
> manually. But there's some more work to get there.
> 
> [1] http://public-inbox.org/git/%3Caa98f187-4b1a-176d-2a1b-
> 826c995776cd@aegee.org%3E

I wonder whether the OT thread discussion about branch annotation may have some value here. For some repositories I manage, I have received questions about whether there was some way to know that a branch in the clone was associated with a worktree "at any point in the past", which, once the worktree has been pruned, is not derivable in a formal computational sense - there may be specific conditions where it is. Perhaps, if that line of development moves forward, that we should considering annotating the worktree-created branch to help with our pruning process and to identify where the branch originated.

Just a thought.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(211288444200000000)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Re: [PATCH 0/3] git worktree prune improvements

[Duy Nguyen]

On Sat, Mar 3, 2018 at 9:21 PM, Randall S. Becker
<rsbecker@nexbridge.com> wrote:
> On March 2, 2018 10:39 PM, Nguy?n Thái Ng?c Duy wrote:
>> This is something we could do to improve the situation when a user manually
>> moves a worktree and not follow the update process (we have had the first
>> reported case [1]). Plus a bit cleanup in gc.
>>
>> I think this is something we should do until we somehow make the user
>> aware that the worktree is broken as soon as they move a worktree
>> manually. But there's some more work to get there.
>>
>> [1] http://public-inbox.org/git/%3Caa98f187-4b1a-176d-2a1b-
>> 826c995776cd@aegee.org%3E
>
> I wonder whether the OT thread discussion about branch annotation may have some value here. For some repositories I manage, I have received questions about whether there was some way to know that a branch in the clone was associated with a worktree "at any point in the past", which, once the worktree has been pruned, is not derivable in a formal computational sense - there may be specific conditions where it is. Perhaps, if that line of development moves forward, that we should considering annotating the worktree-created branch to help with our pruning process and to identify where the branch originated.
>

I think for pruning, we already have that information. If a branch is
associated to a worktree, its HEAD must say so and we must not prune
anything reachable from _any_ HEAD. I made that mistake actually.
Still in process of fixing it (and fsck).
-- 
Duy

[PATCH v2 0/3] git worktree prune improvements

[Nguyễn Thái Ngọc Duy]

v2 fixes comments from Eric and rebases on 'master' since 'worktree
move' has been merged. Commit messages are updated to reflect this.

There's one thing I didn't do is moving the new paragraph up [1]. I
still feel this it's not right to put it there since it starts with
'gc --auto' introduction, then goes to loose objects and packs.
Inserting a note between the loose objects paragraph and the packs one
does not make much sense.

Interdiff

-- 8< --
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 862c931104..3126e0dd00 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -17,7 +17,7 @@ Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
 performance), removing unreachable objects which may have been
 created from prior invocations of 'git add', packing refs, pruning
-reflog, rerere or stale working trees.
+reflog, rerere metadata or stale working trees.
 
 Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
@@ -46,14 +46,14 @@ OPTIONS
 	With this option, 'git gc' checks whether any housekeeping is
 	required; if not, it exits without performing any work.
 	Some git commands run `git gc --auto` after performing
-	operations that could create many loose objects.
+	operations that could create many loose objects. Housekeeping
+	is required if there are too many loose objects or too many
+	packs in the repository.
 +
-Housekeeping is required if there are too many loose objects or
-too many packs in the repository. If the number of loose objects
-exceeds the value of the `gc.auto` configuration variable, then
-all loose objects are combined into a single pack using
-`git repack -d -l`.  Setting the value of `gc.auto` to 0
-disables automatic packing of loose objects.
+If the number of loose objects exceeds the value of the `gc.auto`
+configuration variable, then all loose objects are combined into a
+single pack using `git repack -d -l`.  Setting the value of `gc.auto`
+to 0 disables automatic packing of loose objects.
 +
 If the number of packs exceeds the value of `gc.autoPackLimit`,
 then existing packs (except those marked with a `.keep` file)
@@ -61,9 +61,10 @@ are consolidated into a single pack by using the `-A` option of
 'git repack'. Setting `gc.autoPackLimit` to 0 disables
 automatic consolidation of packs.
 +
-If `git gc --auto` goes ahead because of either too loose objects or
-packs, all other housekeeping tasks (e.g. rerere, working trees,
-reflog...) will also be be performed.
+If houskeeping is required due to many loose objects or packs, all
+other housekeeping tasks (e.g. rerere, working trees, reflog...) will
+be performed as well.
+
 
 --prune=<date>::
 	Prune loose objects older than date (default is 2 weeks ago,
@@ -138,9 +139,10 @@ The optional configuration variable `gc.pruneExpire` controls how old
 the unreferenced loose objects have to be before they are pruned.  The
 default is "2 weeks ago".
 
-The optional gc.worktreePruneExpire controls how old a stale working
-tree before `git worktree prune` deletes it. The default is "3 months
-ago".
+Optional configuration variable `gc.worktreePruneExpire` controls how
+old a stale working tree should be before `git worktree prune` deletes
+it. Default is "3 months ago".
+
 
 Notes
 -----
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 4d4404e97f..b1e8f0534c 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -100,10 +100,8 @@ static int prune_worktree(const char *id, struct strbuf *reason)
 	path[len] = '\0';
 	if (!file_exists(path)) {
 		free(path);
-		if (st.st_mtime <= expire) {
-			if (!stat(git_path("worktrees/%s/index", id), &st) &&
-			    st.st_mtime > expire)
-				return 0;
+		if (stat(git_path("worktrees/%s/index", id), &st) ||
+		    st.st_mtime <= expire) {
 			strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
 			return 1;
 		} else {
diff --git a/t/t2026-worktree-prune.sh b/t/t2026-worktree-prune.sh
index a0f1e3bb80..b7d6d5d45a 100755
--- a/t/t2026-worktree-prune.sh
+++ b/t/t2026-worktree-prune.sh
@@ -78,10 +78,9 @@ test_expect_success 'not prune locked checkout' '
 
 test_expect_success 'not prune recent checkouts' '
 	test_when_finished rm -r .git/worktrees &&
-	mkdir zz &&
-	mkdir -p .git/worktrees/jlm &&
-	echo "$(pwd)"/zz >.git/worktrees/jlm/gitdir &&
-	rmdir zz &&
+	git worktree add jlm HEAD &&
+	test -d .git/worktrees/jlm &&
+	rm -rf jlm &&
 	git worktree prune --verbose --expire=2.days.ago &&
 	test -d .git/worktrees/jlm
 '
-- 8< --


[1] https://public-inbox.org/git/CAPig+cSo_n7y3-qDT92+NYspTB+yF+NUL19MLvfztLJ_qZhXnw@mail.gmail.com/

Nguyễn Thái Ngọc Duy (3):
  gc.txt: more details about what gc does
  worktree: delete dead code
  worktree prune: improve prune logic when worktree is moved

 Documentation/git-gc.txt               | 28 +++++++++++++++++---------
 Documentation/gitrepository-layout.txt |  5 -----
 builtin/worktree.c                     | 11 ++--------
 t/t2026-worktree-prune.sh              |  7 +++----
 4 files changed, 24 insertions(+), 27 deletions(-)

-- 
2.16.2.903.gd04caf5039

[PATCH v2 1/3] gc.txt: more details about what gc does

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-gc.txt | 28 +++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 571b5a7e3c..3126e0dd00 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -15,8 +15,9 @@ DESCRIPTION
 -----------
 Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
-performance) and removing unreachable objects which may have been
-created from prior invocations of 'git add'.
+performance), removing unreachable objects which may have been
+created from prior invocations of 'git add', packing refs, pruning
+reflog, rerere metadata or stale working trees.
 
 Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
@@ -45,20 +46,25 @@ OPTIONS
 	With this option, 'git gc' checks whether any housekeeping is
 	required; if not, it exits without performing any work.
 	Some git commands run `git gc --auto` after performing
-	operations that could create many loose objects.
+	operations that could create many loose objects. Housekeeping
+	is required if there are too many loose objects or too many
+	packs in the repository.
 +
-Housekeeping is required if there are too many loose objects or
-too many packs in the repository. If the number of loose objects
-exceeds the value of the `gc.auto` configuration variable, then
-all loose objects are combined into a single pack using
-`git repack -d -l`.  Setting the value of `gc.auto` to 0
-disables automatic packing of loose objects.
+If the number of loose objects exceeds the value of the `gc.auto`
+configuration variable, then all loose objects are combined into a
+single pack using `git repack -d -l`.  Setting the value of `gc.auto`
+to 0 disables automatic packing of loose objects.
 +
 If the number of packs exceeds the value of `gc.autoPackLimit`,
 then existing packs (except those marked with a `.keep` file)
 are consolidated into a single pack by using the `-A` option of
 'git repack'. Setting `gc.autoPackLimit` to 0 disables
 automatic consolidation of packs.
++
+If houskeeping is required due to many loose objects or packs, all
+other housekeeping tasks (e.g. rerere, working trees, reflog...) will
+be performed as well.
+
 
 --prune=<date>::
 	Prune loose objects older than date (default is 2 weeks ago,
@@ -133,6 +139,10 @@ The optional configuration variable `gc.pruneExpire` controls how old
 the unreferenced loose objects have to be before they are pruned.  The
 default is "2 weeks ago".
 
+Optional configuration variable `gc.worktreePruneExpire` controls how
+old a stale working tree should be before `git worktree prune` deletes
+it. Default is "3 months ago".
+
 
 Notes
 -----
-- 
2.16.2.903.gd04caf5039

[PATCH v2 2/3] worktree: delete dead code

[Nguyễn Thái Ngọc Duy]

This "link" was a feature in early iterations of multiple worktree
functionality for some reason it was dropped [1]. Since nobody creates
this "link", there's no need to check it.

This is mostly used to let the user moves a worktree manually [2]. If
you move a worktree within the same file system, this hard link count
lets us know the worktree is still there even if we don't know where it
is.

We support 'worktree move' now and don't need this anymore.

[1] last appearance in v4 message-id:
    1393675983-3232-25-git-send-email-pclouds@gmail.com
    and the reason in v5 was "revisit later", message-id:
    1394246900-31535-1-git-send-email-pclouds@gmail.com
[2] 23af91d102 (prune: strategies for linked checkouts - 2014-11-30)

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/gitrepository-layout.txt | 5 -----
 builtin/worktree.c                     | 8 --------
 2 files changed, 13 deletions(-)

diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index c60bcad44a..e85148f05e 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -275,11 +275,6 @@ worktrees/<id>/locked::
 	or manually by `git worktree prune`. The file may contain a string
 	explaining why the repository is locked.
 
-worktrees/<id>/link::
-	If this file exists, it is a hard link to the linked .git
-	file. It is used to detect if the linked repository is
-	manually removed.
-
 SEE ALSO
 --------
 linkgit:git-init[1],
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 670555dedd..e55edf2aa5 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -101,15 +101,7 @@ static int prune_worktree(const char *id, struct strbuf *reason)
 	}
 	path[len] = '\0';
 	if (!file_exists(path)) {
-		struct stat st_link;
 		free(path);
-		/*
-		 * the repo is moved manually and has not been
-		 * accessed since?
-		 */
-		if (!stat(git_path("worktrees/%s/link", id), &st_link) &&
-		    st_link.st_nlink > 1)
-			return 0;
 		if (st.st_mtime <= expire) {
 			strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
 			return 1;
-- 
2.16.2.903.gd04caf5039

Re: [PATCH v2 2/3] worktree: delete dead code

[Eric Sunshine]

On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> This "link" was a feature in early iterations of multiple worktree
> functionality for some reason it was dropped [1]. Since nobody creates
> this "link", there's no need to check it.
>
> This is mostly used to let the user moves a worktree manually [2]. If

s/moves/move/

(Not worth a re-roll; perhaps Junio can tweak this when queuing.)

> you move a worktree within the same file system, this hard link count
> lets us know the worktree is still there even if we don't know where it
> is.
>
> We support 'worktree move' now and don't need this anymore.
>
> [1] last appearance in v4 message-id:
>     1393675983-3232-25-git-send-email-pclouds@gmail.com
>     and the reason in v5 was "revisit later", message-id:
>     1394246900-31535-1-git-send-email-pclouds@gmail.com
> [2] 23af91d102 (prune: strategies for linked checkouts - 2014-11-30)
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

[PATCH v2 3/3] worktree prune: improve prune logic when worktree is moved

[Nguyễn Thái Ngọc Duy]

Automatic detection of worktree relocation by a user (via 'mv', for
instance) was removed by 618244e160 (worktree: stop supporting moving
worktrees manually - 2016-01-22). Prior to that,
.git/worktrees/<tag>/gitdir was updated whenever the worktree was
accessed in order to let the pruning logic know that the worktree was
"active" even if it disappeared for a while (due to being located on
removable media, for instance).

"git worktree move" has come so we don't really need this, but since
it's easy to do, perhaps we could keep supporting manual worktree move
a bit longer. Notice that when a worktree is active, the "index" file
should be updated pretty often in common case. The logic is updated to
check for index mtime to see if the worktree is alive.

The old logic of checking gitdir's mtime is dropped because nobody
updates it anyway. The new corner case is, if the index file does not
exist, we immediately remove the stale worktree. But if the "index"
file does not exist, you may have a bigger problem.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/worktree.c        | 3 ++-
 t/t2026-worktree-prune.sh | 7 +++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/builtin/worktree.c b/builtin/worktree.c
index e55edf2aa5..594ace7c2b 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -102,7 +102,8 @@ static int prune_worktree(const char *id, struct strbuf *reason)
 	path[len] = '\0';
 	if (!file_exists(path)) {
 		free(path);
-		if (st.st_mtime <= expire) {
+		if (stat(git_path("worktrees/%s/index", id), &st) ||
+		    st.st_mtime <= expire) {
 			strbuf_addf(reason, _("Removing worktrees/%s: gitdir file points to non-existent location"), id);
 			return 1;
 		} else {
diff --git a/t/t2026-worktree-prune.sh b/t/t2026-worktree-prune.sh
index a0f1e3bb80..b7d6d5d45a 100755
--- a/t/t2026-worktree-prune.sh
+++ b/t/t2026-worktree-prune.sh
@@ -78,10 +78,9 @@ test_expect_success 'not prune locked checkout' '
 
 test_expect_success 'not prune recent checkouts' '
 	test_when_finished rm -r .git/worktrees &&
-	mkdir zz &&
-	mkdir -p .git/worktrees/jlm &&
-	echo "$(pwd)"/zz >.git/worktrees/jlm/gitdir &&
-	rmdir zz &&
+	git worktree add jlm HEAD &&
+	test -d .git/worktrees/jlm &&
+	rm -rf jlm &&
 	git worktree prune --verbose --expire=2.days.ago &&
 	test -d .git/worktrees/jlm
 '
-- 
2.16.2.903.gd04caf5039

Re: [PATCH v2 3/3] worktree prune: improve prune logic when worktree is moved

[Eric Sunshine]

On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> Automatic detection of worktree relocation by a user (via 'mv', for
> instance) was removed by 618244e160 (worktree: stop supporting moving
> worktrees manually - 2016-01-22). Prior to that,
> .git/worktrees/<tag>/gitdir was updated whenever the worktree was
> accessed in order to let the pruning logic know that the worktree was
> "active" even if it disappeared for a while (due to being located on
> removable media, for instance).

This is my fault since I suggested this rewrite[1], but other
documentation calls this <id>, not <tag>, so: s/tag/id/

(Again, not worth a re-roll; perhaps Junio can tweak it when queuing.)

> "git worktree move" has come so we don't really need this, but since
> it's easy to do, perhaps we could keep supporting manual worktree move
> a bit longer. Notice that when a worktree is active, the "index" file
> should be updated pretty often in common case. The logic is updated to
> check for index mtime to see if the worktree is alive.
>
> The old logic of checking gitdir's mtime is dropped because nobody
> updates it anyway. The new corner case is, if the index file does not
> exist, we immediately remove the stale worktree. But if the "index"
> file does not exist, you may have a bigger problem.

Makes sense.

> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

[1]: https://public-inbox.org/git/CAPig+cQG8yEqunNUjoEAPY-W9+TtzWADhgjdL6udnyrG0YEOVg@mail.gmail.com/

Re: [PATCH v2 0/3] git worktree prune improvements

[Eric Sunshine]

On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> v2 fixes comments from Eric and rebases on 'master' since 'worktree
> move' has been merged. Commit messages are updated to reflect this.

Thanks. Aside from a couple minor commit message tweaks (not worth a
re-roll), I didn't find anything else on which to comment on this
version.

> There's one thing I didn't do is moving the new paragraph up [1]. I
> still feel this it's not right to put it there since it starts with
> 'gc --auto' introduction, then goes to loose objects and packs.
> Inserting a note between the loose objects paragraph and the packs one
> does not make much sense.

Fair enough.