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

Re: [PATCH 1/3] t5318: demonstrate commit-graph generation v2 corruption

From
Taylor Blau <me@ttaylorr.com>
Date
Jul 16, 2022, 00:17 UTC
Message-ID
<YtIDsIVCJ8XgF1eJ@nand.local>
In-Reply-To
<xmqqo7xqx6wj.fsf@gitster.g>
On Fri, Jul 15, 2022 at 05:01:16PM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> Taylor Blau <me@ttaylorr.com> writes:
>
> > On Thu, Jul 14, 2022 at 11:15:42PM -0400, Derrick Stolee wrote:
> >> > +		# This commit will have a date at two seconds past the Epoch,
> >> > +		# and a (v1) generation number of 1, since it is a root commit.
> >> > +		#
> >> > +		# The offset will then be computed as 2-1, which will underflow
> >>
> >> I have verified that your test works, but this explanation is confusing me.
> >> "2 - 1" is 1, which does not underflow. There must be something else going
> >> on.
> >>
> >> Looking ahead, you describe the situation correctly in Patch 3 to show that
> >> we take "generation - date", so you really just need s/2-1/1-2/ here.
> >
> > Yes, absolutely. Thanks for catching it.
> >
> > Junio: you may want to s/2-1/1-2 in this patch's message, or I can send
> > you a replacement or reroll, whatever is easier.
>
> I've already done "rebase -i" to do so.
Thanks very much.
Show 11 quoted lines
> But for future reference, the easiest for me is if the author said,
> after saying "Thanks for catching it", "Will reroll after waiting
> for a bit to see if there are other comments".  That way, I only
> have to edit the latest draft of "What's cooking" report to mark the
> topic to be expecting a reroll (which will prevent me from merging
> the topic down to 'next' prematurely by mistake) and forget about
> it, until I actually see the updated set of patches.  It would be
> even easier if the updated set of patches said which topic it is
> meant to replace.  That way, I can trust other reviewers about the
> details of the change between iterations and play a patch monkey,
> when I am short of time.

Makes sense. I appreciate you clarifying it explicitly, I've wondered over the years what is easiest for you when fixing a trivial issue in a larger series.

I've tended to try and avoid resubmitting a whole series when there is just a typo hoping to avoid flooding the list with too many (mostly unchanged) messages. But that requires you to do more work to futz with the patches before they hit your tree, so I try not to do it too often.

In any case, I'll try to err more often on the side of resubmitting a series after acking the typo in the hopes it makes your life easier ;-).

Thanks, Taylor

Previous: Junio C HamanoNext: Taylor Blau
Message 6 of 12 in “commit-graph: fix corruption during generation v2 upgrade”
  1. 0/3 commit-graph: fix corruption during generation v2 upgradeTaylor Blau, Jul 12, 2022
  2. 1/3 t5318: demonstrate commit-graph generation v2 corruptionTaylor Blau, Jul 12, 2022
  3. Derrick StoleeJul 15, 2022
  4. Taylor BlauJul 15, 2022
  5. Junio C HamanoJul 16, 2022
  6. Taylor BlauJul 16, 2022
  7. 2/3 commit-graph: introduce `repo_find_commit_pos_in_graph()`Taylor Blau, Jul 12, 2022
  8. Derrick StoleeJul 15, 2022
  9. 3/3 commit-graph: fix corrupt upgrade from generation v1 to v2Taylor Blau, Jul 12, 2022
  10. Junio C HamanoJul 13, 2022
  11. Taylor BlauJul 15, 2022
  12. Derrick StoleeJul 15, 2022

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.