Re: What's in git.git (stable)

Shawn Pearce <spearce@spearce.org> writes:

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.