Steffen Prohaska <prohaska@xxxxxx> writes:
> 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.
-
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
