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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 31, 2007, 08:45 UTC
Message-ID: <7v8x5jiseh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <F5F68690-68A3-4AFC-A79C-FF02910F0359@zib.de>

Steffen Prohaska <prohaska@zib.de> writes:

Show 6 quoted lines

> Would it be acceptable if the error was less severe in the
> case of local being a strict subset of remote?
> Daniel proposed
> "%s: nothing to push to %s, but you are not up-to-date and
> may want to pull"
> It would still be an error, but a less severe one.

I am not convinced there is one true total order of "error severity" that applies uniformly across different workflows, so I would not immediately agree if you are suggesting to introduce "severity levels". But it certainly makes a lot of sense to be able to _differentiate_ kinds of errors, and to have the calling scripts and the push command itself react to them.

What are the possible error conditions?

 1. Error on the sending side.  The ref parameters given to
    git-push were bogus, or they were good commits but they were
    not fully connected to the commits the other side has
    (i.e. local repository corruption).  pack-objects will abort
    and no remote (nor local tracking ref that tracks what we
    pushed to the remote) would be updated.  This should be
    "most severe" in _any_ workflow, so I do not mind calling
    this "fatal".

 2. Push to a ref does fast forward, but the update hook on the
    remote side declines.  The ref on the remote nor the
    corresponding local tracking ref would not be updated, and
    the command would fail.

For all the other classes of errors, the ref on the remote nor the corresponding local tracking ref would not be updated, and by default, an error on any ref causes the command to error out. For each of these classes of errors, we _could_ have an option to let you tell the command not to error out because of it.

 3. Push to a ref does not fast forward and --force is not
    given, but you can prove the remote is strict subset of
    local (what your 10/10 wants to do).

 4. Same as #3 but you cannot prove the remote is strict subset
    of local.

Any other classes?

It might be a good idea to generalize 3 & 4, by the way. The remote being a strict descendant of what is being pushed might be something you happened to want today, but somebody else may come up with a different rule tomorrow. So,

 3'. Push to a ref does not fast forward and --force is not
     given, but there is a configuration (would this be per
     remote?, per remote branch?, or per local branch?) that
     tells git-push to call a hook on the local side that takes
     <ref being pushed, ref on the remote> as its parameter.
     The result from the hook does not change the fact that this
     is still an error, but it can instruct git-push not to
     error out due to this condition.

In some other workflows, it might make sense to maybe even making 2. not to cause the error from git-push. I dunno.

> It could also be a good idea to teach git push transactional
> behaviour.

That is certainly true. I am not sure about other transports, but it should be a relatively straightforward protocol extension for the git native transport.

> - git push can be configuration to push only the current
>   branch, as outlined below. This would certainly work. What
>   I do not like is that you first need to do some configuration
>   before you get a safe working environment.

I would not doubt it would be safer for _your_ workflow, but you should consider the risk of making things more cumbersome for workflows of others by enforcing that policy.

In other words, don't change anything unless you have a very good reason to convince everybody else that it is universally a good change to the default.