On Tue, Oct 4, 2011 at 9:18 AM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Tue, Oct 4, 2011 at 9:13 AM, Jeff King <peff@xxxxxxxx> 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? -- 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