From: Erik Faye-Lund Date: Tue, 04 Oct 2011 07:40:22 GMT Subject: Re: [PATCH/RFC] remote: support --all for the prune-subcommand Message-ID: In-Reply-To: On Tue, Oct 4, 2011 at 9:18 AM, Erik Faye-Lund wrote: > On Tue, Oct 4, 2011 at 9:13 AM, Jeff King wrote: >> On Tue, Oct 04, 2011 at 09:10:40AM +0200, Erik Faye-Lund wrote: >> >>> >  git fetch --all --prune >>> > >>> I wasn't aware that fetch could prune, but yeah, that seems much >>> better to me. Perhaps a mention of this in the "git remote prune" >>> documentation could steer other users in the right direction? >> >> Yeah, that makes sense. >> >> There is one slight difference: I think "git remote prune" will _just_ >> prune, and not fetch into existing refs at all. I'm not sure exactly >> why you would want that, though. > > Hmm, you might want to do that on, say, a mobile network to save > bandwidth; i.e throw away the stale branches, but not yet update the > non-stale ones because downloading the objects might take a long time > (and/or be expensive). > > So with that in mind, I actually think my patch makes sense in some > cases, but it certainly is less useful that I originally though ;) Strike that part; I hadn't had my morning coffee yet. It might make sense to have similar _functionality_, but having this as a flag to "git fetch" instead of "git remote prune" strikes me as the only sane approach. In fact, I'm not sure I understand why we simply do not always prune by default. My guess would be backward compatibility, but this strikes me as one of these things where we should introduce a config variable (there's already one for git-gui: gui.pruneduringfetch), add a warning if unset, and flip the default at some future major release. After all, a remote branch isn't the user's branch - it's a cache/mirror some other user's branch. If a user wants to keep another user's branch, surely the most sane thing would be to make a local branch of it?