Bug 490126 - Git Staging does not show the full commit when clicking "amend"
Summary: Git Staging does not show the full commit when clicking "amend"
Status: NEW
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 enhancement with 6 votes (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
Depends on:
Blocks: 353816
  Show dependency tree
 
Reported: 2016-03-21 18:22 EDT by Stefan Xenos CLA
Modified: 2023-09-13 02:15 EDT (History)
14 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Xenos CLA 2016-03-21 18:22:44 EDT
I'm not sure if this is a bug or a missing feature.

To reproduce:

Modify file A. Commit it to git.

Modify file B. Open the Git Staging view and click the "Amend" button.

Observed:

I see file B as unstaged, the commit message from the commit that modified A, but file A does not show up as a staged commit.

Expected:

I see file B as unstaged, the commit messages from the commit that modified A, and file A shows up as a staged change.

Also observe that this works correctly in "git gui", the GUI that bundles with command-line git.


This is a problem because:
- There is currently no way to use "amend" to remove existing files from a commit.
- When amending the commit, there is no easy way to preview the entire change you are editing.
Comment 1 Andrey Loskutov CLA 2016-03-21 18:27:40 EDT
Missing feature.
Comment 2 Matthias Sohn CLA 2016-03-21 19:59:49 EDT
bug 353816 and bug 459152 are related
Comment 3 Christian Halstrick CLA 2016-03-22 04:32:08 EDT
I think our staging view does not do the right thing after the "amend" button was clicked. Currently the staging view does show always
- Any difference between working tree and index in the top area "Unstaged changes"
- Any difference between index and HEAD in the bottom area "Staged changes"

In your steps before you do the last step (clicking the Amend button) there should be only listed b in the "Unstaged changes". If you do "add to index" on B "Unstaged changes" would be empty and "Staged changes" would contain be.

But: if you hit the "amend" button then this is more a hint for commit creation which will very likely follow. The created commit should have HEAD~ as parent and not HEAD. But in the moment you hit the amend button we don't change HEAD and index (which would be wrong I guess). And therefore also content of "Unstaged changes" and "Staged changes" doesn't change. I think we should compare index versus HEAD~ to fill "Staged changes" after the amend button was pressed. The area "Unstaged changes" should not be affected by this button.
Comment 4 Lars Vogel CLA 2016-04-07 17:30:47 EDT
+1 that feature would be super useful.
Comment 5 Lars Vogel CLA 2016-04-07 17:52:07 EDT
see also https://dev.eclipse.org/mhonarc/lists/egit-dev/msg04066.html
Comment 6 Eclipse Genie CLA 2016-07-13 05:33:31 EDT
New Gerrit change created: https://git.eclipse.org/r/77213
Comment 7 Dmitry Katsubo CLA 2018-09-19 16:19:23 EDT
I vote for this feature especially when doing the modification of commit during interactive rebase, e.g. in situation when group of files should be removed from the commit A3 and added to commit A2. Or (if other commits are just replayed / continued up to HEAD) left as unstaged changes on HEAD.

A1(HEAD)->A2->A3->...
Comment 8 Jorge Moraleda CLA 2023-09-13 02:15:17 EDT
I fully agree with the last comment. Being able to modify which files are added in a commit that is being edited during interactive rebase, and being able to edit the actual files at that point, both in the working directory and the index would be extremely useful. I am a former SmartGIT user and this is one of the features I miss the most. I vote for this feature.