On Tue, 30 Oct 2007, Junio C Hamano wrote: > Steffen Prohaska <prohaska@xxxxxx> writes: > > > git push now allows you pushing a couple of branches that have > > advanced, while ignoring all branches that have no local changes, > > but are lagging behind their matching remote refs. This is done > > without reporting errors. > > > > Thanks to Junio C. Hamano <gitster@xxxxxxxxx> for suggesting to > > report in the summary that refs have been ignored. > > I do not think this is a good idea at all. Furthermore, I never > suggested anything about summary. You are robbing the > information from the pusher which ones are pushed and which ones > are left behind. I think this case should be a warning rather than an error, though. It is certainly true that the user isn't intending to update those remote refs, because there is no local change to update them with. And it is also true that those local refs being stale is no impediment to updating the refs which are not stale, which is what the user does intend to do. I can't see a workflow which would be hurt by this change, because we know that, if the user follows the instructions and then tries the push again, it will have no effect. If the concern is robbing the user of information, we should simply provide the information, rather than interrupting the user's work to make them act on the information before completing the essentially independant operation they're attempting. In any case, it's misleading to suggest that the user "pull first", because we know that there would be no effect to pushing again after merging. In this case, it would be more accurate to suggest that the user "pull instead". Perhaps the message should be "%s: nothing to push to %s, but you are not up-to-date and may want to pull" -Daniel *This .sig left intentionally blank* - 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
