>> I found vcsh today while looking for similar projects to mine that
>> exploited GIT_DIR to do overlaid git repos.
> Out of interest, did you find anything else?
You mean other similar projects? Not really (but a few stackoverflow questions).
I actually think this should be built-in git functionality. If they
would add --work-dir and --git-dir to `git clone` this would allow
users to at least clone repos overlaid without having to use
yet-another wrapper script, and only get a script if they want to do
> FWIW, bremner has abused vcsh as a poor man's multigit and there's a
> feature/agnostic branch for vcsh which go in a similar direction.
Good to know. I'll check that out too.
> Heh, quite. I have to say that I find the order of the release
> subcommands counter-intuitive and the total control user commands can
> have somewhat dangerous, but your clone foo=12345 is quite brilliant,
> especially for multigit's use case.
I know it's backwards, but it's intentional -- it makes sense if
you're using the up-arrow key to gradually get to a decision:
git release <- list releases
git release 1.0 <- list 1.0's modules
git release 1.1 <- list 1.1's modules
git release 1.1 checkout <- ok, let's get this one
> PS: I am half-wondering if it would make sense to merge the two, but
> as you store directory-specific (by default) and I store user-specific
> (by default) that may be a way of. _Or_ an excuse to extend one of
Well, my answer to extending is to make multigit plugins. Since it's
all layered, you can make a "utility repo" with the scripts that you
need for your specific project and clone that in along with the other
repos. If you put the scripts in the .mgit directory, mgit will act
like the user interface for them (i.e. calling `mgit script ...` will
execute `.mgit/script.sh ...`). This way you don't pollute the
project's namespace with utility scripts. It's not a big idea, just
something that fits naturally into the whole scheme. The nice thing is
that you can make more than one of these utility repos and clone them
on top of one another, eg. you may have one that extends git in a more
generic way which you share between many projects, but you also have
another one that is specific to a single project (eg. it contains
build scripts for that project).
vcs-home mailing list