From: Oswald Buddenhagen <ossi@kde•org>
To: git@vger•kernel.org
Subject: Re: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?
Date: Mon, 27 Aug 2012 22:39:23 +0000 (UTC) [thread overview]
Message-ID: <loom.20120827T233125-780@post.gmane.org> (raw)
In-Reply-To: 7vmx2a3pif.fsf@alter.siamese.dyndns.org
hi,
Junio C Hamano <gitster <at> pobox.com> writes:
> The "alternates" mechanism [...]
sorry for the somewhat late response - i found this thread only now.
at qt-project.org we have a somewhat peculiar setup: we have the qt4 repository,
and a bunch of qt5 repositories which resulted from a split. qt5 is under active
development, but qt4 is still maintained. that means that we need to cherry-pick
between those repositories quite a lot. for an optimal cherry-picking experience
one needs three-way-merging, which means we need shared object stores. which is
where the problems start:
my first approach was just a common objects/ directory with all repositories
symlinking into it. problems:
- the object store can never be garbage-collected. with a lot of heavy rebasing
and temporarily added remotes, it gets messy after a while.
- there is a constant risk of destroying the object store by inadvertently
running git gc - which is particularly likely with git-gui, as it seems to be
retarded enough to ignore the auto-gc setting.
so the second approach is the "bare aggregator repo" which adds all other repos
as remotes, and the other repos link back via alternates. problems:
- to actually share objects, one always needs to push to the aggregator
- tags having a shared namespace doesn't actually work, because the repos have
the same tags on different commits (they are independent repos, after all)
- one still cannot safely garbage-collect the aggregator, as the refs don't
include the stashes and the index, so rebasing may invalidate these more
transient objects.
i would re-propose hallvard's "volatile" alternates (at least i think that's
what he was talking about two weeks ago): they can be used to obtain objects,
but every object which is in any way referenced from the current clone must be
available locally (or from a "regular" alternate). that means that diffing, etc.
would get objects only temporarily, while cherry-picking would actually copy
(some of) the objects. this would make it possible to "cross-link" repositories,
safely and without any "3rd parties".
thoughts?
regards
next prev parent reply other threads:[~2012-08-27 22:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 4:56 Bringing a bit more sanity to $GIT_DIR/objects/info/alternates? Junio C Hamano
2012-08-05 9:38 ` Michael Haggerty
2012-08-05 19:01 ` Junio C Hamano
2012-08-07 6:16 ` Jeff King
2012-08-06 21:55 ` Junio C Hamano
2012-08-08 1:42 ` Sascha Cunz
2012-08-11 9:35 ` Hallvard Breien Furuseth
2012-08-27 22:39 ` Oswald Buddenhagen [this message]
2012-08-28 19:19 ` GC of alternate object store (was: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?) Hallvard Breien Furuseth
2012-08-29 7:42 ` Oswald Buddenhagen
2012-08-29 15:52 ` GC of alternate object store Junio C Hamano
2012-08-30 9:53 ` Oswald Buddenhagen
2012-08-30 16:03 ` Junio C Hamano
2012-08-31 16:26 ` Oswald Buddenhagen
2012-08-31 19:18 ` Dan Johnson
2012-08-31 19:45 ` Junio C Hamano
2012-09-01 4:25 ` [PATCH] fetch --all: pass --tags/--no-tags through to each remote Dan Johnson
2012-09-01 11:22 ` Jeff King
2012-09-01 11:25 ` [PATCH 1/2] argv-array: add pop function Jeff King
2012-09-01 11:27 ` [PATCH 2/2] fetch: use argv_array instead of hand-building arrays Jeff King
2012-09-01 14:34 ` Jens Lehmann
2012-09-01 15:27 ` [PATCH] submodule: " Jens Lehmann
2012-09-01 11:32 ` [PATCH] fetch --all: pass --tags/--no-tags through to each remote Jeff King
2012-09-01 11:34 ` [PATCH 3/2] argv-array: fix bogus cast when freeing array Jeff King
2012-09-05 21:22 ` [PATCHv2] fetch --all: pass --tags/--no-tags through to each remote Dan Johnson
2012-09-07 17:07 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20120827T233125-780@post.gmane.org \
--to=ossi@kde$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox