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

Re: [PATCH] refs: implement reference transaction hooks

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Jun 7, 2020, 20:12 UTC
Message-ID
<20200607201233.GB8232@szeder.dev>
In-Reply-To
<20200603112604.GA25644@tanuki.pks.im>
On Wed, Jun 03, 2020 at 01:26:04PM +0200, Patrick Steinhardt wrote:
Show 54 quoted lines
> On Tue, Jun 02, 2020 at 10:47:55AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > The above scenario is the motivation for a set of three new hooks that
> > > reach directly into Git's reference transaction. Each of the following
> > > new hooks (currently) doesn't accept any parameters and receives the set
> > > of queued reference updates via stdin:
> > 
> > Do we have something (e.g. performance measurement) to convince
> > ourselves that this won't incur unacceptable levels of overhead in
> > null cases where there is no hook installed in the repository?
> 
> Not yet, but I'll try to come up with a benchmark in the next iteration.
> I guess the best way to test is to directly exercise git-update-refs, as
> it's nearly a direct wrapper around reference transactions.
> 
> > > +	proc.in = -1;
> > > +	proc.stdout_to_stderr = 1;
> > > +	proc.trace2_hook_name = hook_name;
> > > +
> > > +	code = start_command(&proc);
> > > +	if (code)
> > > +		return code;
> > > +
> > > +	sigchain_push(SIGPIPE, SIG_IGN);
> > > +
> > > +	for (i = 0; i < transaction->nr; i++) {
> > > +		struct ref_update *update = transaction->updates[i];
> > > +
> > > +		strbuf_reset(&buf);
> > > +		strbuf_addf(&buf, "%s %s %s\n",
> > > +			    oid_to_hex(&update->old_oid),
> > > +			    oid_to_hex(&update->new_oid),
> > > +			    update->refname);
> > > +
> > > +		if (write_in_full(proc.in, buf.buf, buf.len) < 0)
> > > +			break;
> > 
> > We leave the loop early when we detect a write failure here...
> > 
> > > +	}
> > > +
> > > +	close(proc.in);
> > > +	sigchain_pop(SIGPIPE);
> > > +
> > > +	strbuf_release(&buf);
> > > +	return finish_command(&proc);
> > 
> > ... but the caller does not get notified.  Intended?
> 
> This is semi-intended. In case the hook doesn't fully consume stdin and
> exits early, writing to its stdin would fail as we ignore SIGPIPE. We
> don't want to force the hook to care about consuming all of stdin,
> though.

Why? How could the prepared hook properly initialize the voting mechanism for the transaction without reading all the refs to be updated?

> We could improve error handling here by ignoring EPIPE, but making every
> other write error fatal. If there's any other abnormal error condition
> then we certainly don't want the hook to act on incomplete data and
> pretend everything's fine.

As I read v2 of this patch, a prepared hook can exit(0) early without reading all the refs to be updated, cause EPIPE in the git process invoking the hook, and that process would interpret that as success. I haven't though it through how such a voting mechanism would work, but I have a gut feeling that this can't be good.

Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 4 of 26 in “refs: implement reference transaction hooks”
  1. refs: implement reference transaction hooksPatrick Steinhardt, Jun 2, 2020
  2. Junio C HamanoJun 2, 2020
  3. Patrick SteinhardtJun 3, 2020
  4. SZEDER GáborJun 7, 2020
  5. Patrick SteinhardtJun 8, 2020
  6. SZEDER GáborJun 2, 2020
  7. Patrick SteinhardtJun 3, 2020
  8. refs: implement reference transaction hookPatrick Steinhardt, Jun 3, 2020
  9. Taylor BlauJun 3, 2020
  10. Patrick SteinhardtJun 4, 2020
  11. Taylor BlauJun 15, 2020
  12. Patrick SteinhardtJun 16, 2020
  13. Han-Wen NienhuysJun 3, 2020
  14. Junio C HamanoJun 3, 2020
  15. refs: implement reference transaction hookPatrick Steinhardt, Jun 18, 2020
  16. Junio C HamanoJun 18, 2020
  17. refs: implement reference transaction hookPatrick Steinhardt, Jun 19, 2020
  18. Jeff KingOct 23, 2020
  19. Junio C HamanoOct 23, 2020
  20. Taylor BlauOct 23, 2020
  21. Taylor BlauOct 23, 2020
  22. Patrick SteinhardtOct 26, 2020
  23. Taylor BlauOct 26, 2020
  24. Jeff KingOct 27, 2020
  25. Patrick SteinhardtOct 28, 2020
  26. Taylor BlauOct 23, 2020

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.