I have one branch (let's call it B) that ignores a certain file, which isn't ignored in some other branches (eg branch A). When i switch from branch B to branch A, then back to B again, the file has been deleted.
Is this normal? I can sort of see how it would happen, in the sense that branch B thinks it's not there, and branch A thinks that it is, so when i go back to B it 'tidies it away'. But it's kind of annoying.
Any suggestions?
So if you switch to a different branch and there are no files in the commit that were added to different commit you can: Merge the other branch into the current. That brings all changes from the branch being merged — new files a re added, updated files updated, removed files removed.
If you already git add ed some files, their changes will still be tracked. To remove those files from your repository (but not from your file system) use git rm --cached on them. git rm --cached file_name. ext wroks fine for me to update gitignore for one file.
gitignore will prevent untracked files from being added (without an add -f ) to the set of files tracked by Git. However, Git will continue to track any files that are already being tracked. The removal of the file from the head revision will happen on the next commit.
Since the only viable solution is to track the file 'f
' at all times, you could add, only in branch B
, a smudge/clean process with a gitattributes filter driver:
When checkouting branch B
:
the smudge process would change:
f
in a temp filef
with one fbis
file (a tracked file which would contain, for branch B
, the "B
content of f
")the clean process would:
f
content (as modified in B
) in fbis
(fbis
gets committed with f
modifications in branch B
)f
content (with the temp file), meaning f
is not committed (ignored in B
)You can add, still in branch B
, a custom merge driver which will protect fbis
in case of merges from other branches to B
:
the merge driver will always keep B
version of fbis
content, making sure the ignored file f
gets back its content whenever branch B
is checked-out.
Since those drivers (filter and merge) are not committed in other branches, the file 'f' is committed in other branches with all its modifications.
In branch B
, its content will never change, and yet the "local modifications" made to f
are still restored whenever B
is checked-out.
If that content restoration is not needed, you don't need to manage fbis
.
Just keep the filter driver and you will be sure that whatever modification you do to f
in branch B
, those changes will never be committed, effectively ignoring f
content.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With