Repository navigation
Files from HEAD commit should appear as staged when 'amend' is checked #256
Description
Originally filed as #251
@maxbrunsfeld wrote:
Also when amending, you may want to unstage changes that were previously committed.
I believe what he meant was "you may want to reset changes that were previously committed" so that they show up in the Staged Changes list (as opposed to the Unstaged Changes list)
This is a really interesting feature request and I can see how that would provide a nice user experience. Though to implement it we would have to change the state of the users repo in a way that they might not expect to happen from just clicking a check box. We would essentially have to move HEAD to the previous commit by doing reset --soft head~, and if the user un-checks the amend box we would have to reset --hard HEAD@{1}. Not sure if this is going beyond what people would feel comfortable with by checking a box.
This seems like maybe it could be an additional feature outside of amend. Perhaps it's worth considering how we could build a UX around reset --soft head~ that makes it clear that we are changing the state of the user's repo. Though perhaps this belongs in later milestone, post-staff ship?
Thoughts @maxbrunsfeld and @simurai 💭
Activity
maxbrunsfeld commentedon Sep 23, 2016
I don't think we'd want to make any change to the user's repository. I would think that we'd implement this behavior by changing the information that we display in the lower list when the box is checked. Instead of showing a diff between the index and the HEAD commit, we'd show the diff between the index and HEAD commit's parent, because that's the diff that represents the commit we're trying to create. I'm pretty sure this is what other git GUI programs do.
Without this behavior, I think amending is pretty confusing: the
Stagedlist is not showing you the full content of the commit you're about the create. You have to remember what you previously committed in order to understand what changes the final commit will contain.maxbrunsfeld commentedon Sep 23, 2016
The reason I initially thought of this as one issue (#251) is that if we implement this behavior (which I think we need to in order to provide a good amending experience), there is no need for special logic to enable the commit button with no staged files (#255). When amending a non-empty commit, there will be staged files.
kuychaco commentedon Sep 23, 2016
Ah okay. That makes sense. That feels more to me like an interactive rebase to me where you're amending the last commit, or doing a reset soft and committing again.
I like this as a feature and can see how it could be an intuitive UX for many. Personally, my first thought is that this would be unexpected behavior, but maybe that's because I'm so close to Git and thinking too low-level. I'm coming around to the idea of it, but I'd like to brainstorm ways we can be more explicit with how we present the information.
Here's why I think it would be unexpected:
I think of checking the
amendbox as simply applying the--amendflag on the next commit, which is exactly how it's currently implemented. And any changes I currently have staged, will be included in a new commit that also has all the changes in my last commit. So for instance if my last commit was to rename a variable and that touched 10 files and I realized I missed a rename, I only want to see that one missed rename in my Staged Changes list, as opposed to having it be cluttered with the 10 other files which would make it impossible to find the change that I'm actually introducing with the new commit.Also, I expect that what is displayed in my Staged Changes list will always reflect what git shows me when I type
git status. To implement what you're proposing we would need to display something different in the Staged Changes list if the amend box is checked, and this would not reflect what the user would see as the changes staged for committing outside of Atom.That said, you're right that the changes from the last commit will be included in the newly created commit, so it's a bit intuitive to have them listed in the Staged Changes list even if Git doesn't list them.
I do think this could be a good feature, but perhaps we would want to explicitly list these changes in a separate section that could be displayed below the Staged Changes, not sure what it would be called. And it might be confusing to have a file in both the Staged Changes list and this other list... and that still doesn't give the user a file diff that shows all cumulative changes...
At any rate, it seems like implementing this well would be complex from both a UX and code perspective.
maxbrunsfeld commentedon Sep 23, 2016
Here's the interaction in Gitx, the git GUI that I've used the most. Checking the box, the staged list becomes the diff with
HEAD~, and the Commit button becomes enabled.To be fair, here's another app called Tower that actually behaves more like this package does today, where it displays the diff with
HEADeven when you're amending.I generally agree with the philosophy of matching the behavior of git commands, but I don't think
commit --amendis the right comparison in this case. Our checkbox is a way of entering an 'amending' state, at which point you can continue to browse your changes for however long you want, and then at some point later, commit. In my opinion, the closes CLI analogy for that would begit reset head~; git status; git commit.simurai commentedon Sep 23, 2016
Here some wireframes if we wanna do
amendandsoft resetseparately (same as Tower). Note: Soft reset is only possible once there is a commit history list. Also: In the wireframes, the staging area still has the checkboxes, but just imagine it had the two lists.Amend
Clicking the commit button will create a new commit.
Enabling Amend and clicking the Commit button will add the changes to the previous commit. There could be an ⬇️ making it more clear that your changes will be part of the previous commit.
Reset
So it would be:
Amendto add new changes or edit the commit message. It's more light-weight and feels safer.Resetto change anything.You could reset or "rollback" multiple commits, I guess all the ones that didn't get pushed yet. So that you could squash them into a single commit or split them up differently.
nathansobo commentedon Sep 23, 2016
I definitely want to see the contents of
HEADin the staged file list so I can unstage, like GitX.nathansobo commentedon Sep 24, 2016
Sorry, I feel bad for just drive-by-ing my 2 cents without reading in depth. Guess we can talk at the minisummit because once we do it this way people will be mad if we take it away. It is something I use all the time though in my workflow. Maybe 2 steps could be okay if we still made it convenient to reuse the commit message. Maybe. But that UI is a ways off and on the meantime I would really like to live in this UI 100%. It was the same way in the early days of Atom. It was annoying as hell to use until we had a certain feature set, then I could happily dogfood it.