Improvements to Stash Staged changes.

[donperi]

Is your feature request related to a problem? Please describe. Yes. Currently when using Stash Staged changed I noticed some things that can be improved.

1. Two stashes are created unnecessary.
2. Sometimes it errors telling that the selection can't be stashed.
3. When it succeed, the stashed files are keep in the index (I would expect to be removed).

Describe the solution you'd like I think the steps to stash staged files can be simpler. I currently use SmartGit which has an option Stash Selection When looking into the output, the git command ran is:

git stash push --include-untracked -- FILE_1 FILE_2

With this info the steps to reproduce this command could be.

1. Get list of staged files
2. Unstage all changes.
3. Run the command like SmartGit.

Screnshots Error in LazyGit

Two stashed were created.

Version info: LazyGit Version: commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=darwin, arch=arm64, git version=2.43.2 OS: MacOS Sonoma 14.1

Describe alternatives you've considered N/A

Additional context I'm happy to work on this if the improvement makes sense.

[mark2185]

Could you please fill out the rest of the template, e.g. which version and/or OS you're using?

[donperi]

Updated, I used the Feature Request template, it doesn't have version info.

[stefanhaller]

This sounds more like a bug than an enhancement request.

However, I just did a quick test and the command worked correctly for me: it created one stash, didn't pop up any error, and removed the stashed changes from the working tree (leaving the unstaged changes there).

It would help if you could come up with a more concrete recipe for how to reproduce these failures.

git stash push --include-untracked -- FILE_1 FILE_2

This stashes both staged and unstaged changes, so we can't use it here. (Note that lazygit supports the scenario where you have both staged and unstaged changes within a single file.)

[donperi]

I noticed that that it happens with specific files. In this case with very big files. I'll try to create a file that I can share to replicate this.

Note that lazygit supports the scenario where you have both staged and unstaged changes within a single file.

👍 Thanks, I missed this.

[stefanhaller]

I found a way to reproduce it; it seems to happen whenever staged and unstaged changes in the same file are too close. (Not sure that's the only way to trigger it.)

To reproduce, make changes to two lines that have one or two unchanged lines between them; stage only one of the changes. This will trigger the behavior described above. If there are three or more unchanged lines between the changed ones, it works fine.

I haven't yet looked into why it fails, or what we can do about it.

[dsolerh]

I have looked into this issue and found this in the git docs:

-S
--staged
This option is only valid for push and save commands.

Stash only the changes that are currently staged. This is similar to basic git commit except the state is committed to the stash instead of current branch.

and I tried this doing the following: 1- Create file1.txt and commit with content: 2- Create file2.tx with any content: 3- Modify file1.txt with the following:

4- Select in lazygit to stage file2.tx (all content) 5- Select in lazygit to stage from file1.tx:

6- Open a terminal and paste: git stash push --staged 7- The output in the stash is:

And file1.txt now has:

The issue that I get is that I cannot apply/pop the stash after that, since I get this error:

[dsolerh]

I tested the behaviour of the git stash push --staged in "normal" circumstances and it's working as intended, so unless there's a problem with this command that I don't know of I think that is a cleaner approach to "Stashing all staged files"

[stefanhaller]

Ah nice, I wasn't aware of the --staged option. Yes, that's obviously better and also solves the problem of #3563, so it seems that we don't need #3568 then.

The problem is that the option was only added in git 2.35.0, but we need to support 2.20.0 and later. We have two options:

• fall back to our current implementation for versions older than 2.35.0, (and then live with the two bugs that it has)
• disable the command for versions older than 2.35.0

I could go with either option, but I have a slight preference for the second because it's easier for us. I'll let @jesseduffield decide what to do.

As for the error that you got when popping the stash: that's normal git behavior. You get the same error, for example, when trying to apply a custom patch for a file that has unstaged changes. The workaround is to stage your unstaged file first, then it will succeed in both cases. I admit that this is very unintuitive, and also the error message is quite confusing, but that's git's problem, not ours.

[jesseduffield]

I also wasn't aware of that option. I stash staged changes all the time so that's going to be useful.

2.35.0 was in 2022 and I don't want to force users to update their git unless it's quite old (i.e. older than 2022) so I think we should use the fallback approach.

[stefanhaller]

I don't want to force users to update their git unless it's quite old (i.e. older than 2022)

This sounds like you're contradicting yourself. Isn't this saying that you find it ok if users have to update their git if it's older than 2.35.0? I'm confused. (Also, we are not "forcing" users to update their git; only if they want to use the stash staged changes command.)

[jesseduffield]

@stefanhaller I meant to say much older than 2022. Some users seem to very slowly update their git versions (e.g. because they're on OS's with old git versions and because of some company policy they can't update).

As for forcing users to update: it's all on a spectrum. The more useful the feature is, the more that it should be considered 'forcing'. I consider the stash staged feature very useful, and I assume many other users do too.

On net I think it's going to be better for users to support pre 2.35.0 git for stashing staged changes.

[dsolerh]

So, In summary, for users with git version older than 2.35.9 the flow remains the same, and for users of this version an higher the git stash push --staged is used, is that correct?

[dsolerh]

I can add the needed changes to the current PR https://github.com/jesseduffield/lazygit/pull/3568 or create a new one for this but since the changes are related there could be conflicts if they are separate.

[jesseduffield]

So, In summary, for users with git version older than 2.35.9 the flow remains the same, and for users of this version an higher the git stash push --staged is used, is that correct?

That's right

I can add the needed changes to the current PR https://github.com/jesseduffield/lazygit/pull/3568 or create a new one for this but since the changes are related there could be conflicts if they are separate.

Feel free to add the changes to the current PR

[stefanhaller]

No, I would close #3568 and create a new one instead. We don't need the changes in #3568 any more. It would only unnecessarily complicate the code with too little benefit.

[jesseduffield]

To be clear: that PR only helps users on the old git version? If that's the case, I'm okay with keeping the code simple and requiring users on the old git version to upgrade if they want the better behaviour.

[stefanhaller]

Yes, the new version doesn't need the fix.

[stefanhaller]

It's also an uncommon situation for people to have only staged changes, and then to invoke the "Stash staged changes" command. Most people will probably invoke the default stash command in that case.

[jesseduffield]

Good point

[dsolerh]

Makes sense to me