On Wednesday 31 October 2007, Linus Torvalds wrote: > On Wed, 31 Oct 2007, Johannes Schindelin wrote: > > Seriously, your proposal does not make any sense. If you have to set up a > > hook to get the _sane_ behaviour, something is really wrong. So I do not > > really understand why you brought up this idea here and now. > > 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. I agree that sharing the "metainfo" (i.e. config, grafts, hooks, reflogs, rerere magic, etc.) of the repo is not something git should do in the general case. But in some specific workflows (e.g. in-house, centralized workflows), I think it makes sense to coordinate/share some of this info between repos. But in that case, I guess such coordination/sharing can be done by special-purpose tools built on top of git (e.g. in-house admin scripts). ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net
Attachment:
signature.asc
Description: This is a digitally signed message part.
