Jonathan Nieder <> writes:

>       (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".

> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to