git worktree prune improvements
cover git worktree prune improvements
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/%[email protected]%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(-)
Signature · 1 line
2.16.1.435.g8f24da2e1a
PATCH 1/3 gc.txt: more details about what gc does
--- Documentation/git-gc.txt | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
Documentation/git-gc.txt +10 -2
@@ -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 -----
Signature · 1 line
2.16.1.435.g8f24da2e1a
PATCH 2/3 worktree: delete dead code
In reply to Nguyễn Thái Ngọc DuyThis "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)
--- Documentation/gitrepository-layout.txt | 5 ----- builtin/worktree.c | 8 -------- 2 files changed, 13 deletions(-)
Documentation/gitrepository-layout.txt +0 -5
@@ -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],
builtin/worktree.c +0 -8
@@ -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 ;
Signature · 1 line
2.16.1.435.g8f24da2e1a
PATCH 3/3 worktree prune: improve prune logic when worktree is moved
In reply to Nguyễn Thái Ngọc DuyWorktree 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.
--- builtin/worktree.c | 3 +++ 1 file changed, 3 insertions(+)
builtin/worktree.c +3 -0
@@ -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 {
Signature · 1 line
2.16.1.435.g8f24da2e1a
Re: [PATCH 1/3] gc.txt: more details about what gc does
In reply to Nguyễn Thái Ngọc DuyDocumentation/git-gc.txt DESCRIPTION · line 20
Quoted 12 lines · Nguyễn Thái Ngọc Duy
Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>---
Documentation/git-gc.txt +3
-2@@ -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/
Documentation/git-gc.txt then existing packs (except those marked with a `.keep` file) · line 66
Quoted 10 lines
Documentation/git-gc.txt +4
-0Users 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.
Documentation/git-gc.txt The optional configuration variable `gc.pruneExpire` controls how old · line 146
Quoted 10 lines
Documentation/git-gc.txt +3
-0@@ -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".
Re: [PATCH 3/3] worktree prune: improve prune logic when worktree is moved
In reply to Nguyễn Thái Ngọc DuyQuoted 4 lines · 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.
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).
Quoted 5 lines
"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.
builtin/worktree.c static int prune_worktree(const char *id, struct strbuf *reason) · line 103
Quoted 7 lines
Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>---
builtin/worktree.c +0
-0@@ -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'...
builtin/worktree.c static int prune_worktree(const char *id, struct strbuf *reason) · line 105
Quoted 2 lines
builtin/worktree.c +2
-0+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.
Quoted 3 lines
builtin/worktree.c +1
-0+return 0 ;strbuf_addf (reason,_ ("Removing worktrees/%s: gitdir file points to non-existent location" ), id);return 1 ;
Quoted 10 lines · 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-
[email protected]%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.
Quoted 5 lines · Randall S. Becker
Quoted 4 lines · 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.
Quoted 9 lines
Quoted 6 lines
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-
[email protected]%3EI 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).
Signature · 1 line
Duy
v2 cover git worktree prune improvements
In reply to Nguyễn Thái Ngọc Duyv2 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< --
Documentation/git-gc.txt +16 -14
@@ -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 -----
builtin/worktree.c +2 -4
@@ -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 {
t/t2026-worktree-prune.sh +3 -4
@@ -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(-)
Signature · 1 line
2.16.2.903.gd04caf5039
PATCH v2 1/3 gc.txt: more details about what gc does
--- Documentation/git-gc.txt | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-)
Documentation/git-gc.txt +19 -9
@@ -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 -----
Signature · 1 line
2.16.2.903.gd04caf5039
PATCH v2 2/3 worktree: delete dead code
In reply to Nguyễn Thái Ngọc DuyThis "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:
[email protected] and the reason in v5 was "revisit later", message-id: [email protected]
[2] 23af91d102 (prune: strategies for linked checkouts - 2014-11-30)
--- Documentation/gitrepository-layout.txt | 5 ----- builtin/worktree.c | 8 -------- 2 files changed, 13 deletions(-)
Documentation/gitrepository-layout.txt +0 -5
@@ -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],
builtin/worktree.c +0 -8
@@ -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 ;
Signature · 1 line
2.16.2.903.gd04caf5039
PATCH v2 3/3 worktree prune: improve prune logic when worktree is moved
In reply to Nguyễn Thái Ngọc DuyAutomatic 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.
--- builtin/worktree.c | 3 ++- t/t2026-worktree-prune.sh | 7 +++---- 2 files changed, 5 insertions(+), 5 deletions(-)
builtin/worktree.c +2 -1
@@ -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 {
t/t2026-worktree-prune.sh +3 -4
@@ -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 '
Signature · 1 line
2.16.2.903.gd04caf5039
Re: [PATCH v2 2/3] worktree: delete dead code
In reply to Nguyễn Thái Ngọc DuyQuoted 5 lines · 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
s/moves/move/
(Not worth a re-roll; perhaps Junio can tweak this when queuing.)
Quoted 13 lines
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:
[email protected] and the reason in v5 was "revisit later", message-id: [email protected][2]
23af91d102(prune: strategies for linked checkouts - 2014-11-30)Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>
Re: [PATCH v2 3/3] worktree prune: improve prune logic when worktree is moved
In reply to Nguyễn Thái Ngọc DuyQuoted 7 lines · 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).
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.)
Quoted 10 lines
"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.
Quoted 1 line
Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>
[1]: https://public-inbox.org/git/CAPig+cQG8yEqunNUjoEAPY-W9+TtzWADhgjdL6udnyrG0YEOVg@mail.gmail.com/
Quoted 2 lines · 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.
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.
Quoted 5 lines
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.