Michael Haggerty writes:
> On 06/01/2016 09:39 PM, Junio C Hamano wrote:
>> ...
> I think I would represent the logical store of a worktree repo as
> follows. First, ...
> ...
>> Up to this point, I am all for your "separate physical stores are
>> composited to give a logical view". I can see ho
On 06/01/2016 09:39 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I argue that the fundamental concept in terms of the implementation
>> should be the individual physical reference stores, and these should be
>> compounded together to form the logical reference collections and the
>>
Michael Haggerty writes:
> I argue that the fundamental concept in terms of the implementation
> should be the individual physical reference stores, and these should be
> compounded together to form the logical reference collections and the
> sets of reachability roots that are interesting at the
On 06/01/2016 05:15 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I think reference stores are going to need two distinct types of
>> reference iteration: one to iterate over the *logical* reference space
>> of a single repo or worktree, and one to find all *local* references
>> and/o
Michael Haggerty writes:
> I think reference stores are going to need two distinct types of
> reference iteration: one to iterate over the *logical* reference space
> of a single repo or worktree, and one to find all *local* references
> and/or reachability roots (e.g., when run within a linked r
On 06/01/2016 12:14 AM, Jeff King wrote:
> [...]
> Michael (cc'd) noted to me off-list recently that there may be some
> special cases there regarding reflogs in other worktrees (i.e., that we
> don't always include them for our reachability checks). I don't know the
> details, though.
That's corr
Am 01.06.2016 um 00:14 schrieb Jeff King:
> Right, we use the index for reachability checks (both in "prune", but
> also during a "repack -a", which uses the revision parser's
> '--indexed-objects" option). That obviously should handle per-worktree
> index files, but I don't know whether it current
On Tue, May 31, 2016 at 07:02:15PM +0700, Duy Nguyen wrote:
> On Tue, May 31, 2016 at 2:07 PM, Johannes Sixt wrote:
> > Earlier this year I had a largish merge going on in a separate worktree.
> > With a mix of staged resolutions and unmerged paths in the index, I ran 'git
> > gc' in the main wor
On Tue, May 31, 2016 at 2:07 PM, Johannes Sixt wrote:
> Earlier this year I had a largish merge going on in a separate worktree.
> With a mix of staged resolutions and unmerged paths in the index, I ran 'git
> gc' in the main worktree. This removed a lot of objects that were recorded
> in that sep
Earlier this year I had a largish merge going on in a separate worktree.
With a mix of staged resolutions and unmerged paths in the index, I ran
'git gc' in the main worktree. This removed a lot of objects that were
recorded in that separate worktree index. (I was able to recover them
because t
10 matches
Mail list logo
