[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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