Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

[Daniel Barkalow <barkalow@iabervon.org>]

On Tue, 30 Oct 2007, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> 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@pobox.com> 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*