[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] [egit-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
