Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

Michael Haggerty writes: > Fixing reachability via the index and detached HEADs feels relatively > important. > ... I agree with the order of importance above. But "relatively" is a very good keyword. Just like bisection refs, what is in the index and the commit detached

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

On 06/02/2016 11:53 AM, Duy Nguyen wrote: > (from patch 4/4 mail) > > On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty > wrote: >>> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect")); >>> + if (file_exists(path)) >>> + handle_one_reflog(path,

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

(from patch 4/4 mail) On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty wrote: >> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect")); >> + if (file_exists(path)) >> + handle_one_reflog(path, NULL, 0, ); >> + free(path); >> +} > >

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

Nguyễn Thái Ngọc Duy writes: > This series makes sure that objects referenced by all worktrees are > marked reachable so that we don't accidentally delete objects that are > being used. Previously per-worktree references in index, detached HEAD > or per-worktree reflogs come

Re: [PATCH 0/4] Fix prune/gc problem with multiple worktrees

On Wed, Jun 01, 2016 at 05:45:15PM +0700, Nguyễn Thái Ngọc Duy wrote: > This series makes sure that objects referenced by all worktrees are > marked reachable so that we don't accidentally delete objects that are > being used. Previously per-worktree references in index, detached HEAD > or

[PATCH 0/4] Fix prune/gc problem with multiple worktrees

This series makes sure that objects referenced by all worktrees are marked reachable so that we don't accidentally delete objects that are being used. Previously per-worktree references in index, detached HEAD or per-worktree reflogs come from current worktree only, not all worktrees. The series