Dan Johnson <computerdr...@gmail.com> writes: > On Thu, Jul 19, 2012 at 7:55 AM, Jeff King <p...@peff.net> wrote: > ... >> So I think it would be a lot more palatable if we kept reflogs on >> deleted branches. That, in turn, has a few open issues, such as how to >> manage namespace conflicts (e.g., the fact that a deleted "foo" branch >> can conflict with a new "foo/bar" branch). > > In the meantime, would it make sense to introduce a configuration > variable to request this behavior? > > If so, should it be global? > > fetch.prune = always > > or per-remote? > > remote.<name>.prune = always > > The global option seems to be more in line with what Alexey is looking > for, but the per-remote one is similar to the tagopt option, which is > a similar idea. > > Of course, this might be just a waste of time to introduce a feature > no one would use, in which case we obviously should not introduce such > options.
I was reading through the backlog today and noticed that this topic veered into the "reflog graveyard" tangent. I wasn't involved in the main topic, but I think having both configuration variables, remote.<remote>.prune taking precedence over fetch.prune, as long as we make sure "fetch --no-prune" will override any configured default, is not a bad thing per-se. As long as the users who elect to use this feature are aware of the pruning of the refs and logs, that is, but "branch [-r] -d" has been the way to lose both the branch and its log for a long time, so I do not see a big issue there, either. The log graveyard is an independently interesting idea, which I may ping separately, but I consider it pretty much orthogonal to this particular topic. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
