Intelligent Amend Commit

[NJAldwin]

Currently, it's rather easy to mess up when doing an "amend commit". First, one must click the Amend Commit button in the commit dialog, in order to load the last commit & commit message. Then, when one is done, one must click the Amend Commit button again---_NOT_ the Commit button---to finish amending the commit.

Perhaps, to make this more intuitive, we could have a message or notification that comes up when someone clicks the Commit button after the Amend Commit button which asks them if they meant to amend the commit by pressing the Amend Commit button again.

This probably isn't the best way to solve the problem. However, I do think that it needs a better solution. Right now it is counter-intuitive.

[NJAldwin]

It would be relatively easy for me to write this myself, but as I said I am not sure if this is the best way to solve the problem. So would there be a better way to get rid of the confusing parts?

[avish]

+1, this is very confusing. For comparison, git gui does this by just having a radio button selecting between "make a new commit" and "amend previous commit". When the latter is selected, the previous commit message and the files changed by it are automatically loaded. Then to finalize the action you click "commit" regularly.

[Turbo87]

Just FYI: I usually title my patches in the format ": <title>". When I do multiple commits my workflow is normally to let GitEx load the commit message of the last commit by pressing amend, edit the message and then commit my stuff as a new commit. I know there is also the menu with the last used commit messages, but it takes a certain time to load and requires one more aim-and-click than my current solution ;)

[NJAldwin]

Those angle brackets you used (visible in the email) are invisible on the site. For those interested, his patch format is ": <title>"

[vcpp]

NJAldwin: I'm absolutely agree, current interface is counter-intuitive. I think that interface should be fixed instead of teaching user how to use current interface. Confirmation message is not a real fix, it's just a hotfix. It's not good idea to try to solve UI-complexity issues with additional hints and confirmations. UI should be clear itself.
In the best way each button has only one function, so I suggest to split amend button to two buttons: "Load previous commit message" and "Amend previous commit". Second button is disabled until first button clicked.

Turbo87: it's not true, it's abnormal using of feature. Let's think about another button or hotkey for inserting commit message template. In future it also can be used by issue-tracker integration plugins, which could provide some combobox for selecting an issue and auto-prepare commit message with template.

[pasa-]

+1, I messed up amend using this interface. (I just realize now what happened -- internally I just marked that feature as broken and to be avoided.)

The git gui way worked well for me from the start. And it could retain the message text for Turbo87 too, though IMO it's an abuse. :) And the text could be imported from many sensible sources (local commit history, the log, configured templates...) but that's a different FRQ.

I tried the amend again -- clicking the amend button does bring up the message text, but staged files don't appear so I can take anything back. So the feature is IMNSHO broken as I remembered.

[phillijw]

I came here to complain about this interface. I don't feel like "Amend commit" deserves a spot on the commit dialog in the first place. Could we make it a context menu on the commit graph itself?

• Right-click a commit
• Select "Amend commit"
• An amend commit window comes up (I'm not entirely sure what options amend gives you so I can't say for sure what's on the window)

[pasa-]

IMO it does belong there just as it is fine in git GUI -- amending the last (unpushed) commit is part of a sensible workflow.

The right-click is a different feature request, as there you can pick an arbitrary commit, and should be able to order "squash" and "fixup" for it. Certainly that would create a separate commit with message prepared for --autosquash. (the fixup version exists in GE in the manipulate commit menu.)

Direct amending a previous commit looks odd to me, though there could be a good interface for the 'interactive rebase' operation, that you could select like that. Tortoise Git has start of the functionality, but when I tried it just did not what I expected at all. I would enjoy an actally working GUI for multiple cherry-picks and interactive rebase.

[phillijw]

I was just throwing out ideas. I actually didn't get a chance to read all the previous comments until now and it sounds like using a radio button, as @avish said, makes the most sense.

[Teybeo]

I've been confused with this too. By reading this issue, I've just understand that it was normal, due to the commit button currently generating a new commit.
Personally, @NJAldwin proposition, changing the "Commit" button to actually amend the last commit (if it was loaded with a precedent click on "Amend last commit") would be ok for me. Either this or a radio button a la Git Gui.
And the loading of the staged files of the last commit of course.

I don't have the skills to fix this, I can only add myself to the list of those who think/needs this to be fixed.

[j-a-b]

Does anyone have any more brainstorming ideas on how to address this?

Conceptually, do you think it is more intuitive to:

1. Try to work it into the existing commit dialog (examples are the existing button or the checkbox idea submitted above)
2. Create an entirely separate button, parallel to the button that launches the Commit dialog for launching a Commit Amend dialog?
3. Any other overall approaches to consider?

[KindDragon]

Amend checkbox it's ok for me, but changing commit message to previous commit message on selecting combobox is confusing.
We can move this functionality to "Commit message" menu, but Amend would be too complicated (4 clicks)

[j-a-b]

I wonder if some sort of "tabbed" interface could be more intuitive (Something that looks like like the Write/Preview comment box I'm typing in on GitHhub right now).

It seems that one of the advantages of a tab over a checkbox is that the user expects to get entirely different content when they switch tabs.

The only thing I'm not sure about is if we ever got to the point where the file staging area also represents the previous commit's files, would it still be intuitive if the tab was on the comment box. Maybe in this case it could move to the top of the dialog?

[jasir]

Hello, this is reason why I do not use GitExtensions for commiting. For me, just adding the functionality when when I check ammend last commit button, changes from previous commit would be written to staging area would be the best, exactly as gitgui is doing.

[patricktokeeffe]

Things have improved since this was opened. The current amend checkbox + single commit button works great for me. Thanks everyone who made that happen.

And I agree 100% with @jasir: the gitgui behavior of loading HEAD^ back into the staged area when amending is pure gold. I look forward to that happening with GitEx too.

[sadastronaut]

"Amend Commit" and the Commit dialog, in general, for me has several issues.

1. I can only populate the commit dialog with the last commit if I clear out all the text in the commit message, then clikc Amend Commit.
2. When I do the Commit after Step 1, it pops up the warning saying I'm going to rewrite history and all that. If I do that, it clears out my commit dialog and asks me to please enter a commit message. Perhaps the fact that I'm using a template messes it up.

Unrelated to the commits...if I have modified files but I forget to stage them, I enter in my commit message, hit the commit button, confirm that I want to stage and commit all changes via the commit dialog, then it clears out the commit message and asks me to enter a commit message. Again, this could be related to my template (not done via extensions but a COMMITMESSAGE.txt handled by git itself).

[ghanique]

I don't have any issues with the Commit Message textbox being cleared, ever.

On Tue, Apr 28, 2015 at 8:53 PM, sadastronaut notifications@github.com
wrote:

"Amend Commit" and the Commit dialog, in general, for me has several
issues.

1. I can only populate the commit dialog with the last commit if I clear
   out all the text in the commit message, then clikc Amend Commit.
2. When I do the Commit after Step 1, it pops up the warning saying I'm
   going to rewrite history and all that. If I do that, it clears out my
   commit dialog and asks me to please enter a commit message. Perhaps the
   fact that I'm using a template messes it up.

Unrelated to the commits...if I have modified files but I forget to stage
them, I enter in my commit message, hit the commit button, confirm that I
want to stage and commit all changes via the commit dialog, then it clears
out the commit message and asks me to enter a commit message. Again, this
could be related to my template (not done via extensions but a
COMMITMESSAGE.txt handled by git itself).

—
Reply to this email directly or view it on GitHub
#565 (comment)
.

[mrexodia]

I have been looking into this a little bit, the checkbox for amending a commit works great, but the downside is that you cannot really undo changes that were made in the commit. The Git GUI (which is rather terrible) handles this nicely by including the changes from the last commit in the staging area:

Probably introducing this is a non-trivial change but I think it could be very useful!

[johndog]

Two issues, both of which have been mentioned:

• If there is text in the commit message window already, clicking amend won't clear it and replace it with the prior message. This is useful sometimes, but more often it's a worry that I have the wrong message, so I end up clearing the text, then clearing/checking the amend box again to bring it back.
  • Suggestion A: Color the message area somehow (text or background) to show that the text currently disagrees with the message at HEAD
  • Suggestion B: When clicking amend checkbox, if the text is different than the commit message for HEAD, always save it away, clear it and replace it with the text from HEAD. Then when clicking "commit", restore the saved text. This would accelerate a bunch of my workflows where I suspend a commit in progress (and its description) in order to amend the previous commit, and then resume.
• It's hard to review the amended commit in whole before commiting; it's hard to undo changes made in the HEAD commit.
  • Suggestion: Provide a toggle that changes the index view from being relative to HEAD^ to relative to HEAD. There are pros and cons to both views.

[GintasS]

@RussKie this is a duplicate, a new issue exists #2260 with recent activity.

[johndog]

#565 concerns the change description (which already does load, but only if the field is currently empty), #2260 concerns the modified file staging UI. If #2260 is reframed as "holistic experience when checking the amend box", it can subsume both.

[gerhardol]

Duplicate of #2260
The "amend experience" to be handled in one issue.