Stefan Beller <sbel...@google.com> writes:
> > What's the value of this test? Isn't it a non-fast-forward check
> > you already tested in the previous one?
>
> I messed up there. Originally I wanted to test the 2 different
> stages of rejection. A non-fast-forward check is done locally and
> we don't even try pushing. But I also want to test if we locally
> thing all is good, but the server refuses a ref to update.
It is tricky to arrange a test to fail a fast-forward check on the
receiver side, because the local test is done by reading from the
other side, not relying on your remote tracking branches. The usual
flow is:
pusher says to the receiver "I want to push"
receiver says to the pusher "Here are the tips of my refs"
pusher thinks: "Ah, I was about to update their master branch
with this commit, but what they have is (1) not
known to me so by definition I cannot fast-forward,
or (2) known to me and I can definitely tell I am
not fast-forwarding it, so I'd locally fail this
push".
You need to invent a way to successfully race with an ongoing push.
After receiver gives the tips of its refs (all of which are
ancestors of what is going to be pushed) but before the pusher
finishes the "thinking" above, you would somehow update the refs at
the receiver so that the push will not fast-forward.
Such a raced flow would look like:
pusher says to the receiver "I want to push"
receiver says to the pusher "Here are the tips of my refs"
pusher thinks: "OK, everything I'll send will fast-forward"
pusher thinks: "Let's start generating a packfile"
you intervene and update receiver's 'master' at this point.
pusher send a pack and tells the receiver "I want to update your
master from OLD to NEW".
receiver thinks: "Huh, that OLD is not where my 'master' is"
recevier says to the pusher "No fast-forward".
But I do not think it is practical to run such a test.
Rejecting on the receiver's end using pre-receive or update hook
should be testable and should be tested.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
