Jeff King <peff@xxxxxxxx> 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).
--
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
