diff mbox series

[1/8] rebase: simplify code related to imply_merge()

Message ID 20230323162235.995574-2-oswald.buddenhagen@gmx.de (mailing list archive)
State New, archived
Headers show
Series sequencer refactoring | expand

Commit Message

Oswald Buddenhagen March 23, 2023, 4:22 p.m. UTC
The code's evolution left in some bits surrounding enum rebase_type that
don't really make sense any more. In particular, it makes no sense to
invoke imply_merge() if the type is already known not to be
REBASE_APPLY, and it makes no sense to assign the type after calling
imply_merge().

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
---
 builtin/rebase.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

Comments

Phillip Wood March 23, 2023, 7:40 p.m. UTC | #1
Hi Oswald

On 23/03/2023 16:22, Oswald Buddenhagen wrote:
> The code's evolution left in some bits surrounding enum rebase_type that
> don't really make sense any more. In particular, it makes no sense to
> invoke imply_merge() if the type is already known not to be
> REBASE_APPLY, and it makes no sense to assign the type after calling
> imply_merge().

These look sensible, did imply_merges() use to do something more which 
made these calls useful?

Best Wishes

Phillip

> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
> ---
>   builtin/rebase.c | 6 +-----
>   1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5b7b908b66..8ffea0f0d8 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -372,7 +372,6 @@ static int parse_opt_keep_empty(const struct option *opt, const char *arg,
>   
>   	imply_merge(opts, unset ? "--no-keep-empty" : "--keep-empty");
>   	opts->keep_empty = !unset;
> -	opts->type = REBASE_MERGE;
>   	return 0;
>   }
>   
> @@ -1494,9 +1493,6 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>   		}
>   	}
>   
> -	if (options.type == REBASE_MERGE)
> -		imply_merge(&options, "--merge");
> -
>   	if (options.root && !options.onto_name)
>   		imply_merge(&options, "--root without --onto");
>   
> @@ -1534,7 +1530,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>   
>   	if (options.type == REBASE_UNSPECIFIED) {
>   		if (!strcmp(options.default_backend, "merge"))
> -			imply_merge(&options, "--merge");
> +			options.type = REBASE_MERGE;
>   		else if (!strcmp(options.default_backend, "apply"))
>   			options.type = REBASE_APPLY;
>   		else
Junio C Hamano March 23, 2023, 8 p.m. UTC | #2
Phillip Wood <phillip.wood123@gmail.com> writes:

> On 23/03/2023 16:22, Oswald Buddenhagen wrote:
>> The code's evolution left in some bits surrounding enum rebase_type that
>> don't really make sense any more. In particular, it makes no sense to
>> invoke imply_merge() if the type is already known not to be
>> REBASE_APPLY, and it makes no sense to assign the type after calling
>> imply_merge().
>
> These look sensible, did imply_merges() use to do something more which
> made these calls useful?

Good question.

>>   @@ -1494,9 +1493,6 @@ int cmd_rebase(int argc, const char **argv,
>> const char *prefix)
>>   		}
>>   	}
>>   -	if (options.type == REBASE_MERGE)
>> -		imply_merge(&options, "--merge");

This piece is reasonable, of course.  We already know we are in
merge mode so there is nothing implied.

Before this hunk, there is a bit of code to react to
options.strategy given.  The code complains if we are using the
apply backend, and sets the options.type to REBASE_MERGE, which is
suspiciously similar to what imply_merge() is doing.  I wonder if
the code should be simplified to make a call to imply_merge() while
we are doing similar simplification like this patch does?
Felipe Contreras March 23, 2023, 9:08 p.m. UTC | #3
On Thu, Mar 23, 2023 at 2:07 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> > On 23/03/2023 16:22, Oswald Buddenhagen wrote:
> >> The code's evolution left in some bits surrounding enum rebase_type that
> >> don't really make sense any more. In particular, it makes no sense to
> >> invoke imply_merge() if the type is already known not to be
> >> REBASE_APPLY, and it makes no sense to assign the type after calling
> >> imply_merge().
> >
> > These look sensible, did imply_merges() use to do something more which
> > made these calls useful?
>
> Good question.

It used to be called imply_interactive(), so --merge did require an
interactive rebase.
diff mbox series

Patch

diff --git a/builtin/rebase.c b/builtin/rebase.c
index 5b7b908b66..8ffea0f0d8 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -372,7 +372,6 @@  static int parse_opt_keep_empty(const struct option *opt, const char *arg,
 
 	imply_merge(opts, unset ? "--no-keep-empty" : "--keep-empty");
 	opts->keep_empty = !unset;
-	opts->type = REBASE_MERGE;
 	return 0;
 }
 
@@ -1494,9 +1493,6 @@  int cmd_rebase(int argc, const char **argv, const char *prefix)
 		}
 	}
 
-	if (options.type == REBASE_MERGE)
-		imply_merge(&options, "--merge");
-
 	if (options.root && !options.onto_name)
 		imply_merge(&options, "--root without --onto");
 
@@ -1534,7 +1530,7 @@  int cmd_rebase(int argc, const char **argv, const char *prefix)
 
 	if (options.type == REBASE_UNSPECIFIED) {
 		if (!strcmp(options.default_backend, "merge"))
-			imply_merge(&options, "--merge");
+			options.type = REBASE_MERGE;
 		else if (!strcmp(options.default_backend, "apply"))
 			options.type = REBASE_APPLY;
 		else