Well, I think this does kind of have some commonality with another issue
that has come up before: git clone only clones the really core repository
data.
That's generally a big feature, and I think it's absolutely the correct
thing to do.
But I can also see that sometimes, you might want to clone more than the
actual repository, and get things like SVN metadata, branch reflogs,
various hooks and all the config options too.
Of course, in practice, at least right now, the right thing to do for that
is to just do a recursive filesystem copy and then a "git status", but I
think the background here is that some people simply do end up wanting to
transfer more infrastructure than just the actual repository data.
One thing to note: one reason for *not* allowing that is that incremental
upgrades of non-repo data is obviously not possible. You might be able to
*clone* a repo with config info and other metadata (if nothing else, then
by just doing that raw filesystem copy), but you will never ever be able
to _fetch_ the updates, because they aren't part of the core repository,
and aren't versioned.
So I think I can understand why some people would want to do things like
this, but I do think it's broken. Yes, you can make the grafts file (or
the config file) be part of the repo, and even just add a symlink to your
.git/ directory, but it's simply not a very good model.
So I think it always does end up breaking (other people might rebase, and
break your grafts, or just not want them in the first place, or they don't
care about the same things, and mess up "your" configuration etc etc). So
the git repo layout is designed to have the minimally required shared
state, and not anything else.
Linus
-
