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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 30, 2007, 10:15 UTC
Message-ID: <52171BF7-50E2-473E-A0BD-CB64D38FD502@zib.de>
In-Reply-To: <7vfxztm2dx.fsf@gitster.siamese.dyndns.org>

On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:

Show 12 quoted lines

> 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.

Yeah, sorry. You only asked if the summary does mention something; not suggesting it should do so.

> You are robbing the
> information from the pusher which ones are pushed and which ones
> are left behind.

Absolutely; because the branches left behind are not interesting. The remote already is ahead of the local branches. The local branches are just left were they are. They have no new information on them. Forcing an push would _rewind_ the remote without adding anything to it.

If you really intended to do a rewind you should have passed '--force' in the first place and my report would never be printed.

Show 6 quoted lines

> It simply is insane to make this strange rule 10/10 introduces
> the default behaviour.  It is too specific to a particular
> workflow (that is, working with a shared central repository,
> having many locally tracking branches that are not often used
> and become stale, and working on only things to completion
> between pushes).

I don't think its very strange behaviour if you see it in the light of what the user wants to achieve. We are talking about the case were only fast forward pushes are allowed. So, we only talk about a push that has the goal of adding new local changes to the remote. The user says "git push" and means push my new local changes to the remote.

Unfortunately, the remote may have advanced differently from the local branch, and the push must fail because someone needs to merge first. git push recommends to do a pull and retry, which is the right thing to do.

My strange rule 10/10 adds a check that verifies if the local side has something interesting to push. Only in this case a pull make sense. If you do not have something new, a pull will be a fast-forward, and just a waste of time.

In this light I think the current behaviour is insane, because it asks the user to spend time on things that do not add any value. No new commits, no new information, no need to merge, no need to push again, no need to report errors ...

> I think we could live with an optional behaviour, in addition to
> the current "matching refs" behaviour, that is "matching refs,
> ignoring strict ancestors", though, but I doubt it is worth the
> addition.

... just ignore strict ancestors by default.

	Steffen