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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2013, 04:10 UTC
Message-ID: <7v4nbwfooj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130714212800.GA11009@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 19 quoted lines

> 	(4) gitk @{u}@{1}..@{u}; # Is the change good?
>
> 	(5a) git pull --rebase; git push; # Yes, put my change on top of it
> 	(5b) git push --force; # No, my change is better!
>
> So far so good.  But what if yet another change is made upstream
> between step (3) and (5)?
>
> If following approach (5a), that's fine.  We notice the new
> intervening change and react accordingly, again.  There is a
> possibility of starvation, but no other harm done.
>
> In case (5b), it may be a serious problem.  I don't know about the
> intervening change until I read the "git push" output, and in the
> usual case I just won't notice.  The new lockref UI is meant to
> address this problem.  So in the new world order, in case (5b) it
> sounds like I should have instead used
>
> 	(5b') git push --allow-non-ff

t is clear you want to allow-no-ff in this case (otherwise the push will not go through), and that is what the "--force" option meant in the old world. The compare-and-swap safety is to help this case by letting you say

	git push --lockref

which is a weaker form of "--force". We ignore "fast-forward"-ness, like the current "--force" does, but replace it with another form of safety "we know replacing this old value with what we are pushing is OK---if somebody updated the ref in the meantime, then the push is not OK, so please fail".

Show 12 quoted lines

> Suppose I am writing a script that is meant to set the remote
> repository to a known state.  Other contributors are only using
> fast-forward updates so once my change goes in they will act
> appropriately.  I just need to get my ref update in, without being
> blocked by other ref updates.
>
> Then I will use
>
> 	(5c) git push --force
>
> which means not to use this new lockref trick that looks at my
> remote-tracking branch and instead to just force the ref update.

I am not sure I follow. Do other contributors update this remote repository? They are "only using fast-forward updates", so their updates may not lose anything we pushed, but with "--force", aren't you losing their work on top of yours?