When hiding untracked files, adding a folder adds also untracked files (git add instead of git add -u)

[clotodex]

Describe the bug
When hiding untracked files, adding a folder adds also untracked files (git add instead of git add -u).
This means you are also in the commit only shown a subset of the files that will be actually commited.

To Reproduce
In a repo, create a folder, add two files, track one file.
Then change the tracked file.
Open lazy git. Filter to tracked files (ctrl+b, t).
Now with space select the folder to commit.
Without your knowledge it also adds the untracked file.

Expected behavior
It should only add from the tracked files, if the view is filtered.

Version info:
commit=, build date=, build source=nix, version=0.45.2, os=linux, arch=amd64, git version=2.47.1

Additional context
There might be a reason to do it this way. If that is the case, at least a warning should be displayed.

[parthokunda]

Yeah, I think this is a problem. I will try to put a PR soon.

[parthokunda]

Sorry for being so late. I have been very busy for the last couple of weeks.
Anyway, I am a bit confused about how this thing will work. Suppose some untracked files were already staged before applying track filter. If I commit in that filter view what should I do?

• Keep the unstaged files in commit. This might be confusing like before.
• Only commit the files staged in current filter view.

Also, during unstaging in filter view, what should be the expected behavior?

In my opinion, when in filtered view, we should only consider files in current view for all things (staging, unstaging, commit). But this will complicate a lot of things and might be confusing in many use cases.

[stefanhaller]

Interesting questions. I don't use the filter feature much, but when playing with it just now, I found it confusing that untracked but staged files don't show up when I filter for only tracked files. In my intuition, a staged file already counts as a tracked file (even though I know that it technically isn't). So I would propose to simply include them (and, for symmetry, probably exclude them when filtering for only untracked files? Not so sure about that).

This would solve the problems you brought up, or am I still missing scenarios where it doesn't?

Here's a patch that does this:

diff --git i/pkg/gui/filetree/file_tree.go w/pkg/gui/filetree/file_tree.go
index 9ef980faa..5298f79e8 100644
--- i/pkg/gui/filetree/file_tree.go
+++ w/pkg/gui/filetree/file_tree.go
@@ -88,9 +88,9 @@ func (self *FileTree) getFilesForDisplay() []*models.File {
 	case DisplayUnstaged:
 		return self.FilterFiles(func(file *models.File) bool { return file.HasUnstagedChanges })
 	case DisplayTracked:
-		return self.FilterFiles(func(file *models.File) bool { return file.Tracked })
+		return self.FilterFiles(func(file *models.File) bool { return file.Tracked || file.HasStagedChanges })
 	case DisplayUntracked:
-		return self.FilterFiles(func(file *models.File) bool { return !file.Tracked })
+		return self.FilterFiles(func(file *models.File) bool { return !(file.Tracked || file.HasStagedChanges) })
 	case DisplayConflicted:
 		return self.FilterFiles(func(file *models.File) bool { return file.HasMergeConflicts })
 	default:

[clotodex]

That is a good point.
I still find the behavior of it adding the whole folder unintuitive but i can also see that for some people it might be the other way around.
This way, no matter the implementation you DO have a proper view of what will be committed though - which i like!

[stefanhaller]

I still find the behavior of it adding the whole folder unintuitive

Well yes of course. The patch above wasn't meant as the only measure we take, we still also want to do git add -u, which I understand @parthokunda is working on. The patch was only meant to address the issue that Partho was running into while doing that.

[parthokunda]

Interesting questions. I don't use the filter feature much, but when playing with it just now, I found it confusing that untracked but staged files don't show up when I filter for only tracked files. In my intuition, a staged file already counts as a tracked file (even though I know that it technically isn't). So I would propose to simply include them (and, for symmetry, probably exclude them when filtering for only untracked files? Not so sure about that).

This is a nice solution. However, if we unstage in tracked filter view, the untracked files will disappear. This might be a bit confusing, but nevertheless, seems like a good tradeoff to make.
Created a draft PR for now. Gonna clean this up hopefully tomorrow.

[stefanhaller]

However, if we unstage in tracked filter view, the untracked files will disappear. This might be a bit confusing,

I don't find this confusing at all. This is not really very different from filtering by staged files, and then unstaging a file (or vice versa); of course the file then disappears.

[parthokunda]

I have made a PR, kindly check at your convenience.

[AckslD]

Question, should this also happen when pressing a for staging all files, should all here mean all the files show currently, ie for example only tracked files if that filter is applied. That would make sense to me, if a user actually wants to stage also untracked files they can first remove the filter and then press a. Would such a change be reasonable or is it breaking existing behavior too much?

[stefanhaller]

@AckslD I think that's totally reasonable, and it was simply an oversight that this wasn't changed in this PR too.

The change would have to happen in toggleStagedAllWithLock in a very similar way to what was done in 7a1b631 (so WorkingTreeCommands.StageAll gets a new extraArgs parameter).

It's not a totally trivial change because there are other callers of StageAll that also want this logic (probably), so there's a bit of refactoring needed. Let me know if you feel like tackling this @AckslD, and I can give you some more thoughts; but honestly, for me it would probably be easier if I just make the change myself. 😄 I'll put it on the list.