Re: Feature request: fetch --prune by default

[Dan Johnson <computerdruid@gmail.com>]

On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
<alexey.muranov@gmail.com> wrote:
> On 19 Jul 2012, at 13:55, Jeff King wrote:
>
>> I agree it would be much less confusing. However, one downside is that
>> we do not keep reflogs on deleted branches (and nor did the commits in
>> remote branches necessarily make it into the HEAD reflog). That makes
>> "git fetch" a potentially destructive operation (you irrevocably lose
>> the notion of which remote branches pointed where before the fetch, and
>> you open up new commits to immediate pruning by "gc --auto".
>
> If i understand correctly, existence of a reflog entry will not stop "gc" from removing a commit, will it?
> In this case, if a remote branch was rebased or reset, commits can be lost anyway, right?
From the git-gc man page:
git gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current
set of branches and tags, but also objects referenced by the index,
remote-tracking branches, refs saved by git filter-branch in
refs/original/, or reflogs (which may reference commits in branches
that were later amended or rewound).

So yes, a reflog entry does stop gc from removing objects, including
commits. It will expire old reflog entries (90 days by default)
though, so it's not like they will stay around forever.
-- 
-Dan