Hi, On Mon, Aug 27, 2007 at 10:35:01AM CEST, Johannes Schindelin wrote: > On Mon, 27 Aug 2007, Petr Baudis wrote: > > > So now I wonder, what is the thing you miss most there? > > I wonder if this is repo.or.cz specific, but we recently had a problem > where the blobs of a project went away, and the forked project still > relied on them. Any ideas how to solve that issue? I actually *don't* want any objects to go ever away from a project. I just have no idea how to prevent it but still have some sane packing behaviour. I've been already thinking about this few years ago and even ended up with some patches in progress, but never finished them... (What I've found in my IRC logs:) 22:03 < pasky> I do run git repack -a -d but as far as I understand, that should be fine 22:03 < gitster> Huh? "repack -a -d" within git.git? 22:04 < gitster> What happens if an object only on 'pu' was already packed (you run prune-packed, don't you?), pu is rewound/rebased, and then you run "repack -a -d" again? 22:04 < gitster> And that object was borrowed by one of the forks? 22:05 < pasky> gitster: according to git-repack documentation no objects should be removed 22:05 < pasky> gitster: only redundant ones 22:05 < pasky> maybe the documentation is using some obscure definition of "redundant" I'm not familiar with 22:05 < gitster> redundant within that repository. In short, my worry comes from the fact that I do not know what you are doing to ensure that reachability extends to forks. 22:06 < pasky> gitster: I'm relying on git to ensure it for me 22:06 < pasky> gitster: if I can't do that, something is seriously badly broken 22:07 < pasky> gitster: well "redundant" means duplicate 22:07 < pasky> gitster: does "unreachable" mean "duplicate"? 22:09 < pasky> in short, dropping unreachable objects in the process of git-repack -a -d is absolutely ludicruous, especially the way git-repack -a -d is documented now 22:22 < pasky> gitster: I'd still like to know if git-repack -a -d can remove unreachable objects too, whether it should, if it's a bug/feature and why is it not documented... 22:49 < gitster> documentation fixes probably is needed but we have warned about pruning/repacking alternates for a long time. 22:50 * gitster was away for lunch. 22:51 < pasky> gitster: where is any warning about repacking vs alternates in the documentation? 22:51 < gitster> I suspect you are being dense on purpose -- I meant list archives. 22:53 < gitster> I agree that we would need documentation updates to help new people, but I at the same time think *you* know why unreachable objects will not be included in new pack upon "-a -d" already. 22:53 < pasky> gitster: in reality I haven't seem almost any git internals in 0.5 year and forgot a lot of stuff 22:54 < pasky> but I can guess :) 22:54 < pasky> still I realy heavily on documentation Looking at it now, it should work to just extend git-repack to pass some arguments directly to git-pack-objects and extend the duct tape to set GIT_ALTERNATE_OBJECT_DATABASE to object databases of all the forks (forks of forks, ...) and pass all the forked refs to git-pack-objects. Duh. Can anyone think of some more elegant solution? -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber - 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