Junio C Hamano wrote:
> Jonathan Nieder <jrnie...@gmail.com> writes:
>> 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?
Yep, I meant that when you really *do* want to force a push
regardless of what's on the remote end, the current --force behavior
is more useful than --lockref.
The example I used to introduce (5c) is too vague to be useful. A
more compelling example (to me, at least) is the one from later in
that message involving a relay, which does not involve other
contributors at all.
That is, suppose I maintain a mirror of the branches from
git://repo.or.cz/git.git by pushing regularly to a hosting service
where I do not have shell access. Since I can't fetch from the target
repository or push from the source, I instead fetch and then push from
a relay, like this:I might push like this:
git fetch upstream
git push --force origin refs/remotes/upstream/*:refs/heads/*
Or, in the same spirit, with a detached HEAD:
git fetch upstream refs/heads/*:refs/heads/*
git push --force origin :
The --force is to account for "pu" and "next" rewinding.
In this scenario, assuming I have exclusive access to the repository
and the push updates the remote-tracking branches, --lockref and
--force work equally well. The commands might run once every 6 hours
using a cronjob.
Now suppose my relay has some downtime. That's fine --- I can still
maintain the mirror by running the same commands on another machine.
But when the old relay comes back up, "push --lockref" will fail and
"pu" and "next" in my mirror are not updated any more.
That is why I said that --force is more appropriate than --lockref
for this application.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
