Re: More problems...

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 29 Apr 2005, Ryan Anderson wrote:
> 
> Why not just use "rsync" for both remote and local synchronization, and
> provide a "relink" command to scan two .git/objects/ repositories and
> hardlink matching files together?

Absolutely. I use the same "git-pull-script" between two local directories 
on disk. The only issue there is that you have to give the ".git" 
directory, ie you should do

	git-pull-script ~/by/other/repository/.git

instead of pointing to the other repo's root.

Of course, I don't bother with the linking. But that's the trivial part.

> With the SHA1 hash, you can even have a --unsafe option that just
> compares the has names and does a link based purely off of that and the
> stat(2) results of both files.  (I'd expect that a ... safer variant
> would extract both files and compare them, but the --unsafe should be
> sufficient, in practice, I would think.)

I don't think there is any point to unsafe. The assumption is that if you 
do things this way, the "unlinked" files will the the uncommon case, so 
what you do is

 - remember the list of files you copied when you did the pull (you had to 
   have this list at some point anyway). Sort by name,
 - create a list of names of both repositories, sorted by name
 - do the union of those three lists (cheap, thanks to the sorting)
 - stat each name to see if it's already linked (which it will be, most of 
   the time), continue to the next one..
 - if they aren't linked, just do a "cmp" on them, and warn if they aren't 
   the same, continue to the next one.
 - else link them.

And if you want to, you can skip the first stage, and just relink two
trees without looking at a list of "known new" files - it's going to be
expensive to link two big repositories the _first_ time, but hey even the
"expensive" part is likely to be pretty cheap in the end. If it takes an
hour or two to relink some years of history, big deal. Do it overnight,
you only need it once.

		Linus