Johannes Sixt <[email protected]> writes:
> We have three independent options that the user can choose in any
> combination:
>
> o --force given or not;
>
> o --lockref semantics enabled or not;
>
> o refspec with or without +;
>
> and these two orthogonal preconditions of the push
>
> o push is fast-forward or it is not ("ff", "noff");
>
> o the branch at the remote is at the expected rev or it is not
> ("match", "mismatch").
>
> Here is a table with the expected outcome. "ok" means that the push is
> allowed(*), "fail" means that the push is denied. (Four more lines with
> --force are omitted because they have "ok" in all spots.)
>
> ff noff ff noff
> match match mismatch mismatch
>
> --lockref +refspec ok ok denied denied
> --lockref refspec ok denied denied denied
I am confused with these. The latter is the most typical:
git fetch
git checkout topic
git rebase topic
git push --lockref topic
where we know it is "noff" already, and we just want to make sure
that nobody mucked with our remote while we are rebasing.
If nobody updated the remote, why should this push be denied? And in
order to make it succeed, you need to force with +refspec or --force,
but that would bypass match/mismatch safety, which makes the whole
"make sure the other end is unchanged" safety meaningless, no?
> +refspec ok ok ok ok
This is traditional --force.
> refspec ok denied ok denied
We are not asking for --lockref, so match/mismatch does not affect
the outcome.
> Notice that without --lockref semantics enabled, +refspec and refspec
> keep the current behavior.
But I do not think the above table with --lockref makes much sense.
Let's look at noff/match case. That is the only interesting one.
This should fail:
git push topic
due to no-ff.
Your table above makes this fail:
git push --lockref topic
and the user has to force it, like this?
git push --lockref --force topic ;# or alternatively
git push --lockref +topic
Why is it even necessary?
If you make
git push --lockref topic
succeed in noff/match case, everything makes more sense to me.
The --lockref option is merely a weaker form of --force but still a
way to override the noff check. If the user wants to keep noff
check, the user can simply choose not to use the option.
Of course, that form should fail if "mismatch". And then you can
force it,
git push --force [--lockref] topic
As "--force" is "anything goes", it does not matter if you give the
other option on the command line.
> (*) As we are talking only about the client-side of the push here, I'm
> saying "allowed" instead of "succeeds" because the server can have
> additional restrictions that can make the push fail.
Yes, you and I have known from the beginning that we are in
agreement on that, but it is a good idea to explicitly say so for
the sake of bystanders.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
