Shawn Pearce <spearce@xxxxxxxxxxx> writes:
> Does anyone on the mailing list really have an objection to having
> reflogs on by default?
When you talk about potential breakage for existing users, you
should not be asking people on THIS list. You instead should
talk with or at least think about people on linux-kernel, x.org
and wine people, and possibly others. git is maturing, and we
cannot expect that most of the users are paying attention to
what is happening on this list anymore.
I 100% agree that it makes sense to have reflog enabled for a
repository with an associated worktree. I would say that we do
not even need it to be conditional on the configuration variable
for such a repository.
My answer to your question is:
kernel.org:/pub/scm/
I would REALLY be worried to have reflog enabled at a public
distribution point where the only ways the owners interact with
it daily are 'git push' and 'git pull'. As you mentioned, there
is one extra potential receive-pack failure, and in general it
is one more thing that can go wrong, and hard to notice breakage
because it is on the other side of the connection.
Worse yet, there is no easy way to garbage collect. Even in an
end-user repository with a worktree, the only way to garbage
collect older reflog entries is to edit the reflog files to
remove the top part.
Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
then enable it and otherwise honor the configuration variable,
without changing the default in the code (with your patch) nor
in the default configuration ("enable for new repositories" as I
suggested) might be a workable compromise.
-
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