Steffen Prohaska <prohaska@zib.de> writes:

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

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

quoted text
> - 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html