Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.

Jeff King [off-list ref] writes:

Does this seem like a good approach overall? Existing behavior should be
identical unless the config option is set, and with it set, I think it
should satisfy Pierre and posters from the original thread. If that is
sensible, which of the solutions for "no, I really want to force this
strict rewind" is the most palatable?

That "strict rewind" workaround alone made me so disgusted beyond words.

And then made me step back and think again.

If it is stale, it is stale.  A revert is just a different history that
did not have some things that already happened, while a fork has some
other things that did not happen in the original history on top of that.
They are the same thing -- alternate history that drops some things that
already happened.  It does not matter if you are strictly stale or if you
built a few (or hundreds of) commits on top of something that is stale.
You are losing history if you tried to push such a thing.

And if you do not want to trigger "what you are pushing is not up to
date", the solution is simple.  You do not push them.

I however think what Pierre wanted to do is different, and you do not have
to solve "force this strict rewind" problem to solve it.

What we need is (with a configuration option) to change the meaning of
"matching refs" from the current definition "branches with the same name
between here and there" to "branches with the same name between here and
there, but excluding the ones that do not fast forward (or strictly
behind)".  So if you have tons of stale branches you checked out but
haven't touched most of them, your "matching push" won't even try to push
what you haven't touched.

I do not think we would ever want to allow a configuration that disables
the exit status from push upon a push failure when somebody explicitly
says "git push $there $this" and $this is not non-fast-forward.  If you
asked $this to be pushed, and if $this cannot be pushed, we _should_ error
out.

So...

 (1) when you say "git push" to trigger the "matching refs" push, with the
     new configuration, you do not error out nor even try to push out
     things that do not fast forward.  Pretend that you did not even
     attempt to push them, and do not error out.  This may result in not
     pushing anything out, but that is what the people who have such a
     configuration is asking for.

     If you have configured which branches are pushed when you are on your
     current branch, and that branch --- most likely it is that current
     branch --- does not fast forward, it is your problem.

 (2) even with such a configuration, you can "git push $there $this" and
     "git push $there +$this" to explicitly ask refs to be pushed.  Such a
     push won't be interfered by the new configuration and correctly fail
     (or force).