| Re: [jgit-dev] [egit-dev] A vision on rebase |
2012/9/25 Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>
----- Ursprungligt meddelande -----
The point of editing is to change something from one version to>
>
> 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".
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.ok, maybe I didn't yet fully get what these visual clues should look like> If we use drag&drop we should also implement undo as otherwise anUndo seems necessary here as in an UI thing, but it's easy to
> accidential
> drop on the wrong target commit might be hard to revert.
forget.
I tried some ascii mockup. Seems the formatting fell apart somewhat. I can get
>
> How about some mockups for the visual part ?
back with something flashier (graphviz?). Perhaps a more complicated
case may be needed to explorer the pros and cons of the different
designs.Something flashier would be nice :) Maybe graphviz or wireframesketcher ?Come to think of it, we may want both. Editing the traditional syntax
would update the graph and vice verse.
-- robin
> Matthias
> 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
>
>
>
>
> --
>
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev
>
--
Matthias
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jgit-dev