On Oct 30, 2007, at 9:29 AM, 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.
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.
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
-
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
