git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Interleaved remote branch update problems

From
MFMartin Fick <mfick@codeaurora.org>
Date
Apr 6, 2012, 05:32 UTC
Message-ID
<9a97881f-a49e-47b2-9c14-b067bc7a525c@email.android.com>
In-Reply-To
<20120406003710.GC14224@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
Show 11 quoted lines
>On Thu, Apr 05, 2012 at 03:49:14PM -0600, Martin Fick wrote:
>
>> I have noticed that git push --force does not reliably force 
>> a push to remote branches.  In particular, it will not 
>> update a remote branch if that branch has been updated since 
>> the beginning of the push.  Is this normal, is this 
>> expected?
>
>Yes, that's expected. --force means "it's OK to push something that
> will rewind history", not "it's OK to clobber somebody else who is
> pushing at the same time".
But why is it ok to clobber somebody else right after they pushed, this seems like splitting hairs?  Why force me to wait to clobber?  Afterall, git goes through great pains to only lock a ref for the small duration of time when it is updated.  But this behavior means that it effectively is actually locked for the entire duration of a push except that it teases a client into thinking it is not locked until then end of a potential costly transfer.
And what about the fast forward case?  If client A is pushing change a and then client B starts pushing b which depends on a, why shouldn't B succeed as long as A succeeds first, even without the force flag?  But it does not work this way even with the force flag.
Show 10 quoted lines
> The determination for the former happens on the client
>side, and for the latter on the server side.
>
>If you want the latter, you would need a protocol extension, I think;
>I'm pretty sure the client doesn't transmit the force flag at all to
>the
>server (and I don't think this should be tied to the force flag
>automatically; they are two different cases, and you may be in a
>situation where it is safe to do the former but not necessarily the
>latter).
I think this use case distinction is irrelevant to users on a shared server unless you could somehow tell git to "only clobber the branch if it currently points to shax".  Which is sort of what git is pretending to do, but it isn't really since the user isn't specifying shax, it is determined when the push starts and is inherently subject to a race.  It's not like the user can safely determine what the remote branch points to before they update it to see if it is ok to clobber it.
Just a user's perspective...
-Martin
Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
Previous: Jeff KingNext: Jeff King
Message 3 of 4 in “Interleaved remote branch update problems”
  1. Martin FickApr 5, 2012
  2. Jeff KingApr 6, 2012
  3. Martin FickApr 6, 2012
  4. Jeff KingApr 6, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.