[RFC] Add config option corresponding to --rebase-merges

[RFC] Add config option corresponding to --rebase-merges

[Dakota Hawkins]

I'd like to work on a patch to add config options that correspond to
rebase's --rebase-merges flag.

In my workflow, while it's uncommon to encounter merge commits during
a rebase operation, when they are encountered I pretty much always
want this behavior. Since it's rare, I pretty much always forget to
ask for it, with interesting and confusing consequences.

If nobody has any opposition to the concept, the following are the
specific options and values that I think makes sense and covers the
existing functionality.

# New rebase.merges config that takes effect if set to true or cousins
+ rebase.merges=
+   true
+   cousins

# New cousins value for pull.rebase
pull.rebase=
+   cousins

# New pull.rebaseMerges config that takes effect if set to true or
# cousins. Intended to allow pull.rebase to be set to interactive.
+ pull.rebaseMerges=
+   true
+   cousins

# Corresponding additions for branch.<name> config
branch.<name>.rebase=
+   cousins
branch.<name>.rebaseMerges=
+   true
+   cousins

I'd like to get feedback on the idea and specific options proposed,
if only to avoid having to tweak them once they've been added.

Thanks,

Dakota Hawkins

Re: [RFC] Add config option corresponding to --rebase-merges

[Dakota Hawkins]

I think it would also be prudent to add the following:

# Auto-config option values for new branches
branch.autoSetupRebase=
+   localCousins
+   remoteCousins
+   alwaysCousins

Re: [RFC] Add config option corresponding to --rebase-merges

[Johannes Schindelin]

Hi Dakota,

On Fri, 23 Aug 2019, Dakota Hawkins wrote:

> I'd like to work on a patch to add config options that correspond to
> rebase's --rebase-merges flag.
>
> In my workflow, while it's uncommon to encounter merge commits during
> a rebase operation, when they are encountered I pretty much always
> want this behavior. Since it's rare, I pretty much always forget to
> ask for it, with interesting and confusing consequences.
>
> If nobody has any opposition to the concept, the following are the
> specific options and values that I think makes sense and covers the
> existing functionality.

I am in favor of this, as indicated at
https://github.com/gitgitgadget/git/issues/318

> # New rebase.merges config that takes effect if set to true or cousins
> + rebase.merges=
> +   true
> +   cousins
>
> # New cousins value for pull.rebase
> pull.rebase=
> +   cousins
>
> # New pull.rebaseMerges config that takes effect if set to true or
> # cousins. Intended to allow pull.rebase to be set to interactive.
> + pull.rebaseMerges=
> +   true
> +   cousins
>
> # Corresponding additions for branch.<name> config
> branch.<name>.rebase=
> +   cousins
> branch.<name>.rebaseMerges=
> +   true
> +   cousins
>
> I'd like to get feedback on the idea and specific options proposed,
> if only to avoid having to tweak them once they've been added.

I am not quite sure about the "cousins" thing. If at all, I would make
that a global option, I think. But then, maybe you have a use case in
mind where it would make sense to rebase cousins in some, but not in
other cases, cases that can be discerned via branch names?

Ciao,
Johannes

Re: [RFC] Add config option corresponding to --rebase-merges

[Dakota Hawkins]

> I am not quite sure about the "cousins" thing. If at all, I would make
> that a global option, I think. But then, maybe you have a use case in
> mind where it would make sense to rebase cousins in some, but not in
> other cases, cases that can be discerned via branch names?

I wasn't sure about that either (in fact I don't think I knew it existed before
looking in to this), but I included it here in an attempt to be "symmetrical"
with the --rebase-merges flag functionality.

Both pull.rebase and branch.<name>.rebase support the value "merges", so I
think a rebase.merges config boolean is at least a no-brainer. In this case,
though, it concerns me that you can set these to either "interactive" or
"merges", so there's no way to have both. That's why I also suggest adding a
".rebaseMerges" option to these (to allow .rebase=interactive).

I could imagine that there exists some workflows where
--rebase-merges=rebase-cousins might be desired either globally or for certain
branches, though I don't think it's something I'd use myself. I really need to
play around with it in a test repo to better understand its implications.

This is the kind of feedback I was hoping for, though. I'd be amenable to
adding only the simple option (if there's any kind of consensus on that) since
that's the one I really want to use myself.

Thanks!

Dakota

On Mon, Aug 26, 2019 at 10:19 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Dakota,
>
> On Fri, 23 Aug 2019, Dakota Hawkins wrote:
>
> > I'd like to work on a patch to add config options that correspond to
> > rebase's --rebase-merges flag.
> >
> > In my workflow, while it's uncommon to encounter merge commits during
> > a rebase operation, when they are encountered I pretty much always
> > want this behavior. Since it's rare, I pretty much always forget to
> > ask for it, with interesting and confusing consequences.
> >
> > If nobody has any opposition to the concept, the following are the
> > specific options and values that I think makes sense and covers the
> > existing functionality.
>
> I am in favor of this, as indicated at
> https://github.com/gitgitgadget/git/issues/318
>
> > # New rebase.merges config that takes effect if set to true or cousins
> > + rebase.merges=
> > +   true
> > +   cousins
> >
> > # New cousins value for pull.rebase
> > pull.rebase=
> > +   cousins
> >
> > # New pull.rebaseMerges config that takes effect if set to true or
> > # cousins. Intended to allow pull.rebase to be set to interactive.
> > + pull.rebaseMerges=
> > +   true
> > +   cousins
> >
> > # Corresponding additions for branch.<name> config
> > branch.<name>.rebase=
> > +   cousins
> > branch.<name>.rebaseMerges=
> > +   true
> > +   cousins
> >
> > I'd like to get feedback on the idea and specific options proposed,
> > if only to avoid having to tweak them once they've been added.
>
> I am not quite sure about the "cousins" thing. If at all, I would make
> that a global option, I think. But then, maybe you have a use case in
> mind where it would make sense to rebase cousins in some, but not in
> other cases, cases that can be discerned via branch names?
>
> Ciao,
> Johannes