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

Re: Push and remote refs

From
Jeff King <peff@peff.net>
Date
Nov 5, 2006, 21:06 UTC
Message-ID
<20061105210607.GA28320@coredump.intra.peff.net>
In-Reply-To
<7vhcxdu1ln.fsf@assigned-by-dhcp.cox.net>
On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:
Show 7 quoted lines
> I recall discussing this exact behaviour with Pasky when he
> added it to Cogito.  I think we concluded that it is a very
> sensible thing to pretend we fetched immediately after we
> successfully pushed and got the same thing back, and there is no
> risk of data loss or user confusion, as long as we catch failure
> from the push and refrain from doing this update, which Cogito
> did implement correctly when we discussed this.

Is it possible for hooks on the receiving side to change the tip commit in some way? For example, the 'update' hook could do some markup on the commit message or contents, creating a new commit and using it instead of the pushed one; in this case, the sending side ends up with an incorrect (and unrelated) SHA1. Is this simply too insane to worry about?

Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 5 in “Push and remote refs”
  1. Daniel BarkalowNov 5, 2006
  2. Junio C HamanoNov 5, 2006
  3. Jeff KingNov 5, 2006
  4. Junio C HamanoNov 5, 2006
  5. Jeff KingNov 5, 2006

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.