On Tue, Dec 16, 2014 at 12:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> 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. > Yes, that was my understanding as well. I just messed up mentally. Now that the update hook test is in place, we do have tests from the local and the remote side rejecting, so it should be fine now. -- 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