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

Re: Git status parse error after v.2.22.0 upgrade

From
Jeff King <peff@peff.net>
Date
Jun 13, 2019, 19:00 UTC
Message-ID
<20190613190037.GA27217@sigill.intra.peff.net>
In-Reply-To
<8981e6c8-eb20-fde7-2b4c-1fbf2057caef@gmail.com>
On Thu, Jun 13, 2019 at 06:43:41PM +0100, Phillip Wood wrote:
Show 17 quoted lines
> >>  (2) make the sequencer machinery more careful to clean up after it
> >>      is done or it is aborted  (for example, "git reset --hard"
> >>      could remove these state files preemptively even when a rebase
> >>      is not in progress, I would think).
> >>
> >> I think we already had some patches toward the latter recently.
> > 
> > Maybe I am not understanding it correctly, but do you mean in (2) that
> > "git reset --hard" would always clear sequencer state?
> 
> I think the commit Junio is referring to is
> b07d9bfd17 ("commit/reset: try to clean up sequencer state", 2019-04-16)
> which will only remove the sequencer directory if it stops after the
> pick was the last one in the series. The idea is that if cherry-pick
> stops for a conflict resolution on the last pick user commits the result
> directly or run reset without running `cherry-pick --continue`
> afterwards the sequencer state gets cleaned up properly.

OK, that makes a lot more sense to me. It did make me wonder if doing an "e"dit on the final commit of a rebase followed by "reset HEAD^" would clear the sequencer state. But looking at that commit, this kicks in only for the cherry-pick and revert cases.

Thanks for explaining.
> If we do want to do something then maybe teaching gc not to collect
> commits listed in .git/sequencer/todo and
> .git/rebase-merge/git-rebase-todo would be useful.

IMHO that opens up a can of worms, because the reachability rules get more complicated (so for example people trying to prune away unwanted history get confused about what is still mentioning the objects). That's a reasonable rare case. OTOH, so is mentioning commits in an ongoing rebase that are not still reachable from the branch you are rebasing, nor the HEAD reflog.

-Peff
Previous: Phillip WoodNext: Phillip Wood
Message 9 of 12 in “Git status parse error after v.2.22.0 upgrade”
  1. Espen AntonsenJun 11, 2019
  2. Johannes SchindelinJun 11, 2019
  3. Espen AntonsenJun 12, 2019
  4. Johannes SchindelinJun 12, 2019
  5. aleksandrs@ledovskis.lvJun 13, 2019
  6. Junio C HamanoJun 13, 2019
  7. Jeff KingJun 13, 2019
  8. Phillip WoodJun 13, 2019
  9. Jeff KingJun 13, 2019
  10. Phillip WoodJun 25, 2019
  11. SZEDER GáborJun 13, 2019
  12. Aleksandrs ĻedovskisJun 13, 2019

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.