Re: [PATCH 7/7] push: document --lockref

Johannes Sixt [off-list ref] 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.

quoted

Let's look at noff/match case.  That is the only interesting one.

This should fail:

	git push topic

due to no-ff.

Yes.

quoted

Your table above makes this fail:

        git push --lockref topic

and the user has to force it,

Of course.

quoted

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.

Am 13.07.2013 20:14, schrieb Junio C Hamano:

Johannes Sixt [off-list ref] writes:

quoted

quoted

Your table above makes this fail:

        git push --lockref topic

and the user has to force it,

Of course.

quoted

like this?

	git push --lockref --force topic ;# or alternatively
        git push --lockref +topic

Why is it even necessary?

quoted

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.

quoted

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.

All you have been saying is that you find your

   git push --lockref there topic

is more useful than my

   git push --lockref there +topic

You are trading crystal clear semantics to save users ONE character to
type. IMO, it's a bad deal.

The crystal clear semantics would be:

 - to override no-ff safety, use +refspec;

 - to override "mismatch" safety, do not use --lockref/use --no-lockref;

 - do not use --force unless you know the consequences.

I actually think that by implying allow-no-ff in --lockref, you are
hurting users who have configured a push refspec without a + prefix:
They suddenly do not get the push denied when it is not a fast-forward
anymore. For example, when you have

    [remote "ko"]
        push = master
        push = +pu

and you accidentally rewound master before the point that is already
published, then

   git push --lockref ko

will happily push the rewound master.

-- Hannes