From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: aleksandrs@ledovskis.lv,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Espen Antonsen <espen@inspired.no>,
git@vger.kernel.org
Subject: Re: Git status parse error after v.2.22.0 upgrade
Date: Thu, 13 Jun 2019 18:58:33 +0200 [thread overview]
Message-ID: <20190613165833.GD31952@szeder.dev> (raw)
In-Reply-To: <xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com>
On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:
> aleksandrs@ledovskis.lv writes:
>
> > My repo indeed contains a ".git/sequencer/todo" file which
> > contains references to commits long-gone (i.e., rebased).
> > Renaming or deleting this file stops whines about "error: could
> > not parse".
>
> Interesting. So in short, when the repository has leftover
> sequencer state file that is not in use, "git status parse" thing
> (whatever it is---are you getting it when you run "git status"
> command???)---is not careful enough to notice that it does not
> matter even if that leftover file is unusable.
>
> Two issues "the sequencer" folks may want to address are
>
> (1) make the one that reads an irrelevant/stale 'todo' file more
> careful to ignore errors in such a file;
>
> (2) make the sequencer machinery more careful to clean up after it
> is done or it is aborted
It may or may not be related, but... Some weeks (months?) ago I run
into a situation where 'git rebase' didn't clean up after itself
following a well-timed ctrl-C, and got confused to the point that not
even a subsequent 'git rebase --abort' was able to rectify the
situation.
So, I wanted to rebase just a couple of commits to somewhere else, but
messed up the command's parameters, and it then tried to rebase a
couple hundred commits. Upon noticing the unexpectedly large numbers
in the "Generating patches" progress line I hit ctrl-C, and then the
aborting 'git rebase' apparently left an incomplete/corrupted
'.git/rebase-apply/' directory behind. Unfortunately I didn't think
about saving the precious corrupted state, and deleted that dir right
away... only saved the transcript from the terminal later:
~/src/git (test-atexit)$ git rebase js/test-atexit
First, rewinding head to replay your work on top of it...
Generating patches: 100% (509/509), done.
^C
~/src/git ((42e6cb0046...)|REBASE 1/509)$ gitk js/test-atexit
~/src/git ((42e6cb0046...)|REBASE 1/509)$ git rebase --abort
error: could not read '.git/rebase-apply/head-name': No such file or directory
~/src/git ((42e6cb0046...)|REBASE 1/509)$ git reset --hard
HEAD is now at 42e6cb0046 git-p4: use `test_atexit` to kill the daemon
~/src/git ((42e6cb0046...)|REBASE 1/509)$ rm -rf .git/re
rebase-apply/ rebased-patches refs/
~/src/git ((42e6cb0046...)|REBASE 1/509)$ rm -rf .git/rebase-apply/
~/src/git ((42e6cb0046...))$ git checkout -
next prev parent reply other threads:[~2019-06-13 16:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 12:58 Git status parse error after v.2.22.0 upgrade Espen Antonsen
2019-06-11 19:28 ` Johannes Schindelin
2019-06-12 12:47 ` Espen Antonsen
2019-06-12 18:47 ` Johannes Schindelin
2019-06-13 9:30 ` aleksandrs
2019-06-13 16:05 ` Junio C Hamano
2019-06-13 16:24 ` Jeff King
2019-06-13 17:43 ` Phillip Wood
2019-06-13 19:00 ` Jeff King
2019-06-25 13:25 ` Phillip Wood
2019-06-13 16:58 ` SZEDER Gábor [this message]
2019-06-13 17:11 ` Aleksandrs Ļedovskis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190613165833.GD31952@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=aleksandrs@ledovskis.lv \
--cc=espen@inspired.no \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.