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.

		Linus