Hi,
Seth Falcon <sethfalcon <at> gmail.com> writes:
> Eric Wong <normalperson <at> yhbt.net> writes:
> > I can't reproduce it on Linux with ext3. I translated your recipe into
> > a test script in the patch below. Anybody familiar with OSX and/or HFS
> > know if there's a workaround or fix for this?
I've been investigating this problem too, as it keeps biting me when importing
our (OpenXPKIs) subversion tree using git-svn. I'd love to work with git and
am happy to help with debugging this further. Still, I am a pretty puzzled on why
this happens ...
> And so then on Linux with -v I get (after snipping most of the
> output):
> First, rewinding head to replay your work on top of it...
> symlink: 'foo.txt' => 'bar.txt'
> On my OSX laptop I get:
> First, rewinding head to replay your work on top of it...
> symlink: 'foo.txt' => ''
Same here (this is a MacBook Pro, for what it's worth, BTW). As said, I've
investigated this a bit further. The empty filename in new seems to come from
trying to read the wrong SHA1 file. If one outputs ce->sha1 before
void *new = read_sha1_file(ce->sha1, &type, size);
is called, one gets different output on Linux and Mac OS X.
For Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux
and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ...
I've tried tracking down where this comes from. Here is what I've learned:
- read_blob_entry() is called from write_entry().
SHA1 is already incorrect at that point in time.
- write_entry() is called from checkout_entry().
SHA1 is already incorrect at that point in time.
- checkout_entry() is called from check_updates().
SHA1 is already incorrect at that point in time.
Unluckily I could not figure out, where it is computed in the first place.
One idea was that maybe it was cached from the old file in the Mac OS X case
and recomputed on Linux or so? Or maybe it's not git's fault but git-svn
messes up (although I doubt it)?
I'll happy try out anything that has a slight chance of solving this issue
(workarounds greatly appreciated, too).
Best regards,
Alex
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html