Resetting HEAD To a Previous Commit in Time

[say25]

The ability reset my head to a previous state would be great 😄

Please describe the problem you think should be solved As part of my workflow sometimes I jump to a previous point in time on my branch.

I can be:

1. Rewriting history
2. Debugging a previous code state

[Optional] Do you have any potential solutions in mind? Resetting the HEAD of the branch should solve this.

[steveward]

Thanks for opening this @say25. For context, having a reset/rollback function was discussed previously in https://github.com/desktop/desktop/issues/2347 and https://github.com/desktop/desktop/issues/3474. Generally we are 👎 on this feature since it has previously caused quite a bit of confusion and various edge cases for users (see @shiftkey's comment).

Would having something like git checkout SHA or git checkout -b SHA be a potential solution here?

In your PR you also mentioned this:

I generally find myself wishing to go back a few commits to merge a typo commit or something of a similar sort.

Just to clarify so I understand -- are you wanting to amend a previous commit message (i.e. git commit --amend)?

[visutnam1]

สอนผมบ้างสิคับ ขอบคุนคับ

[say25]

@steveward So I guess why I don't like git checkout SHA as much is because I then end up a detached HEAD state. Similarly git checkout -b SHA puts me on a new branch.

Doing something like git reset --hard SHA lets me navigate to that point, tells me how many commits back I went, and doesn't change my branch. It would also let me experience how my project was at that point in time. Afterwards, I can simply pull the origin to get back to where I was on master.

Doing something like git reset --soft SHA lets me do everything from --hard AND lets me merge multiple commits (effectively rebasing though I guess I would need to force push from command line). It would also let me experience how my project was at that point in time provided I discard the new pending changes.

[niik]

Hey @say25, thank you so much for getting this discussion started. While I can definitely see how this feature could be useful even for myself I want to tread very gently here. My concerns are that resetting HEAD to an arbitrary commit is a very foreign concept to users not intimately familiar with Git and when resetting HEAD you can find yourself in a situation that's hard to get out of without a similar level of understanding of Git.

Our recently added "What is GitHub Desktop and who is it for?" document is of help in determining

when we have to choose between workflows for advanced Git users and workflows for beginner Git users, we prioritize beginners [...] This also means GitHub Desktop will likely not support workflows that are [...] different from the vast majority of developers.

I think this qualifies here. When considering new flows we have to take into account how use of such flows would affect beginners.

Doing something like git reset --hard SHA lets me navigate to that point, tells me how many commits back I went, and doesn't change my branch. It would also let me experience how my project was at that point in time. Afterwards, I can simply pull the origin to get back to where I was on master.

This assumes that the branch was already pushed to the remote, a beginner user doing this on a local branch would likely have troubles resetting back to where they started.

Doing something like git reset --soft SHA lets me do everything from --hard AND lets me merge multiple commits (effectively rebasing though I guess I would need to force push from command line). It would also let me experience how my project was at that point in time provided I discard the new pending changes.

Here we get into the opposite scenario of the one above where if the branch is pushed and the user resets back prior to the tip of the remote branch they're now faced with having to force push their changes which isn't a workflow we're supporting in the app at the moment and one that has gotten a lot of teams into a bind before.

Checking out a specific commit (i.e a detached head state) is at least not susceptible to the problems outlined above though there are obviously other issues to be considered there. With the current support for detached head in the app not having received a lot of attention I'd want to explore how the app behaves there before starting to think about implementations, most crucially I want there to be an easy escape hatch as well as a way to create a new branch from that specific SHA.

Rewriting history is a powerful tool in Git but also one of the more confusing areas and I would like to see us use a scenario based approach here rather than a Git-centric one. For example, I think editing of past commit messages should be straightforward in the app as long as they're not pushed to the remote yet. Behind the scenes we'd use various rewriting tricks to make such a feature work but the scenario is "Doh, I typoed that message two commits ago and I'd like to quickly edit it" and they way we accomplish that is an implementation detail.

Ultimately we're super thankful for the effort that you've put in here but we're not ready to add an unbounded reset feature into the app at this time.

[say25]

@niik this makes sense to me. Would it be worth supporting git checkout SHA or the -b variety?

[LordJashin32]

How does this help new users? It just scares them away more than anything. They get told to go to the command line to fix their problem. Which is the reason i never used Github's desktop app and stuck to using TortoiseSvn for years because i couldn't stand using command line to reset my repo. And in years it still hasn't changed. There can be options in settings to enable for advanced users while still benefiting beginners. Until thoughts on this subject change. I will have to use TortoiseGit or some other app. Back in the day TortoiseGit didn't exist and i was forced to use Svn because the command line git stuff used to scare me back then.

I think the novice user eventually runs into the oops my Fork is ahead commits so i can't make a pull request.

Not everyone is a command line wizard. Some of us mostly use GUIs. And Windows especially. And its a lot easier to use a GUI than remember the code to type to do a specific command you want to do at any time. For a novice they aren't going to remember ls, dir, rm, cd, git pull, etc, etc. They will have to lookup and type in the command every time. Until they memorize it because they looked it up so many times. I can't tell if this is focused toward novices or not. There's a split in thinking that i can't understand.

Sorry if my language here sounds harsh. I hope we can come to an understanding on this subject.

EDIT: I will personally help this if you guys want this feature in your app. I'd really like to avoid having to uninstall it.

EDIT2: The big thing with this. Is it makes the commit history nicer as well. Instead of having tons of "Revert" commits when you messed up.

[tierninho]

@LordJashin32 Thank you for your thoughts. Note, this issue was closed awhile back and will not be implemented.

[Diogo-Rossi]

@niik, @steveward

Checking out a specific commit (i.e a detached head state) is at least not susceptible to the problems outlined above though there are obviously other issues to be considered there. With the current support for detached head in the app not having received a lot of attention I'd want to explore how the app behaves there before starting to think about implementations, most crucially I want there to be an easy escape hatch as well as a way to create a new branch from that specific SHA.

Any news on that? I was looking for this in #8580.

It is not a advanced feature to start a new branch on a past commit. Many beginners would like to do that.

[mcmartincerny]

I've discovered a workaround that allows you to enable resetting to any commit you desire. Back in 2021, @sergiou87 introduced a reset to commit feature and merged it (#12393) into the master branch. Unfortunately, this feature was never enabled in the production release. Fortunately, you can easily activate it yourself by making a simple modification in the minified code located within your GitHub Desktop installation directory. I understand this is a somewhat unconventional fix, but there's a chance that the GitHub Desktop maintainers might not enable it themselves. Please note that you'll need to perform this modification each time you update GitHub Desktop. You might consider writing a script to streamline this process.

How to enable reseting on commits:

• Locate your GitHub Desktop installation directory. On macOS, it's typically found at /Applications/GitHub Desktop.app/.
• Open the file Contents/Resources/app/renderer.js
• Use your text editor's search function to find this.props.canBeUndone&& within the file and delete it.
• Restart GitHub Desktop, and you should find the feature working as expected!

It's important to note that this workaround only applies to local changes, and you won't be able to reset changes that have already been pushed to the remote repository.

Enabling resetting on any commit without restrictions:

• Open the file Contents/Resources/app/renderer.js once again.
• Search for this.props.canBeResetTo&&void 0!==this.props.onResetToCommit and replace it with true
• Restart GitHub Desktop, and you should now have the ability to reset to any commit without limitations.

[Gakk]

@mcmartincerny Please excuse me if I has misunderstood this issue, but I believe this already has been implemented with #16120 and released in 3.2.8?

[mcmartincerny]

@Gakk correct me if I am wrong but checking out commit like that leaves you with detached head. What I and a few other people really want is simple git reset --mixed <commit sha>. Which my dirty changes thanks to @sergiou87's PR enable you to do.

[steveward]

Requested in https://github.com/desktop/desktop/issues/17960.

[omnipitous]

@steveward So I was referred here from the above ticket only to find this is already closed as not gonna happen.. really??

Maybe I can describe the needed, very straight forward and 'safe', feature here: The user doesn't need to understand Head or what Commit they want to reset to or anything low level about Git.. The user, due to what seems to be bug either in Desktop OR Git itself, sees that their local branch is "dirty" (Hey I didn't make any changes but the UI is telling me there are changes to push and I absolutely don't want to mess up 'main'/Someone else's branch SO: Quick and easy button to reset Local to exactly what is on origin. no more, no less.

That is FAR better and safer than the user having to sort out why their local differs and potentially pushing breaking changes to 'origin'

git reset --hard origin/<branch name>

Yes I can, and currently have to, do that on the command line but there's no same reason to not support that in the UI.

[OrionSmedley]

Instead of resetting to a previous state, what do you recommend? I've merged branches into master, and also editted master. And then realized that all of these changes were bad. So, how do I go back to a previous state, and make that my main, if there is not reset? It would be annoying to click on every commit since then and click revert this commit.