Can the discard functionality use other than git checkout?

[adilJamshad]

Is your feature request related to a problem? Please describe.
Some of the repos i work with have pre-checkout hooks and thus the discard functionality becomes really slow. Can discard functionality use any other command than git checkout?

Describe the solution you'd like
The discard changes functionality can work the same way but it can be done with so many other commands.

[ChrisMcD1]

There would be an alternative possible with git restore https://git-scm.com/docs/git-restore, but unfortunately the docs still have it tagged as "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

Do you have a particular discard flow in mind? If you want to clear your entire working directory, you can already do a Dx when on the files tab to discard everything with a git reset --hard HEAD && git clean -fd

If you want to discard a single file, I'm personally not aware of a 3rd option besides checkout and restore.

[adilJamshad]

@ChrisMcD1,
can we add -q flag to discard commands using git checkout. this won't trigger any post-checkout or pre-checkout hooks?

[stefanhaller]

-q doesn't feel like the right option to use for this, but git -c core.hooksPath=/dev/null checkout seems to me like an appropriate thing to do. The rationale is that we might also have implemented discarding as taking the current patch and applying it in reverse, in which case no checkout hook would run either. (I'm not suggesting we do that.)

Instead of hard-coding /dev/null we should probably use os.DevNull so that it works on Windows too.

[stefanhaller]

Here's a PR: #4313. @adilJamshad Could you test if this works for you?

[TimShilov]

@stefanhaller @jesseduffield Sorry for jumping in on a closed issue but I would argue that this change is a mistake. 🤔

Once again, my favorite tool is causing troubles for me because you try to satisfy the creator of an issue instead of critically evaluating the request and considering if it even makes sense or not. 😩

IMO, lazygit (which is a git UI) should not disable any git functionality! 🤔
The git itself runs a hook on every checkout and there’s a reason for that! Some people might use that hook and depend on it.
Also, other tools (for example, Jetbrains IDE’s) also run those hooks on file resets, so by disabling them you are creating inconsistencies between tooling. This might potentially make lazygit users an annoying teammates as their stuff might not work as everyone else’s. 😅

If the hook is slow - that’s a problem with the hook, not the tool that’s triggering it.

If you don’t want the hook to run on file checkouts - git has you covered, as it provides a flag to the hook to determine whether or not checkout is a branch checkout or a file checkout:

The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0).
https://git-scm.com/docs/githooks#_post_checkout

Given that, I would argue that the previous functionality of lazygit was correct and there was no need to break it and rob the people of functionality they might’ve depended on!

It’s a responsibility of the hook developers to make sure the hook makes sense!
Otherwise, we might as well disable all hooks as at some point people will say that post-merge hook is slow. 🤷‍♂️

[ChrisMcD1]

Hm, I was not aware that post-checkout hooks were provided with a flag telling them if they were branch-based or file-based! Interesting...

Re-reading the initial issue, and the linked docs page, I'm also noticing that @adilJamshad you are talking about pre-checkout hooks, which I am not seeing mentioned in the docs anywhere. Are you using some 3rd party extension that gives you more hooks?

Seems to me though that it would be a reasonable revert, and the offending slow hooks could be updated to only act on branch changes (assuming that is a valid resolution).

[adilJamshad]

@ChrisMcD1 husky is being used to run post-checkout hooks after every checkout. I noticed the behavior difference between lazygit and git in vscode. it makes complete sense what @TimShilov said. but i believe that post-checkout hook isn't executed when a user discard a file in vscode and other IDEs, then can this functionality be replicated on lazygit? The reason behind suggested this change isn't "post-checkout hook is slow", the reason behind suggesting this change is not to run post-checkout hooks on discarding files which seems a universal functionality for all the IDEs as well.

[stefanhaller]

@TimShilov Strong words again. I appreciate your input, but I reject the accusation that we did this without thinking.

My rationale for changing it was that we are not talking about a "checkout" command here; we are talking about a "discard changes" command. The fact that we are using git checkout under the hood is an implementation detail; as I said above, we might also use something along the lines of git diff -- <path> | git apply -R to implement it (not exactly like this, but you get the idea), in which case no post-checkout hook runs either, and why should it. This would be equivalent to entering the file using enter, selecting all lines (e.g. using v >) and hitting d; this also discards all changes, but doesn't run any hooks. Again, why should it.

Now, if your complaint had been that we went too far with this and also disable the hooks when checking out a file from an older commit using c in the commit files view, then I would totally agree. That was pure laziness, it was easier to implement this way, but it was a mistake, and I'll make a PR soon to fix this.

Once again, my favorite tool is causing troubles for me

You didn't say in what way this causes trouble for you. Can you elaborate?

[stefanhaller]

Now, if your complaint had been that we went too far with this and also disable the hooks when checking out a file from an older commit using c in the commit files view, then I would totally agree. That was pure laziness, it was easier to implement this way, but it was a mistake, and I'll make a PR soon to fix this.

Here's the PR for this: #4371.

[TimShilov]

@adilJamshad

I noticed the behavior difference between lazygit and git in vscode.
... but i believe that post-checkout hook isn't executed when a user discard a file in vscode and other IDEs, then can this functionality be replicated on lazygit?

To the best of my knowledge, that's not true. Please correct me if I'm wrong.
I have just double-checked, and both VSCode and IntelliJ Idea execute post-checkout hook when you discard a change in the list of changed files. Try adding say "Hello" (if you're on Mac) to your hook and then discard changes in any of them to see it.
Of course, it might depend on the version of Git and editor configuration but, I believe, default behavior is to run the hook in both of them.
So, lazygit was behaving exactly like the 2 most popular code editors and the git itself.

Separately, as I've mentioned above, it is very easy to prevent your hooks from running on file checkouts.
Just add this at the top of your hook:

# flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0)
# https://git-scm.com/docs/githooks#_post_checkout
flag=$3
if [[ "$flag" -eq 0 ]]; then
    exit 0
fi

If the hooks being slow is causing problems for you - it must be causing problems for your teammates as well (whether they are using lazygit or not). They will likely thank you if you fix the hook for everybody.

---

@stefanhaller I'm not saying that you weren't thinking, and I apologize for my tone. I'm just saying that for the second time you've implemented someone's request by taking away from other user's workflow. If you satisfy one user and disappoint another one - in my picture of the world that's a zero sum and nothing is really achieved.
In fact, the perception of the tool changes towards "constantly breaking and unreliable", which is not fair as the tool you've built is amazing! 😬
That said, I will keep more civil tone next time, and will try to contribute to the project to actually provide some value instead of just complaining. 😅

Now, about your rationale.

why should it

Because that's how git works, that's how all code editors I've used work, and that's what I, as a user, expect from lazygit.
Again, if git itself runs a hook, why wouldn't a 'simple terminal UI for git commands' run it as well?

You didn't say in what way this causes trouble for you. Can you elaborate?

The reason it caused trouble for me is that one of the projects I work on uses post-checkout hooks on file checkouts to do some maintenance (installing dependencies and running builds).
For example, when I discard a change to the package.json file in a Node.js project - I expect to be able to run the project right away and have all the dependencies in place.
In a monorepo setup, when I discard a change to one package, I expect it to be rebuilt automatically so other packages can use it.
Without the hook I have to:

1. Discard changes
2. Pause and consider what change(s) I have actually discarded to think if I need to reinstall dependencies or rebuild anything. More than that, I have to think where that change actually was to know where to run manual checks (I work on a monorepo with 100+ packages).
3. Run npm install or tsc manually (potentially in multiple places across the codebase)
   If I don't do steps 2 and 3, then my dependencies are in an unknown state and the project might run incorrectly (or not run at all).

After I have updated lazygit my expectations were no longer true. I kept working as usual, but sometimes I spend time working on something, I hit an error and realize that hooks were skipped, I have to manually run command to do whatever the hook is supposed to do, and then start from scratch. That is a waste of time, so the update was disruptive to my workflow.
That, of course, just one example and probably is a rare use case, but a use case that git allows nonetheless.

We can of course consider using reverse patch to discard changes but I, personally, don't see any need for that. At the very least, I would suggest making it a separate hotkey (something like dX?) or an option because I believe lazygit should default to the git behavior.

One thing, I hope we all agree on, is that a breaking behavior like that shouldn't be included in the patch release. 🙏