Re: [PATCH v4 00/32] Lockfile correctness and refactoring
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Sep 12, 2014, 11:13 UTC
- Message-ID
- <5412D54C.5030602@alum.mit.edu>
- In-Reply-To
- <xmqq7g1bifm0.fsf@gitster.dls.corp.google.com>
On 09/10/2014 06:51 PM, Junio C Hamano wrote:
Show 10 quoted lines
> [...] > I am wondering if it makes sense to maintain a single ref that > reaches all the commits in this shared object store repository, > instead of keeping these millions of refs. When you need to make > more objects kept and reachable, create an octopus with the current > tip and tips of all these refs that causes you to wish making these > "more objects kept and reachable". Obviously that won't work well > if the reason why your current scheme uses refs is because you > adjust individual refs to prune some objects---hence the first > question in this message.
This is an interesting idea.
I wouldn't trust git to handle efficiently commits with thousands of parents, but it would be easy to knit a huge number of tips together using multiple layers of, say, 16-parent octopus merges.
Michael
-- Michael Haggerty mhagger@alum.mit.edu