Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Rebase usability


----- 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.

> > 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?"



Back to the top