Hi there,
> Sorry, I forgot the details, could you quickly remind me why these caches
> are not in the pack index files?
Er, I'm not sure what you mean. Are you asking why these revision
caches are required if we have a pack index, or why they aren't in the
pack index, or something different? I'm thinking probably the second:
the short answer is that cache slices are totally independant of pack
files.
It might be possible to somehow merge revision cache slices with pack
indexes, but I don't think it'd be a very suitable modification. The
rev-cache slices are meant to act almost like topo-relation pack
files: new slices are simply new files, seperate slice files can be
fused ("repacked") into a larger one, the index is a (recreatable)
single file associating file (positions) with objects. The format was
geared to reducing potential cache/data loss and preventing overly
large cache slices.
>> Hmpf.
>>
>> We got rid of the last Python script in Git a long time ago, but now two
>> different patch series try to sneak that dependency (at least for testing)
>> back in.
>>
>> That's all the worse because we cannot use Python in msysGit, and Windows
>> should be a platform benefitting dramatically from your work.
>
> In fact, the test the script performs could be easily rephrased with
> "sort", "uniq" and "comm".
> OTOH: If the walker is supposed to return the exact same orderd list of
> commits you can just use test_cmp.
The language that script is written in isn't important. I originally
wrote it in python because I wanted something quick and wasn't much of
a sh guru (sorry :-/ ). As Micheal said I've no doubt it can easily
be converted to shell script -- in fact, I'll try to get a shell
version working today.
- Nick
--
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