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.

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

Reply via email to