| Re: [jgit-dev] [egit-dev] A vision on rebase |
> -----Original Message----- > From: Matthias Sohn > Sent: Monday, September 24, 2012 4:55 PM > > 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. An easier way might be to stage the changes (with a review option) until the OK or Cancel is chosen. This is similar to how db tools would present a alter table. After all the changes are stages there is usually a show SQL button to review the change script, then accept or abort. > > How about some mockups for the visual part ? > > > > 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 > <https://dev.eclipse.org/mailman/listinfo/egit-dev> > > > > > > -- > Best regards > > GSM: +48 695 192 160 <tel:%2B48%20695%20192%20160> > Blog: http://luksza.org > LinkedIn: http://www.linkedin.com/in/dariuszluksza > <http://www.linkedin.com/in/dariuszluksza> > > _______________________________________________ > egit-dev mailing list > egit-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/egit-dev > <https://dev.eclipse.org/mailman/listinfo/egit-dev> > > > > > > -- > Matthias
Attachment:
smime.p7s
Description: S/MIME cryptographic signature