Re: Multiple working trees with GIT ?

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Jan 24, 2008, 09:59 UTC
Message-ID: <Pine.LNX.4.64.0801240947230.14173@reaper.quantumfyre.co.uk>
In-Reply-To: <20080124074952.GA8793@1wt.eu>

On Thu, 24 Jan 2008, Willy Tarreau wrote:

Show 63 quoted lines

> Hi all,
>
> I'm having long thoughts about how to use GIT to manage a distro. One of
> the aspects which comes very often is the notion of "variant" for a
> packaging. For instance, the whole project could consist in a list of packages
> with their branches, but this list may vary depending on the platform, the
> medium, etc... I was searching how to propagate common changes withing variants
> with the least hassle.
>
> I figured out that having one file list per variant will be very annoying. In
> another project, that's already what I have and frankly, applying the same
> change to 10 files is counter-productive. Since the lists will often be the
> sames except for a few entries, and since most updates will be relevant to
> all variants, I thought branches will be my best friends.
>
> But I would like to be able to always access file lists, without having to
> constantly git-checkout <variant-X>.
>
> Finally, I found a very convenient solution, but I don't know if there are
> any risks using it. If we can conclude to a riskless usage (with/without
> some adjustments), I can contribute a script to setup this environment.
>
> The idea is to have multiple working trees in a subdirectory of the normal
> one. Some would probably like them to be movable anywhere else, but let's
> not complicate things first. But in order not to constantly have to pull/push
> in every tree, I set up the .git repo of each working tree with many symlinks :
>
>  project/
>          .git/ (normal repo)
>          ... master checked out there by default ...
>          worktree/
>                   variant_a/
>                             .git/ (symlinks)
>                   variant_b/
>                             .git/ (symlinks)
>                   variant_c/
>                             .git/ (symlinks)
>
>
> Each variant is set up like this :
>    4096 Jan 24 08:44 .git
>      19 Jan 24 08:27 .git/HEAD
>      28 Jan 24 08:30 .git/logs
>     419 Jan 24 08:44 .git/logs/HEAD
>      26 Jan 24 08:31 .git/logs/refs -> ../../../../.git/logs/refs
>      18 Jan 24 08:31 .git/refs -> ../../../.git/refs
>      21 Jan 24 08:31 .git/objects -> ../../../.git/objects
>      18 Jan 24 08:31 .git/info -> ../../../.git/info
>      19 Jan 24 08:31 .git/hooks -> ../../../.git/hooks
>      25 Jan 24 08:31 .git/description -> ../../../.git/description
>      20 Jan 24 08:31 .git/config -> ../../../.git/config
>     118 Jan 24 08:44 .git/index
>      22 Jan 24 08:31 .git/branches -> ../../../.git/branches
>      63 Jan 24 08:44 .git/FETCH_HEAD
>      41 Jan 24 08:44 .git/ORIG_HEAD
>
> In fact, I found that each directory which hosts a HEAD file needs to
> remain a directory because of this head, but all other dirs can be
> symlinks to original tree.
>
> This works pretty well. I can simply cd worktree/variant_a and work on a
> file, or pull master, or even git-cherry-pick from other branches (pretty
> convenient for this usage). But I don't know what caveats I may encounter.

You might want to have a look at the git-new-workdir script in contrib, it does basically the same thing. It's been there for about 10 months now. It was based on an email from Junio:

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

However, there are some caveats about using this approach, basically about the fact that there is nothing stopping you from updating refs that are currently checked out in another directory and causing yourself all sorts of pain ... the topic has cropped up a couple of times on the list since the script was added.

> Maybe there are other solutions too. I see that we tend to replace symlinks
> everywhere with ref files. We might as well (in a far future version) accept
> a file for ".git" which would contain a path to the central repo and the
> branch's head.

There was a suggestion for something not too dissimilar even before the new-workdir script:

http://thread.gmane.org/gmane.comp.version-control.git/33755

AFAIK it hasn't actually been implemented.

-- 
Julian

  ---
May your SO always know when you need a hug.