On Thu, 24 Jan 2008, Willy Tarreau wrote:
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
