On Thu, Aug 16, 2012 at 04:22:54PM -0700, Junio C Hamano wrote: > > 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. Yeah, I think that is sensible. As long as the _default_ is not to prune, and people are making a conscious choice to prune, I don't see a problem at all. The log graveyard is orthogonal to the proposed option, but I think it would be a necessary step before flipping the default for that option to "true". -Peff -- 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