All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Git Mailing List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: git gc and worktrees
Date: Tue, 31 May 2016 19:02:15 +0700	[thread overview]
Message-ID: <CACsJy8BHU0YtgvjuefRPuMPLhvoOPLVMhR4YzH8=wVFeOie+Xw@mail.gmail.com> (raw)
In-Reply-To: <574D382A.8030809@kdbg.org>

On Tue, May 31, 2016 at 2:07 PM, Johannes Sixt <j6t@kdbg.org> 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 separate worktree index. (I was able to recover them because the
> content was still on disk.)
>
> Now I wanted to derive a test case that shows that breakage, but I am unable
> to. The objects recorded in a separate worktree index, but not committed,
> yet, are not pruned anymore.
>
> Have there been any fixes in this regard recently? Or does this look like
> something else going on?

Not sure. I vaguely recall Jeff touched this pruning issue once,
something about recent objects will not be pruned based on mtime. But
maybe some of those objects in the index are not so young, and because
I think we never check indexes in git-gc/git-prune, they have a chance
to be deleted.

No I'm wrong. mark_reachable_objects() which is used by git-prune,
does add objects from index and HEAD, which only covers those from
_current_ worktree. This should be fixed even if it is not the root
cause of your problem. I'll look into it.
-- 
Duy

  reply	other threads:[~2016-05-31 12:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31  7:07 git gc and worktrees Johannes Sixt
2016-05-31 12:02 ` Duy Nguyen [this message]
2016-05-31 22:14   ` Jeff King
2016-06-01  7:00     ` Johannes Sixt
2016-06-01  8:57     ` Michael Haggerty
2016-06-01 15:15       ` Junio C Hamano
2016-06-01 16:12         ` Michael Haggerty
2016-06-01 19:39           ` Junio C Hamano
2016-06-02  4:08             ` Michael Haggerty
2016-06-03 16:45               ` Junio C Hamano
2016-06-01 10:45 ` [PATCH 0/4] Fix prune/gc problem with multiple worktrees Nguyễn Thái Ngọc Duy
2016-06-01 10:45   ` [PATCH 1/4] revision.c: move read_cache() out of add_index_objects_to_pending() Nguyễn Thái Ngọc Duy
2016-06-01 10:45   ` [PATCH 2/4] reachable.c: mark reachable objects in index from all worktrees Nguyễn Thái Ngọc Duy
2016-06-01 18:13     ` Eric Sunshine
2016-06-02  9:35       ` Duy Nguyen
2016-06-01 18:57     ` David Turner
2016-06-02  9:37       ` Duy Nguyen
2016-06-01 10:45   ` [PATCH 3/4] reachable.c: mark reachable detached HEAD " Nguyễn Thái Ngọc Duy
2016-06-01 10:45   ` [PATCH 4/4] reachable.c: make reachable reflogs for all per-worktree reflogs Nguyễn Thái Ngọc Duy
2016-06-01 15:51     ` Michael Haggerty
2016-06-01 16:01   ` [PATCH 0/4] Fix prune/gc problem with multiple worktrees Jeff King
2016-06-01 16:06   ` Junio C Hamano
2016-06-02  9:53     ` Duy Nguyen
2016-06-02 11:26       ` Michael Haggerty
2016-06-02 17:44         ` 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='CACsJy8BHU0YtgvjuefRPuMPLhvoOPLVMhR4YzH8=wVFeOie+Xw@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.