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
