There is a config/auth.js file in my github repository (which has many forks) I want to ignore any further changes to this file. After searching I found the following three ways but none of them is working for me :
1. git rm --chaced
this deletes the file.
2. git update-index --assume-unchanged config/auth.js
this is working on my machine but then every contributor will have to run this command on his fork as well(which i do not want them to do).
3. git update-index --skip-worktree config/auth.js
same problem as case 2
Basically i dont want others to know anything happened and when the sync their fork(rebase) the changes in the file are ignored autmatically.
Any solution to do what you're asking is going to have a ton of "behind the scene's magic" that could go very wrong at any time; I don't recommend it.
The problem is that if you want to ignore their change to a given file, but you don't want them to see any effects of what you've done, then you necessarily need to be looking at a different set of commits than they are. For example, if you have
x --- x --- x <--(master)
and they clone, so they have
x --- x --- x <--(origin/master)(master)
and then they make some changes, including an edit to the config, so they have
x --- x --- x <--(origin/master)
\
O <--(master)
for your repo to "ignore" the change to the config file means that you'll end up with
x --- x --- x --- O' <--(master)
after incorporating their changes. O' is necessarily a distinct commit from O. The client will expect to see O at origin/master and indeed it would be very disruptive if you presented them with the "reality" that origin/master is now at O'.
So to keep things working neatly, you have to store O and represent to the fork that the upstream of master points to O. Given that you have more than one fork, each of which might have its own changes to your config file, you have to either:
1) Create a "bridge" repo for each fork, and thereby change the remote URL they use to address you,
or
2) Maintain in your origin repo a separate set of branches for each fork, requiring the forks to configure an appropriate refspec.
So truly making this change "invisible" just isn't possible. Assuming you want the "lighter weight" of those two options - which I believe would be (2) - you would end up with something like
x --- x --- x --- O <--(master)
\
O' <--(fork-a/master)
and now you'd have to use hooks to automate rebasing of changes between master and fork-a/master (while filtering changes to the config file out of the rebases). I see nothing but opportunities for disaster there.
The other option (bridge repos) still looks pretty much like the above. It just keeps things from looking even worse in any single repo, given that you actually have many forks. It structures how changes flow between forks I guess, but then you have to coordinate between all those repos.
I can't see either of those really working.