New undo last commit/amend breaks workflow

Description

The changes introduced to undoing a commit/amending to a commit with #1364 breaks a lot of workflows.

Until 1.26. it was possible to do the following things, which are now impossible:

• Click the amend checkbox, this would display all then changes from the last commit in the staging area, this allowed you to:
  • Easily see the changes from the last commit without having to undo
  • Easily remove from, add to or replace in the last commit (whole files, as well as individual lines)
  • Before actually amending the last commit I got a 'preview' of what it would look like (which files/lines are included) in the staging area

Instead now all I have is an amend without any preview, and an undo which irreversibly rewrites history as soon as I click it.

This was a great tool, that can't be reproduces with normal Git and that is now gone.

Please either bring the checkbox back or give me the ability to bring it back. The new version is a massive step backwards functionally in my eyes.

Old amend checkbox

Versions

1.27.0

[MarionCrp]

I agree ! Loved the amend commit functionality ! (what about a "enabled" checkbox in settings ? )

[DzmitryBiruk]

Yeah i agree,
This changes broke my workflow

[gjtorikian]

I also loved the amend checkbox. Where did it go?

[smashwilson]

One of our design priorities with this package is to maintain fidelity with the reality of git's state on disk. There are a lot of advantages to doing this: you can change context seamlessly between Atom and any other git tool, including the command line, even mid-operation; the diff markers in the gutters are accurate; you don't lose any work if you close and re-open Atom; and so on.

The previous behavior of the amend checkbox was one of the only places in the package where this was not the case. It caused us a lot of headaches and was the root cause of some fairly subtle bugs. After quite a bit of consideration, we replaced it with the implementation we have now, which does maintain that fidelity. "Undo" is actually a bit more powerful now, too: you can undo several commits in sequence and re-commit them in different chunks, like a rebase-lite.

Easily see the changes from the last commit without having to undo

With a clean index, undo and commit are symmetric options; if you click undo and commit without changing anything, the HEAD commit is the same... with the exception of its timestamp, so the commit SHA does change.

• I would like to provide a better, first-class way to view the content of a previous commit. More thoughts on that later.
• It might also be interesting to preserve the commit's timestamp if you don't modify anything else, so the SHA wouldn't change if you undo and immediately re-commit. We'll have to think about that one.
• Another thought is to visually distinguish between commits that have and have not been pushed yet, because commits that have been pushed are riskier to undo.

Please either bring the checkbox back or give me the ability to bring it back. The new version is a massive step backwards functionally in my eyes.

One of the downsides of making design changes in a product with as many users as Atom is that we're going to make someone upset as we iterate. It won't be the last time, and I for one appreciate the level of diplomacy on display here so far 😉

Sharing concrete use-cases that aren't supported is helpful - it gives us more data to see how these features are actually being used, and either come up with solutions that help you accomplish the same tasks in a new way, or consciously take them out of scope and decide not to support them. (We can't support everything after all!)

[gjtorikian]

I must be going blind, actually -- I didn't even see that undo button until you mentioned it. For me, personally, 99% of my use cases are just adding one more file / hunk to a previous commit -- and the last 1% is rewriting a mistyped commit message.

So yeah, the undo button works for me. ☺️

[essenmitsosse]

Thanks @smashwilson for the reply and clarification. I definitely understand your reasoning. Lets just refer to that XKCD: https://xkcd.com/1172/

Being able to get back the commit that was just undone would solve 90% of the issue for me. How about adding a button, that does something like git reset HEAD@{1}. Of course it would be awesome if Atom would be able to decide if a new commit is necessary or if it can just restore the old one. But for the time being just being able to quickly redo the undo from the UI would make the workflow possibilities far more what they used to be.

This basically means:

Old	New
Tick amend checkbox	Undo Button
Untick amend checkbox	Button/context menu that does something like git reset HEAD@{1}

[simurai]

@gjtorikian For me, personally, 99% of my use cases are just adding one more file / hunk to a previous commit

For that use case, there is now an "Amend" option in the context menu when right-clicking the last commit.

Amend	Undo
——————————————————————	——————————————————————
I forgot to add something to my last commit	I want to "edit" my last commit (add/remove changes, rewrite commit message, add/remove co-authors)
Right-click -> Amend	Click "Undo" button

[gjtorikian]

Whoa, even better!

[essenmitsosse]

@simurai I was aware of that feature but I admittedly misphrased that a bit.

The amend feature doesn’t solve the initial problem: being able to see the last commit or the result of a potential amend, while still being able to get back to the original commit without history rewrite in case no amend turns out to be necessary.

what is needed is the ability to redo an undo so i can securely move the last commit into the staging area.

[simurai]

see the result of a potential amend

Yeah, I can see that being useful. 👍 When clicking on "Undo", it might be hard to manually untangle the "amended" changes again.

what is needed is the ability to redo an undo so i can securely move the last commit into the staging area.

One way could be to keep the last commit, but have it look disabled and add a button that says [Redo undo]:

But that looks quite confusing. 😆 And might bring back the "subtle bugs" mentioned above ☝️

Something we could consider for the future: Be able to see the preview of an "Amend". But first we would need some sort of multi-file diff.

Or be able to squash two commits with a preview. And other options like reorder commits or edit the commit message. Then you don't have to worry too much about the history while you make commits and can do it later before you push.

[essenmitsosse]

Something we could consider for the future: Be able to see the preview of an "Amend". But first we would need some sort of multi-file diff.

That`s basically what the old "amend" checkbox used to do.

But yeah, that redo undo button would be great.

And just using git reflog internally should make the implementation native to git und thus hopefully avoid any subtle bugs.

[gliviu]

I just lost some important changes when I had some files staged and accidentally pressed the undo button. This new feature is a complete hazard.
Not to mention it is totally counter intuitive. I'm working with git for a couple of years now, still it took me quite some experiments to understand how the new proposal is supposed to work.
My opinion - this should definitely be rolled back.

[mpacer]

I just want to chime in that this massively breaks my workflow. This was one of my favorite features of Atom's git integration — I didn't know it if you had asked though. It was so smooth a feature that I didn't even realise how great it was. But now… I'm hobbled.

I frequently use it for both use cases: editing the commit message and adding/removing changes after a bit more of development time.

But in particular it is great because I end up toggling back and forth frequently when I'm trying to decide whether things should be in their own commits or joined with others. It allowed me to not need to make a decision while still seeing what things would look like without triggering any githooks (which can sometime get pretty weighty and slow).

I appreciate the considerations regarding the symmetry of the operation and its fidelity to git (not to mention subtle bugs). But, one of the greatest aspects of a UI built on top of git is the way that it can expose functionality that would be hard to express in the original set of operations that dramatically ease the use of a tool known for its trickiness.

I know it's unlikely, but please consider adding the toggle back as a configurable option that is off by default but still available for those who rely on it.

[jrial]

@smashwilson Tx for the clarification.

As others have already mentioned: the two common use cases for the "amend" checkbox were:

1. Quickly add a small chunk that was forgotten
2. Reword the last commit message

Both of these can be achieved with the new "undo" button, but "undo" is an ambiguous, and therefore scary word. Especially in the context of a tool that has a gazilion barrels, all aimed squarely at your foot (git, not Atom). How about "Soft reset", "Uncommit" or "Restage" instead? Additionally, a tooltip could be added to the button that clarifies "This undoes the last commit, but keeps its changes in the staging area".

Anyway, some remarks on some of your other points:

With a clean index, undo and commit are symmetric options; if you click undo and commit without changing anything, the HEAD commit is the same... with the exception of its timestamp, so the commit SHA does change.

Then it's not a symmetric option. But it can be made symmetric by adding a "redo" or "recommit" button, which others have also brought up. This button would check out the commit again, unmodified, whilst preserving the other changes on the staging area. I think this is an elegant solution to the problem brought up by the OP:

• The undo button can be used to view the changes from the last commit (they're in the staging area), and to pile on extra changes if required prior to committing.
• The commit button will commit whatever is on the staging area, so if extra changes have been piled on, or the commit message was changed, this will also be included in the new commit.
• The redo button would redo the commit that was previously undone, unmodified. Any other changes from the staging area remain in the staging area. The order of operations is simple: stash current changes, check out the commit's SHA, pop the changes.
• At all times, the parity between on-disk and Atom is maintained.

I would like to provide a better, first-class way to view the content of a previous commit. More thoughts on that later.

I suggest showing the standard diff view currently used for preparing the commit, upon selecting the commit in question. But if you're thinking something more powerful, by all means. :)

It might also be interesting to preserve the commit's timestamp if you don't modify anything else, so the SHA wouldn't change if you undo and immediately re-commit. We'll have to think about that one.

If nothing has changed, the commit button could simply check out the commit SHA rather than performing a new commit. But this is an optimisation that is entirely optional IMHO; if we have a "redo" button, there's little need in complicating the functionality of the "commit" button.

Another thought is to visually distinguish between commits that have and have not been pushed yet, because commits that have been pushed are riskier to undo.

Please also add a popup, warning of the dangers of doing so, with a "don't show again" tickbox for those of us who know what they're doing.