Jonathan Nieder <jrnieder@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html