On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote: > J. Bruce Fields wrote: >> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote: >>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote: >>> >>>>> I want git pull to work like git push. >>>> That strikes me as a less complete solution, since it only helps in the >>>> case where the other branches all happen to be unmodified locally (hence >>>> can be fast-forwarded). In other cases the "git push" will still emit a >>>> spurious error. >>> Well, but then there's something you should really think >>> about. >> Perhaps, but not necessarily; you may have some branches with local >> changes that you're content to leave unpushed (and un-updated). > > Sure, but that won't change. The only thing I'm proposing is that > local copies of remote branches are automatically fast-forwarded > on every pull, but only if > > * the branch has no modifications what so ever > * the branch is set up to auto-merge with the particular branch > fetched from the particular remote > > I really don't see any downsides what so ever with this. Those > of you who do, please enlighten me. The downsides are that it makes the behavior of pull slightly more complicated, and that it changes long-established default behavior of a major subcommand. (Those aren't huge disadvantages, but they are disadvantages.) > >> - the user has one or more unmodified copies of remote branches >> lying around, and > > Extremely common case for a large group of users. OK, but that was one part of a four-"and" clause. I don't see any absolute clincher here, but on balance I think the disadvantages win out. --b. - 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
