On Tue, May 31, 2016 at 2:07 PM, Johannes Sixt <j6t@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html