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

["Swindells, Thomas" <TSwindells@xxxxxxx>]

A lot of good ideas are coming out here.
One feature that would be useful - and provide a vast improvement over using the
CLI is the ability to split and reorder commits easily. The main functionality required
for this would be to be able to insert new commits and be able to drag and move files
between commits to redistribute the changes. A step beyond this would also be to
do it at the patch level so that if two parts of a file have been modified you can
selectively drag just one of the patches underneath it into a different commit.
This would be equivalent to the staging patches support in the interactive add CLI
but being visual potentially a lot easier to use.

Most of this should be relatively straight forward if a tree structure is shown of the
commit, files in the commit and then patches in the file. Depending what you select
and where you choose to drop it will determine the behaviour to be done.

Dragging a commit and dropping it after another will reorder, dropping it on another
will squash, off the screen will drop the commit.

Dragging a file and dropping it within another commit will move the patches, dragging
it between two commits will insert a new commit with that file, dragging off the screen
will unstage the change.

Dragging a patch and dropping it within another commit will move the patch - adding the new
file to the commit if necessary, and similar behavior to the other scenarios.

Context menus should also be available to perform some of the commands particular
drop/revert and editing a commit message.


I think in an ideal world the rebase would be performed in real time so feedback is
Immediately available if a modification creates a conflict in later commits, and sensible
tools to easily see always resolve it the way I just changed it.

Similarly during the rebase it should be easy to checkout any change, make changes to the
files and then commit the changes back onto that change (ie edit operation). If egit were
performing the rebase in realtime this operation could then also be performed in any order
rather than the command lines sequential ordering.

If realtime ends up being too expensive having a button to propagate the changes and see the
result would be another option - this would be separate from then finally saving and applying
the final results of the rebase.

Thomas

> -----Original Message-----
> From: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Kinzler, Mathias
> Sent: 26 September 2012 08:16
> To: EGit developer discussion; jgit-dev@xxxxxxxxxxx
> Subject: Re: [egit-dev] [jgit-dev] A vision on rebase
>
> I have been out of this for a while, but can't resist to add my five cent here, too.
>
> First of all, I would say that this sound like a terrific idea.
>
> However, I can only agree with Robin Stocker: don't try to further overload the
> history view. It is already the by far most complex part of the EGit UI (both
> coding and end-user experience-wise) and could rather use some reduction of
> functionality (for example, I wonder who ever uses the search functionality now
> that we have Git Search; it is really ugly and hard to use [fingerpointing at
> myself])...
>
> Whether yet another view is the right approach, I'm not quite sure. Maybe it's
> more like an editor where the "planned branch" is edited (at the end of the day,
> the file with the commits and actions is edited just like in rebase interactive in
> the command line, just with cool graphical tool support, right?). Upon "Save",
> the editor is closed and rebase is actually done/started. Perhaps even a dialog
> should be used for editing. My point here is that you do some planning using
> drag&drop etc. and finally enter rebase mode applying this plan. Without a
> clear "Save" of the plan or "Start Rebase", I wonder what the significance of
> "real" vs. "planned" commits would be.
>
> Looking at the "rebase interactive" from the command line, the "edit" option
> would stop after applying the commit specified in the given line. I wonder how
> this would be integrated. Perhaps you would add a commit in the above editor
> and mark it somehow as "edit". The rebase is started and stops letting the user
> edit and commit. Then they press Rebase->Continue... In that case I believe it
> would really be helpful to give the user some information (after pressing
> Continue) where they are in their rebase: I imagine a list of the already applied
> commits, the editing actions etc. that have already been done since the start of
> the rebase and the list of planned commits/edits etc. for this rebase. I believe
> that this could be the exact same dialog/editor as the one used to plan the
> rebase with some additional visual hints which parts of the plan have been
> applied and which parts are still to come.
>
> Maybe also a "single step" mode could be nice for more complex rebases
> stopping after each commit (without the user having specified "edit" explicitly).
> Then after each step the user could inspect the repository and decide what to
> do (dispose the last commit by reverting, abort the rebase altogether, skipping
> the next or all subsequent steps in the plan).
>
> So, in short:
> 1. Don't reuse the history view
> 2. Think about the distinction between planning and execution of the rebase 3.
> Visualize the "you are here" during execution of the rebase
>
> All the best,
> Mathias
>
>
> -----Original Message-----
> From: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Robin Stocker
> Sent: Dienstag, 25. September 2012 22:28
> To: Robin Rosenberg
> Cc: EGit developer discussion; jgit-dev@xxxxxxxxxxx
> Subject: Re: [egit-dev] [jgit-dev] A vision on rebase
>
> 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
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev

________________________________


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@xxxxxxx and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************