Community
Participate
Working Groups
Git amend should populate the committer/author information with the last commit values by default. In some development scenarios where a developer decides to amend quite often it gets frustrating to provide those information over and over again.
Pushed to master: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6283a86389639a067e2f66a290558941434b890d Checking only the amend flag will cause to automatically fill in the latest commit message for the client. If one decides to check the flag and provide a message, the latest commit will be overwritten as requested. In case the user didn't provide the committer name and/or email a popup will still open.
I cannot confirm this fix, running latest git master. Clicking the amend checkbox does nothing visibly. It also does not send an XHR to fetch the old commit. When I click the [More] link (with Amend checked), I see XHR finished loading: "https://my.local.server:8443/gitapi/commit/HEAD/file/adrian/autoSaveText/?page=1&pageSize=1". xhr.js:140 The previous commit message is crammed into the Message: field, but line breaks are lost (most importantly the two newlines setting off the top summary line from the rest). I can only copy, paste this messages, cancel out with [x] and start over with the amended commit and the salvaged, single-line text, from the clipboard. I would say this is still broken, at least in my scenario. The only other thing I see in the JS console worth mentioning is this: The page at 'https://my.local.server:8443/git/git-status.html#/gitapi/status/file/adrian/autoSaveText/' was loaded over HTTPS, but displayed insecure content from 'http://www.gravatar.com/avatar/042d8ebd24bf86bd98a76a8233f275e9?d=mm': this content should also be loaded over HTTPS. git-status.html:1
Adrian, did you encounter any other trouble with git commands? It sounds to me, like there's a problem with blocking content and hence the script hasn't been executed. The git amend command should check for the flag you've provided, and invoke a call, waiting with a 'Commiting changes' message. Can you please describe the steps to reproduce in detail?
(In reply to Maciej Bendkowski from comment #3) > Adrian, did you encounter any other trouble with git commands? It sounds to Not that I'm aware of. I use many git repos: some init-ed directly from within orion. some cloned from github. some cloned from my server, but created previously outside orion. > me, like there's a problem with blocking content and hence the script hasn't > been executed. The git amend command should check for the flag you've > provided, and invoke a call, waiting with a 'Commiting changes' message. Can > you please describe the steps to reproduce in detail? Here is the details: I realize the last commit I it had a typo. I am still in the git-status.html and click the [Commit] button again, with no new staged changes. A new, empty, editable Commit message: textarea#nameparameterCollector.parameterInput opens. I click the Amend [ ] checkbox and notice how the commit messages stays empty. No XHR is issued according to JS console. I click the [ More ] button (<button class="dismissButton">More</button>, dismissButton looks strange to me) Anyway, now I can see XHR finished loading: "https://apa.selfhost.eu:8443/gitapi/commit/HEAD/file/adrian/autoSaveText/?page=1&pageSize=1". xhr.js:140 and the now popup shows the previous commit change "Message:" text all crammed into one line. Shouldn't clicking the Amend checkbox immediately load the full original commit message into textarea#nameparameterCollector.parameterInput where it can be comfortably edited? Does not happen for me.
(In reply to Adrian Aichner from comment #4) > I realize the last commit I it had a typo. > I am still in the git-status.html and click the [Commit] button again, with > no new staged changes. > A new, empty, editable Commit message: > textarea#nameparameterCollector.parameterInput opens. > I click the Amend [ ] checkbox and notice how the commit messages stays > empty. > No XHR is issued according to JS console. The amend is a git commit flag, and as such, not a separate command. In order to actually amend your commit, you have to enable the amend flag and hit 'Commit'. If you leave the message text box empty, the commit comment will not be changed. Can you confirm this is what you have done?
(In reply to Maciej Bendkowski from comment #5) > (In reply to Adrian Aichner from comment #4) > > I realize the last commit I it had a typo. > > I am still in the git-status.html and click the [Commit] button again, with > > no new staged changes. > > A new, empty, editable Commit message: > > textarea#nameparameterCollector.parameterInput opens. > > I click the Amend [ ] checkbox and notice how the commit messages stays > > empty. > > No XHR is issued according to JS console. > > The amend is a git commit flag, and as such, not a separate command. In > order to actually amend your commit, you have to enable the amend flag and How/where do I "enable the amend flag" in the GUI? I am doing this from the git-status page. What is your exact use case for amending a commit to fix a spelling error in a previous commit? > hit 'Commit'. If you leave the message text box empty, the commit comment > will not be changed. Can you confirm this is what you have done?
(In reply to Adrian Aichner from comment #6) > How/where do I "enable the amend flag" in the GUI? Click the Amend [ ] checkbox. > What is your exact use case for amending a commit to fix a spelling error in > a previous commit? Click 'commit', click the 'Amend' checkbox, type your new message in the 'Commit message' text box and hit 'Submit'.
(In reply to Maciej Bendkowski from comment #7) > (In reply to Adrian Aichner from comment #6) > > How/where do I "enable the amend flag" in the GUI? > > Click the Amend [ ] checkbox. > > > What is your exact use case for amending a commit to fix a spelling error in > > a previous commit? > > Click 'commit', click the 'Amend' checkbox, type your new message in the > 'Commit message' text box and hit 'Submit'. Maciej, I am trying to help you make orion competitive. When you run git commit --amend from the command-line in a git directory it will initialize your favorite editor (see end of man git-commit) with the contents of the last commit message. Now you can just edit the typos in the old commit message, save, and quit the editor. The [More] button in the orion Commit UI already loads the previous message in a single-line Message text field, when the Amend flag is checked (I have mentioned this a number of times now). Clicking the Amend checkbox should just populate an empty textarea with the previous commit message. Then I could start using orion for amending commits.
Adrian, thank you for the detailed explanation of your use-case. Unfortunately, the current commandParameter API does not support parameter manipulation nor event callbacks (as e. g. checkbox onCheck), before they are passed to the command. The commit message fetch is done in the commit command body and therefore it's populated in the commit dialog. I'll open a separate bug for the parameter manipulation.
Created attachment 235349 [details] Make Amend an option for the Commit button
Comment on attachment 235349 [details] Make Amend an option for the Commit button Thanks for the background information and opening of the new Bug 416908. How about moving the Amend checkbox up besides the Commit button? That way it would be known at click time the commit is an amending one. Seems also well inline with "git commit --amend" where amend is an option one can pick. See my attached picture.
(In reply to Adrian Aichner from comment #11) > How about moving the Amend checkbox up besides the Commit button? I think it's a neat solution and could be easily turned into a generic one. This way we'd have command flag support. The only obstacle I see at the moment is the UI for such options. The command flag should not influence workflows which do not require additional functionality. In case of the 'commit' command we do not have any other commands attached to that same section, so a flag at the left side is fine, however, if we would want to apply flags to commands, which are rendered somewhere in the middle of all available commands, e. g. 'reset' which could have also other flags, then we encounter a problem, how to render this command, so it doesn't require additional user actions like an additional 'click'.
(In reply to Maciej Bendkowski from comment #12) > (In reply to Adrian Aichner from comment #11) > > How about moving the Amend checkbox up besides the Commit button? > > I think it's a neat solution and could be easily turned into a generic one. > This way we'd have command flag support. The only obstacle I see at the > moment is the UI for such options. The command flag should not influence > workflows which do not require additional functionality. In case of the > 'commit' command we do not have any other commands attached to that same > section, so a flag at the left side is fine, however, if we would want to > apply flags to commands, which are rendered somewhere in the middle of all > available commands, e. g. 'reset' which could have also other flags, then we > encounter a problem, how to render this command, so it doesn't require > additional user actions like an additional 'click'. Thanks for looking into this! I can see how general git command options support in the Orion UI would get us in deep waters pretty quickly. On the other hand I find amending a commit (based on the the full text of the last commit) a very mainstream activity which might well justify the UI I suggested. Adding an [Amend Commit] button instead would be another possibility, but I hesitate to even suggest that. So I would still support my initial idea of moving up the Amend checkbox from the popup to the commit button :-)
Closing as duplicate of 425241. This way we can track the issue in a general gerrit workflow context. *** This bug has been marked as a duplicate of bug 425241 ***
