> issue is present in the 'am' rebase backend. > Note that the sleep() calls were added to 'builtin/am.c', i.e.
> error: could not read '.git/rebase-apply/head-name': No such file or directory > Applying: sha1-file: remove OBJECT_INFO_SKIP_CACHED > And then we can reliably reproduce the issue even when rebasing only a > + for (i = 0 i + fprintf(stderr, "sleeping. > say(state, stdout, _("Applying: %.*s"), linelen(state->msg), state->msg) > -1737,6 +1737,14 static void am_run(struct am_state *state, int resume) > diff -git a/builtin/am.c b/builtin/am.c
#GIT REBASE ABORT PATCH#
> This patch below increases the size of the window where a ctrl-C gets > couple of tries I managed to hit ctrl-C while 'git rebase' was > back, and 'git rebase -abort' works as it should. > Once 'git rebase' stops because of the merge conflict we get our shell > and we are not rebasing, so there is no need for 'git rebase -abort'. > 'git rebase' starts applying patches, then it cleans everything up, > There is a rather short window when 'git rebase' applies patches > Trying to reproduce it is a hit or miss. > unrelated (none of them touches rebase or the sequencer) patches on > All this is with a git built from current 'next', with a bunch of > that was exactly what I did, instead of securing the failed state for > of the situation by forcibly deleting that worktree. > "Fortunately" it was in a separate worktree, so I could easily get out > error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory > Falling back to patching base and 3-way merge. > Using index info to reconstruct a base tree. > Applying: send-email: do defaults -> config -> getopt in that order > Applying: send-email: rename the variable for consistency > Applying: send-email: move the read_config() function above getopts > First, rewinding head to replay your work on top of it. > of patches I realized that something is wrong, hit ctrl-C right away, Upon seeing the unexpectedly large number > rebase', and ended up trying to rebase a fairly recent (post v2.24.0) > I somehow messed up the upstream and branch parameters of 'git > 'git rebase -abort' will refuse to clear it up. > rebase' process with ctrl-C in just the right moment that a subsequent > So, to clarify: apparently it is possible to abort an ongoing 'git
Subject: Re: 'git rebase -abort' couldn't abort aborted rebaseĭate: Fri, 09:52:51 -0800
#GIT REBASE ABORT ARCHIVE#
Re: 'git rebase -abort' couldn't abort aborted rebase - Elijah Newren archive mirror help / color / mirror / Atom feed From: Elijah Newren
0 kommentar(er)
