On Tue, Dec 13, 2011 at 03:35:13PM -0800, Junio C Hamano wrote: > Teach a new "--ignore-stale" option to "git push" which tells it not to > push stale refs (i.e. the commit that would have been pushed without the > option is an ancestor of the commit that is at the destination). With this, > a lazy workflow could be like this: > > $ git clone <<origin>> > $ git checkout -b topic1 origin/topic1 > $ work work work > $ git push origin : > $ git checkout -b topic2 origin/topic2 > $ work work work > $ git push --ignore-stale origin : > > and the second push does not have to worry about other people working on > topic1 and updating it in the central repository while you haven't touched > the corresponding local branch at all. Unless the action of the people in the central repo was to rewind history, in which case you are overwriting their work. Probably unlikely, though. But I still see this as solving the wrong problem, and encouraging a dangerous workflow. Why are you using ":" to push matching branches if you don't want to push topic1? I think a much more likely scenario is: $ git clone <<origin>> $ git checkout -b topic1 origin/topic1 $ work work work $ : hmm, it's not ready yet $ git checkout -b topic2 origin/topic2 $ work work work $ : looking good, let's ship it! $ git push ;# we default to matching! I.e., the user is not actually intending to push all matching branches, but does so accidentally because "matching" is the default. And they have accidentally just pushed non-ready work to topic1, which would happen even with --ignore-stale. IOW, I am not convinced that people are actually consciously choosing the workflow you outlined above, and are instead interested in --ignore-stale as a convenient way of guessing which branches should be pushed during a matching push. But it's only a guess, and as I showed above, it can still cause problems. I think the right solution is to switch the default away from matching, which is the root cause of the confusion. -Peff -- 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