Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] A vision on rebase 
First of all, thanks Robin for stating this discussion and for yours
review on the 'reword' command.

Personally I wouldn't give users possibility to change anything
directly in the history view. Such approach can lead new users to some
errors and confusing.

IMO better solution would be to add 'Rebase Interactive' context menu
option to history view. Then user will right click on commit on with
he want to start history edition and choose this option. Then we will
show him rich editor with preloaded commits to edit. User will be able
to select action (pick, reword, edit, squash, fixup) to be performed
on given commit from drop down list. Each entry would have 'delete
button' and can be drag-and-dropped to different place if history
order should be changed. Under list of commits we can simulate how new
history would look like. Inserting new commit to history would be
handled from context menu using 'insert after' and 'insert before'
options, if one of those would be chosen the 'commit search' dialog
would appear and after finding proper commit it will be inserted into
history.

On Mon, Sep 24, 2012 at 7:55 AM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:


After reading a Dariusz patches in Gerrit for more rebase operations,
we only have "pick" today, and no interaction, here is *my* "vision" of
how it could work. It's not very complicated as an idea so if someone
has a similar idea I would not be surprised.

Image the user it viewing his/her history

  o fix a[HEAD]
  o fix b
  o fix c
  o fix d
  :

Now the user drags "fix c" to HEAD, signifying that he wants to reorder
the commits. EGit rewires the graph after checking for branches
that could lead the user into problem, due to the usual issues with
published work etc, and other problems, i.e. attemting rebase on
other branches than the current may not be the proper thing to
do, though I can imaging exceptions.

EGit now enters interactive rebase mode, similar to how git
invokes the editor, but we're flashier.

A new planned branch appears in the history view.

             Øpick fix c'
Øpick fix a'
o fix a     |
 |           Øpick fix b'
o fix b     |
 o fix c     |
 o fix d ----´
 |

x' is the rebased version of x and the rebase commands appear as labels.
By default the commands are pick.

The planned branch would have differently colored nodes and shapes so
the use clearly sees what are real commits and what are plans.

In addition the user should be able to copy-paste (i.e. cherry-pick) any
commit into the planned branch, delete, edit and so on.

The user would also be able to immediately get feedback on conflict that
would appear from the proposed edits.

During rebase the view would be updated so the user sees how much of the
work has actually been performed.

The visual effect of this related to EGit, but I think JGit would be the
logical place for some of the logic beyonds the traditional rebase. E.g.
we'd need to do a simulation for the quick-feedback regarding conflicts.
I'm not sure about how to handle conflicts here. If a' has a conflict,
then the resolution of that conflict affects whether 'c would introduce
conflicts, so there may be situations where there may not be possible
to predict all conflicts, but then perhaps a worst-case scenario could
be assumed.

-- robin


_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev




--
Best regards

GSM: +48 695 192 160
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Back to the top