Re: [PATCH/POC 3/7] setup.c: add split-repo support to .git files

From: Duy Nguyen <pclouds@gmail.com>
Date: Dec 14, 2013, 01:28 UTC
Message-ID: <CACsJy8DtPw7_OH+vH3zhrgaeir6GbHSNzbWYtD02ozOnAJYE+w@mail.gmail.com>
In-Reply-To: <20131213204348.GX2311@google.com>

On Sat, Dec 14, 2013 at 3:43 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 22 quoted lines

> Junio C Hamano wrote:
>
>>  - Do we want to record where the working tree directory is in
>>    $GIT_SUPER_DIR/repos/<id> somewhere?  Would it help to have such
>>    a record?
>
> That could be nice for the purpose of garbage collecting them.  I fear
> that for users it is too tempting to remove a worktree with "rm -rf"
> without considering the relationship from the parent repo that might
> be making walking through all reflogs slower or holding on to objects
> no one cares about any more.
>
> I imagine it would work like this:
>
>  1. At worktree creation time, full path to the working tree directory
>     is stored in $GIT_SUPER_DIR/repos/<id>.
>
>  2. "git gc" notices that the worktree is missing and writes a file
>     under $GIT_SUPER_DIR/repos/<id> with a timestamp, saying so.
>
>  3. If the worktree still hasn't existed for a month, "git gc" deletes
>     the corresponding $GIT_SUPER_DIR/repos/<id> directory.

I was thinking about doing something like this in "git prune" but manually. Your idea sounds nicer.

Show 5 quoted lines

> Problems:
>
>  * What if I move my worktree with "mv"?  Then I still need the
>    corresponding $GIT_SUPER_DIR/repos/<id> directory, and nobody told
>    the GIT_SUPER_DIR about it.

We could store $GIT_SUPER_DIR as relative path. That way if you move it, you break it. When you fix it, hopefully you remember to fix the link in repos/<id> too

Alternatively, the setup up code could be taught to verify that $GIT_SUPER_DIR/repos/id/<backlink> actually points to the current worktree. If not warn the user or something

>  * What if my worktree is on removable media (think "network
>    filesystem") and has just been temporarily unmounted instead of
>    deleted?

Or we keep update a timestamp in repos/<id> to note the last used time of this worktree. "gc" or "prune" would warn about unused repos after a certain amount of time, do not remove them automatically. This could be iii. to your list below.

Show 6 quoted lines

> So maybe it would be nicer to:
>
>   i. When the worktree is on the same filesystem, keep a *hard link* to
>      some file in the worktree (e.g., the .git file).  If the link count
>      goes down, it is safe to remove the $GIT_SUPER_DIR/repos/<id>
>      directory.

This can still break with updating by creating a new version, then renaming it. Although I can't think why anybody (or anything) would want to do that on .git file. This does not work on Windows though.

Show 5 quoted lines

>  ii. When the worktree is on another filesystem, always keep
>      $GIT_SUPER_DIR/repos/<id> unless the user decides to manually
>      remove it.  Provide documentation or a command to list basic
>      information about $GIT_SUPER_DIR/repos directories (path to
>      worktree, what branch they're on, etc).

And on Windows, a new partition means a new drive, so it works there too.

Show 12 quoted lines

>
> (i) doesn't require any futureproofing.  As soon as someone wants it,
> they can implement the check and fall back to (ii) for worktrees
> without the magic hard link.
>
> (ii) would benefit from recording the working tree directory as a
> possibly unreliable, human-friendly reminder.
>
>>  - How would this interact with core.worktree in .git/config of that
>>    "super" repository?
>
> Eek.

I'll see if I can ignore core.worktree when $GIT_SUPER_DIR is set. If not, ban this use case :)

-- 
Duy