Re: [jgit-dev] [egit-dev] A vision on rebase

[Robin Stocker <robin@xxxxxxxxx>]

Robin Rosenberg wrote:
> ----- Ursprungligt meddelande -----
> >
> >
> > 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".
> 
> The point of editing is to change something from one version to
> another and I think switching notation for editing is unnecessary
> and harmful. It is easy to see what is the plan and what is the
> current history given the right visual cues. Two completely
> separated views cannot help here, unless you actually implement
> a new history-like view.

I agree with Dariusz and Matthias here, I think a separate view
would work better. Problems with integrating into History view:

* The History view is already pretty complex (both code and UI).

* The filtering (limit commits to selected file, dir, project) of
  the History view would be problematic when in rebase mode.
  Would this be disabled during the rebase, to always show all
  commits? Otherwise a user may not realize that there are more
  commits than those that are shown which are rebased.

* When history changes, the History view sometimes relayouts,
  causing a change in the graph and the user has to rescan.

* History view is already a drag source, this would have to be
  overloaded for reordering.

* Integrating the action buttons (pick, reword, etc) into
  the graph using SWT will be hard if not impossible.
  (I'm guessing they would be like the ref labels.)


Some benefits of a separate view:

* The view would guide the user through the process, e.g. it
  would be shown until the rebase is finished. In case of a
  conflict it would instruct the user to fix conflicts and add
  the files. It would also offer Continue, Skip, Abort as buttons.

* The context menu can be entirely separate from the normal
  History view context menu, focusing on the rebase use cases.

* One can inspect history (e.g. in case of a conflict during
  rebase) without losing the rebase context.

* It would only be a linear table of the rebasing commits,
  no other commits around or interleaved with the view. This
  also means a simpler implementation.


That said, I'm looking forward to more detailed UI mockups,
maybe the above concerns can be overcome.

And thanks for starting with this important missing piece
within EGit :).

Regards,
  Robin (the other one)


> > 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.
> 
> Undo seems necessary here as in an UI thing, but it's easy to
> forget.
> 
> >
> > How about some mockups for the visual part ?
> 
> I tried some ascii mockup. Seems the formatting fell apart somewhat. I
> can get
> back with something flashier (graphviz?). Perhaps a more complicated
> case may be needed to explorer the pros and cons of the different
> designs.
> 
> Come to think of it, we may want both. Editing the traditional syntax
> would update the graph and vice verse.
> 
> -- robin
> 
> > 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
> >
> >
> > ______________________________ _________________
> > egit-dev mailing list
> > egit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/ mailman/listinfo/egit-dev
> >
> >
> >
> >
> > --
> > Matthias
> >
> > _______________________________________________
> > egit-dev mailing list
> > egit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/egit-dev
> >
> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jgit-dev