mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <>
To: Duy Nguyen <>
Cc: "Дилян Палаузов" <>,
	"Git List" <>
Subject: Re: Worktree silently deleted on git fetch/gc/log
Date: Sat, 3 Mar 2018 05:05:20 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Mar 2, 2018 at 6:53 AM, Duy Nguyen <> wrote:
> I'm going to improve it a bit in this case either way, I think I have
> some idea: (mostly to Eric) since worktree B is alive and kicking, it
> should keep at least HEAD or index updated often. We can delay
> deleting a worktree until both of these are past expire time.

Make sense.

> Also Eric (and this is getting off topic), I wonder if the decision to
> store absolute path in worktrees/../gitdir and .git files is a bad one
> (and is my bad).

Your original implementation of worktrees was able to recover
automatically when a worktree was moved (via 'mv', for instance). That
feature pretty much required recording an absolute path in the
worktree's .git file. When the automatic-recovery feature was dropped,
I suppose the need for absolute path in the .git file disappeared, as

I can't presently think of a reason why gitdir needed/used an absolute
or normalized path. Was it because there was some need to compare such

> If we stored relative path in ".git" file at least, the worktree would
> immediately fail after the user moves either the linked checkout, or
> the main one. This should send a loud and clear signal to the user
> "something has gone horribly" and hopefully make them connect it to
> the last rename and undo that. "git gc" would have near zero chance to
> kick in and destroy stale worktrees.

It would detect if the main or linked worktree moved up or down one or
more directory levels or elsewhere.

It would not detect if the worktree directory was merely renamed.

Still, detecting some cases of breakage early may be better than not
detecting breakage at all.

Another idea may be to store the worktree's own normalized/absolute
path as a second line in its .git file. It could then immediately
detect any manual movement or renaming of itself. A minor concern,
though, is if there are any external tools reading that file directly
since they could be confused by the second line. Of course, such tools
hopefully would be using "git rev-parse --git-dir", so maybe it
wouldn't be a big deal. On the other hand, older versions of Git
itself would be confused by the second line, so perhaps the idea isn't

> Another bad thing about absolute paths, if you backup both main and
> linked worktrees in a tar file, restoring from the backup won't work
> unless you restore at the exact same place.
> Hmm?

Yep, that's an issue. An even simpler case is the somewhat common
usage pattern of creating worktrees within the main worktree (Dscho
has a number of times mentioned working like this, and I've done it
myself). In such a case, even just moving or renaming the main
worktree breaks the linked ones when absolute paths are in play.

So, yes, these issue argue for use of relative paths.

  reply	other threads:[~2018-03-03 10:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 12:44 Worktree silently deleted on git fetch/gc/log Дилян Палаузов
2018-03-01 18:09 ` Eric Sunshine
2018-03-01 19:24   ` Дилян Палаузов
2018-03-01 20:14     ` Eric Sunshine
2018-03-01 23:56       ` Duy Nguyen
2018-03-02 11:34         ` Дилян Палаузов
2018-03-02 11:40           ` Eric Sunshine
2018-03-02 11:53           ` Duy Nguyen
2018-03-03 10:05             ` Eric Sunshine [this message]
2018-03-07 10:01               ` Duy Nguyen

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).