Re: [egit-dev] Rebase usability

[Duft Markus <Markus.Duft@xxxxxxxxxx>]

Just my 2 cents on „educating all users“: impossible! Once somebody has started using it (we have this feature already in our EGit build!), it will get back as bug if behavior changes...

 

Regards,

Markus

 

Von: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] Im Auftrag von Matthias Sohn
Gesendet: Sonntag, 15. Dezember 2013 22:03
An: Robin Rosenberg
Cc: EGit developer discussion
Betreff: Re: [egit-dev] Rebase usability

 

On Sun, Dec 15, 2013 at 3:08 PM, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote:

----- Ursprungligt meddelande -----
> Från: "Matthias Sohn" <matthias.sohn@xxxxxxxxx>
> Till: "Robin Rosenberg" <robin.rosenberg@xxxxxxxxxx>
> Kopia: "EGit developer discussion" <egit-dev@xxxxxxxxxxx>
> Skickat: lördag, 14 dec 2013 22:48:15
> Ämne: Re: [egit-dev] Rebase usability

>
> On Sat, Dec 14, 2013 at 4:20 PM, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx
> > wrote:
>
> >
> > First, It's marvelous to see rebase in EGit. Rebase has been one of the
> > main reasons
> > to use the command line extensively.
> >
> > On usability, I wonder wheter doing like C Git does is the right thing.
> > I'd expect
> > the selected version should be included in the rebase for several reasons.
> > I know
> > C Git does not. In the command this is easily fixes, just do "git rebase
> > -i commit^".
> >
>
> We copied C Git's behavior since we thought this is what users would expect
> so which are the reasons to include the selected version ?

Often I want to rebase after identifying a commit that I want to edit, so I
have selected it already, and as I mentioned, in a filtered view it's hard
to select the parent.

 

We could try this and change the behavior so that the selected commit is

included in the rebase todo list, we just have to educate the users about

this change.

 

There's one case where this probably doesn't make much sense:

you can also select a commit which is not a predecessor but on a side branch

and start interactive rebase to edit commits between HEAD and the common

predecessor and at the same time rebase on the new base.

 

Let's say I want to edit C and also rebase C - D on X

 

A -- B -- C -- D <-- HEAD

       |

       ---- X

 

Then with the current behavior I can select X and click "Rebase Interactive"

and then set the action "Edit" on B and I will get

 

A -- B

       |

       ---- X -- C' -- D'

 

and rebase will stop at C' to allow amending this commit. Not sure if

it would make sense to also include B and X into the rebase todo list in this case.

 

We also could add a couple of additional commands to provide shortcuts for

frequently used actions, the menu could look like

 

...

Revert Commit

Merge

Rebase on

-----------------------

Rebase Interactive

Edit

Skip

Squash

Fixup

Reword

Move up

Move down

-----------------------

...

 

the shortcut actions would start rebase interactive on the parent of the

selected commit, set the selected rebase action and immediately start

interactive rebase. Move up/down could be also provided via drag&drop.

 

> > In Egit that's not as easy, especially if you start with a filtered
> > history, where
> > it's not as easy to select the previous commit. In a complex graphh it is
> > not easy
> > even when no filtering takes place.
> >
> > In most cases including the selected commit in the edit list would cause
> > no issues since
> > picking the first commits in the original order is a noop, but if the
> > selected commit is
> > a merge, the effect would be a surprise.
> >
>
> we could disable changing the action if the first commit is a merge

Maybe a question is the right thing. "Do you want to include the selected commit
in the edit list?"

 

yes

 

--

Matthias 

 

Salomon Automation GmbH | Friesachstrasse 15 | 8114 Friesach bei Graz | Austria
Registered Office: Friesach bei Graz | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht für Zivilrechtssachen Graz