Re: git-relink status (or bug?)

["marc zonzon" <marc.zonzon+git@gmail.com>]

Thank you for your answer

On Sat, Jun 21, 2008 at 9:22 PM, Junio C Hamano <gitster@pobox.com> wrote:

>
> I do not think anybody uses it these days.  Instead either they clone with
> reference (or -s), or perhaps use new-workdir.

The goal of git-relink is analogous to the default local clone,
hardlinks can be safer than
 sharing because you don't loose anything when the origin directory
reset a branch.
I remark that git-clone(1) warn about -s use, but not --reference, but
they seems identical on these aspects.

In numerous cases you cannot suppose your alternate will keep your
objects forever.
I have posted recently such a case study
http://thread.gmane.org/gmane.comp.version-control.git/85407
and when trying hardlinks, i found this bug. It happens that sharing
was a better solution
(but only with the help of Shawn answer I could set it up!)

This new-workdir seems also a nice script, that I never looked at
before (But why is there no documentation on these contrib?)

>
> Here is a totally untested fix.
>
> The "careful" part can be made much more clever and efficient by learning
> implementation details about the .idx file (it has the checksum for itself
> and the checksum for its .pack file at the end) but I did not bother.

Thank you
I see that you only take the safe way, don't hardlink if something is
different, but there would be a more efficient one, to link when the
packs have the same name, and link also the idx. If they have the same
name they have the same content (with a fair probability!)

I cannot provide a patch for that, because I'm not a perl programmer,
and I'm too lazy to rewrite it in C or python!

> I do not think this in its current shape is committable, without
> improvements and success reports from the list.  Hint, hint...

Being "perl challenged" I cannot readproof the script, but at least I
can test it but only on trivial test cases which make git-relink fail!
(I have only tried once to use it to solve the previously cited
problem)

Marc