-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intelligent Amend Commit #565
Comments
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? |
+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. |
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 ;) |
Those angle brackets you used (visible in the email) are invisible on the site. For those interested, his patch format is ": <title>" |
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. 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. |
+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. |
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?
|
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. |
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. |
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. 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. |
Introduces a check box for Commit Amend that replaces the previous Amend button in the Commit dialog. When the Amend Commit box is checked, it will load the commit message of the previous commit, and the Commit button will result in a "commit --amend". Ideally in the future, when the box is checked, the staging area on the the left of the Commit dialog can include changes from the previous commit for easy amending. This is intended to address issue gitextensions#565
Does anyone have any more brainstorming ideas on how to address this? Conceptually, do you think it is more intuitive to:
|
Amend checkbox it's ok for me, but changing commit message to previous commit message on selecting combobox is confusing. |
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? |
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. |
Introduces a check box for Commit Amend that replaces the previous Amend button in the Commit dialog. When the Amend Commit box is checked, it will load the commit message of the previous commit, and the Commit button will result in a "commit --amend". Ideally in the future, when the box is checked, the staging area on the the left of the Commit dialog can include changes from the previous commit for easy amending. This is intended to address issue gitextensions#565
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 |
"Amend Commit" and the Commit dialog, in general, for me has several issues.
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). |
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
|
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! |
Two issues, both of which have been mentioned:
|
Duplicate of #2260 |
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.
The text was updated successfully, but these errors were encountered: