Whatever method you use, you will probably want to include the configuration filename in a. The special treatment required for your configuration file would be just another step that one must perform while recovering from the rewrite:
#SMARTSVN REMOVE FILES FROM REPOSITORY MANUAL#
This amounts to rewriting history, which will require manual intervention for each branch/repository (see “Recovering From Upstream Rebase” section in the git rebase manpage). If it is unacceptable to maintain the content in the repository then you will likely want to completely eradicate it from history with something like git filter-branch -index-filter …. Rewriting History Requires Manual Intervention Anyway… With such a defaulting mechanism in place, users should be able to pull a commit that renames foo.conf to without having to do any extra work.Īlso, you avoid having to manually copy a configuration file if you make additional installations/repositories in the future. Makefile or similar)) to launch/deploy your software, you could incorporate a defaulting mechanism into the launch/deploy process: test -f foo.conf || test -f & a script or some other program configured by content in the repository (e.g. Or, if the users already use some existing part of the repository (e.g. If it is not completely unacceptable to continue to maintain the configuration file's content in the repository, you might be able to rename the tracked file from (e.g.) foo.conf to and then instruct your users to cp foo.conf after applying the rename commit.
Keep File as a ‘Default’ and Manually/Automatically Activate It
#SMARTSVN REMOVE FILES FROM REPOSITORY SOFTWARE#
In a comment, you mention that the file you want to “untrack, but keep” is some kind of configuration file that is required for running the software (directly out of a repository).
If they have taken other actions since pulling your deletion (or they are pulling with rebase into a detached HEAD), they may need something other than They could use git log -g to find the commit just before they pulled your deletion. Or with git checkout (per comment by William Pursell but remember to re-remove it from the index!): git checkout - foo.conf & git rm -cached foo.conf If they have already pulled your deletion commit, they can still recover the previous version of the file with git show: git show >foo.conf Restore File as Untracked After Pulling a Commit That Deletes It To resolve such conflicts, use git rm foo.conf & git rebase -continue (if the conflicting commit has changes besides those to the removed file) or git rebase -skip (if the conflicting commit has only changed to the removed file). If they are pulling via rebase and are ‘carrying’ modifications to the file, they will get conflicts. Probably the easiest thing to do is to tell your downstream users to save a copy of the file, pull your deletion, then restore the file. I do not think a Git commit can record an intention like “stop tracking this file, but do not delete it”.Įnacting such an intention will require intervention outside Git in any repositories that merge (or rebase onto) a commit that deletes the file.
0 kommentar(er)
