Re: Recording merges after repo conversion

> 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.