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

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

Reply via email to