Redundant entries added to .gitignore when user selects "Ignore" in the Changes tab menu

[justinTM]

Description

From the Changes tab, if the user selects an item (file, directory, etc.) > right clicks > "Ignore", then a duplicate entry is added to the .gitignore file.

Example:
If the file .DS_Store is marked "Ignore" for, say, 100 times, then 100 copies of .DS_Store entry will be added to the .gitignore file, regardless if it already exists.

Version

GitHub Desktop version: 0.8.0

OS version: OS X El Capitan, version 10.11.6

Steps to Reproduce

1. [First step]
2. [Second step]
3. [and so on]

Expected behavior: Ignore the ignore; check if the file already exists. If it does already exist, ignore the user action (silently or with a message to the user).

Actual behavior: Infinite duplicates of the already-existing .gitignore entry can be created regardless of existing matching entries.

Reproduces how often: Always (not intermittent).

Logs

Additional Information

[shiftkey]

This behaviour occurs due to the fact that Git will only apply gitignore rules to untracked files - once a file is tracked it doesn't care about your .gitignore file contents.

One way to ensure that you can't get into this loop would be to discard the changes to the tracked file as part of this operation, but that doesn't address the underlying issue about how to handle already-tracked files that the user wants to ignore - do we delete the file so that it can be committed?

[shiftkey]

@justinTM can you confirm that the file you were trying to ignore is already tracked in Git?

[justinTM]

@justinTM can you confirm that the file you were trying to ignore is already tracked in Git?

@shiftkey Yes, the file .DS_Store was tracked (and committed) before the entry in .gitignore was created; my bad!

I would suggest the issue still remain open, as there could be some improvement to this functionality, regardless of my brain fart? :)

[shiftkey]

@justinTM all good, just adding some context as to what Git is doing here

[shiftkey]

Looking into what we'd need to change here:

• onIgnore only takes in a string representing the new pattern here and here - we'd need to pass information about the file back to the dispatcher.
• onIgnore also supports wildcard expressions - I'd probably leave that behaviour alone here because going through the repository to remove all track files matching some extension feels like overreach.
• Dispatcher.ignore() would also need to know about the file, so it can pass this through to the GitStore
• AppStore._ignore() could look at the AppFileStatus of the changed file and discard the change (optionally?) if it's a modified file

[shiftkey]

If someone wants to take a shot at this, I've added some guidance above.

[shiftkey]

Dropping this from the milestone as the work requires some additional thought around UX - see #3164 (comment) and replies

[JeanCollas]

Thanks, I am happy that you already know the issue, I hope it will be fixed soon.

[bartclaeys]

Seems like this issue hasn't been fixed yet?

[phantomdesvin]

Hi. It would be ideal that, when the user adds something new to ignore, if there are tracked files that match that ignore command, GitHub Desktop could bring a message like “The following files are already tracked so they won’t be ignored. Select the files that you wan’t to untrack so they can be ignored from now on” and some visual interface for untracking those files. That would keep users from making this mistake and would improve the workflow as right now you have to use the command prompt to untrack files.

[gabessdsp]

Just wondering if there are any updates to this?

[WaGi-Coding]

Pretty annoying issue, hope it gets resolved in the next few decades already.
Wasted so much time on this already. I thought Github Desktop will make things easier, in fact it does not if you do not follow a workflow they want you to follow ^^

[Birgerev]

Three year old issue, any fix planned? This thing has been annoying me since the day I started using the desktop app, is there any workaround or temporary fix?

[justinTM]

It appeared to me as if Brendan implied it was an error between chair and screen (i.e., NotABug/WontFix). Good luck.

…

On Dec 15, 2020, at 3:51 AM, Birger Evansson ***@***.***> wrote:  Three year old issue, any fix planned? This thing has been annoying me since the day I started using the desktop app, is there any workaround or temporary fix? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vaidasma]

Bump! seems this has been an issue since 2017, is this still being investigated?

[lfkdev]

Still a big problem.