Johannes Sixt <j6t@xxxxxxxx> writes: > I am suggesting that +refspec would *not* override the match/mismatch > safety, but --force would. OK. I earlier did not read from your message that you wanted to change "+refspec" to mean "allow non-ff push", so the two entries in your table: > ff noff ff noff > match match mismatch mismatch > > --lockref +refspec ok ok denied denied > --lockref refspec ok denied denied denied did not make sense to me. If you are making "+refspec" to mean "--allow-no-ff refspec", then above is at least internally consistent. >> Let's look at noff/match case. That is the only interesting one. >> >> This should fail: >> >> git push topic >> >> due to no-ff. > > Yes. > >> Your table above makes this fail: >> >> git push --lockref topic >> >> and the user has to force it, > > Of course. > >> like this? >> >> git push --lockref --force topic ;# or alternatively >> git push --lockref +topic >> >> Why is it even necessary? > Because it is no-ff. How do you achieve the push today (without > --lockref)? You use one of these two options. It does not change with > --lockref. But by going that route, you are making --lockref _less_ useful, no? "git push topic" in no-ff/match case fails as it should. The whole purpose of "--lockref" is to make this case easier and safer than the today's system, where the anything-goes "--force" is the only way to make this push. We want to give a user who - rebased the topic, and - knows where the topic at the remote should be a way to say "I know I am pushing a no-ff, and I want to make sure the current value is this" in order to avoid losing somebody else's work queued on top of the topic at the remote while he was rebasing. You _CAN_ introduce a new --allow-no-ff at the same time and fail a no-ff/match push: git push --lockref topic and then allow it back with: git push --lockref --allow-no-ff topic git push --lockref +topic ;# +topic is now --allow-no-ff topic but why _SHOULD_ we? As soon as the user _says_ --lockref, the user is telling us he is pushing a no-ff. If that is not the case, the user can push without --lockref in the first place. The only potential thing you are gaining with such a change is that you are allowing people to say "this will fast-forward _and_ the I know the current value; if either of these two assumptions is violated, please fail this push". If "--lockref" automatically implies "--allow-no-ff" (the design in the reposted patch), you cannot express that combination. But once you use "--lockref" in such a situation , for the push to succeed, you know that the push replaces not just _any_ ancestor of what you are pushing, but replaces the exact current value. So I do not think your implicit introduction of --allow-no-ff via redefining the semantics of the plus prefix is not adding much value (if any), while making the common case less easy to use. > No; --lockref only adds the check that the destination is at the > expected revision, but does *NOT* override the no-ff check. You _could_ do it in that way, but that is less useful. -- 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