2012/9/24 Dariusz Luksza
<dariusz.luksza@xxxxxxxxx>
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.
+1 I would prefer this approach as it clearly separates what is current history
and what is "rebase interactive editor".
If we use drag&drop we should also implement undo as otherwise an accidential
drop on the wrong target commit might be hard to revert.
How about some mockups for the visual part ?
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
