On Thu, 08 Sep 2011, Paul Mackerras wrote: > On Sat, Aug 27, 2011 at 02:31:02PM +0200, Michal Sojka wrote: > > Here is a new version with the micro-optimization. > > > > Another minor change is that this patch now applies to gitk repo > > (http://git.kernel.org/pub/scm/gitk/gitk.git) instead of the main git > > repo. > > > > -Michal > > > > --8<---------------cut here---------------start------------->8--- > > I often use gitk to review patches before pushing them out and I would > > like to have an easy way to edit commits. The current approach with > > copying the commitid, switching to terminal, invoking git rebase -i, > > editing the commit and switching back to gitk is a way too complicated > > just for changing a single letter in the commit message or removing a > > debug printf(). > > > > This patch adds "Edit this commit" item to gitk's context menu which > > invokes interactive rebase in a non-interactive way :-). git gui is > > used to actually edit the commit. > > > > Besides editing the commit message, splitting of commits, as described > > in git-rebase(1), is also supported. > > > > The user is warned if the commit to be edited is contained in another > > ref besides the current branch and the stash (e.g. in a remote > > branch). Additionally, error box is displayed if the user attempts to > > edit a commit not contained in the current branch. > > I have to say that this patch makes me pretty nervous. I can see the > attractiveness of the feature, but I don't like making gitk > unresponsive for a potentially long time, i.e. until git gui exits. > It may not be clear to users that the reason gitk isn't responding is > because some other git gui window is still running. I understand this. See below for a possible solution. > Also, if some subsequent commit no longer applies because of the > changes you make to a commit, it's going to abort the rebase > completely and thus lose the changes you made. That could be > annoying. Agreed. A solution could be to create a ref called for example refs/gitk/failed-rebase and then abort the rebase together with displaying the error message explaining what happened. The edited commit would remain visible and a user can manually cherry pick remaining commits and then reset the original branch to this failed-rebase ref. > I usually do this by starting a new branch just before the commit I > want to change and then use a combination of the cherry-pick menu item > and git commit --amend. Maybe something to make that simpler for > users would be good, i.e. automate it a bit but still have it be a > step-by-step process if necessary. Part of the problem of course is > that neither gitk nor git gui are really designed to be an editing > environment. So what about the following: 1) When user selects "Edit commit", git rebase -i is called, git citool is started on background and things will be set up (I do not know yet how exactly) so that same callback is called when git citool exits. 2) gitk updates the list of commits and marks the current (detached) head by a tag (colored box) saying that there is rebase in progress. The same tag would appear if gitk is executed manually during interactive rebase. 3) When git citool exits (or when you explicitly select something from rebase tag's context menu), rebase would continue. > In fact you really want an edit/compile/test environment so you don't > introduce new bugs. Another possibility would be to allow only editing of the commit message. Then you don't need compile/test steps and the rebase should not fail due to conflicts. I do not think I would like this limitation, but it would certainly be better then nothing. -Michal -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html