On Thu, Sep 2, 2010 at 6:31 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Thu, 2 Sep 2010, A Large Angry SCM wrote: > >> On 09/02/2010 12:41 PM, Nicolas Pitre wrote: >> >> > For example, right now you already can't rely on having the exact same >> > pack output even on the same machine using the same arguments and the >> > same inputs simply by using threads. As soon as you're using more than >> > one thread (most people do these days) then your pack output becomes non >> > deterministic. >> >> Finally, the real pack expert weighs in! > > BTW I just have a little time to quickly scan through my git mailing > list backlog these days, and stumbled on this by luck. So if people > want my opinion on such matters it is safer to CC me directly. appreciated nicolas. will keep it short. ish :) * based on what you kindly mentioned about "git repack -f", would a (well-written!) patch to git pack-objects to add a "--single-thread-only" option be acceptable? * would you, or anyone else with enough knowledge of how this stuff reaallly works, be willing to put some low-priority back-of-mind thought into how to create a "canonical" pack format - one that can be enabled with a command-line-option? the reason i ask is because if i even attempted such a task, i'd die of laughing (probably manically) if it was ever accepted. i'd rather live :) questions (not necessarily for nicolas) - can anyone think of any good reasons _other_ than for multiple file-sharing to have a "canonical" pack-object? off the top of my head i can think of one: rsync if the transfer is interrupted. if the pack-objects are large - and not guaranteed to be the same - then an interrupted rsync transfer would be a bit of a waste of bandwidth. however if the pack-object could always be made the same, the partial transfer could carry on. musing a bit further... mmm... i supooose the same thing applies equally to http and ftp. it's a bit lame, i know: can anyone think of any better reasons? l. -- 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