Re: Feature request: fetch --prune by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Johnson <computerdruid@xxxxxxxxx> writes:

> On Thu, Jul 19, 2012 at 7:55 AM, Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]