git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Patrick Steinhardt <ps@pks.im>,
	Phillip Wood via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Brian Lyles <brianmlyles@gmail.com>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] rebase: apply and cleanup autostash when rebase fails to start
Date: Wed, 14 Aug 2024 16:59:32 +0100	[thread overview]
Message-ID: <b676bd17-1cc8-4639-acb7-675dde32a1ae@gmail.com> (raw)
In-Reply-To: <ZrzA0yp45w9NuTp2@tanuki>

Hi Patrick

On 14/08/2024 15:36, Patrick Steinhardt wrote:
> On Wed, Aug 14, 2024 at 01:22:27PM +0000, Phillip Wood via GitGitGadget wrote:
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> If "git rebase" fails to start after stashing the user's uncommitted
>> changes then it forgets to restore the stashed changes and remove state
> 
> s/remove/& the/
> 
>> directory. To make matters worse running "git rebase --abort" to apply
> 
> s/worse/&,/
> 
>> the stashed changes and cleanup the state directory fails because the
> 
> s/cleanup/& of/

Thanks for catching those typos

>> diff --git a/builtin/rebase.c b/builtin/rebase.c
>> index e3a8e74cfc2..ac23c4ddbb0 100644
>> --- a/builtin/rebase.c
>> +++ b/builtin/rebase.c
>> @@ -526,6 +526,23 @@ static int rebase_write_basic_state(struct rebase_options *opts)
>>   	return 0;
>>   }
>>   
>> +static int cleanup_autostash(struct rebase_options *opts)
>> +{
>> +	int ret;
>> +	struct strbuf dir = STRBUF_INIT;
>> +	const char *path = state_dir_path("autostash", opts);
>> +
>> +	if (!file_exists(path))
>> +		return 0;
>> +	ret = apply_autostash(path);
>> +	strbuf_addstr(&dir, opts->state_dir);
>> +	if (remove_dir_recursively(&dir, 0))
>> +		ret = error_errno(_("could not remove '%s'"), opts->state_dir);
> 
> This seems somewhat dangerous to me though. Should we really delete the
> autostash directory in case applying the autostash has failed?

Applying the stash should not fail because the rebase has not started 
and so HEAD, the index and the worktree are unchanged since the stash 
was created. If it does fail for some reason then apply_autostash() 
creates a new entry under refs/stash. We definitely do want to remove 
the directory otherwise we're left with the inconsistent state we're 
tying to fix.

>> @@ -1851,9 +1871,14 @@ run_rebase:
>>   
>>   cleanup:
>>   	strbuf_release(&buf);
>> +	strbuf_release(&msg);
>>   	strbuf_release(&revisions);
>>   	rebase_options_release(&options);
>>   	free(squash_onto_name);
>>   	free(keep_base_onto_name);
>>   	return !!ret;
>> +
>> +cleanup_autostash:
>> +	ret |= !!cleanup_autostash(&options);
>> +	goto cleanup;
>>   }
> 
> It's somewhat curious of a code flow to jump backwards. It might be
> easier to reason about the flow if we kept track of a variable
> `autostash_needs_cleanup` that we set such that all jumps can go to the
> `cleanup` label instead.

It is slightly odd, but in the end I decided it was simpler to say "goto 
cleanup_autostash" than try and keep track of what needs cleaning up 
when saying "goto cleanup". There are a couple of similar examples in 
builtin/stash.c:show_stash() and 
config.c:git_config_set_multivar_in_file_gently()

Thanks for the review

Phillip


> Patrick
> 

  reply	other threads:[~2024-08-14 15:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14 13:22 [PATCH] rebase: apply and cleanup autostash when rebase fails to start Phillip Wood via GitGitGadget
2024-08-14 14:36 ` Patrick Steinhardt
2024-08-14 15:59   ` Phillip Wood [this message]
2024-08-14 17:27     ` Junio C Hamano
2024-08-15  9:47       ` Phillip Wood
2024-09-08 21:54         ` Junio C Hamano
2024-09-08 21:54         ` Junio C Hamano
2024-09-02 15:12 ` [PATCH v2] " Phillip Wood via GitGitGadget
2024-09-08 21:55   ` Junio C Hamano
2024-09-12 20:44     ` Junio C Hamano

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=b676bd17-1cc8-4639-acb7-675dde32a1ae@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=brianmlyles@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).