使用 Git 处理 subversion:忽略对跟踪文件的修改 [英] Using Git to work with subversion: Ignoring modifications to tracked files
问题描述
我目前正在使用一个 subversion 存储库，但我正在使用 git 在我的机器上本地工作.它使工作更容易，但也使 subversion 存储库中发生的一些不良行为非常明显，这给我带来了问题.
在拉下代码后有一个有点复杂的本地构建过程，它创建(并且不幸地修改)了许多文件.显然，这些更改并不意味着要提交回存储库.不幸的是，构建过程实际上是在修改一些被跟踪的文件(是的，很可能是因为有人在某个时候错误地将这些构建工件提交到了 subversion 存储库).由于这些是修改，将它们添加到我的忽略文件中对我没有任何作用.
我可以避免检查这些更改，我简单地不暂存或提交它们，但是具有未暂存的本地更改意味着我无法在不先清理它们的情况下重新调整.
我想知道是否有任何方法可以忽略对一组跟踪文件的未来更改?或者，有没有其他方法可以处理我遇到的问题，还是我只需告诉签入这些文件的人清理它们?
As ，这意味着滥用这个stateless 文件 content 通过添加有状态上下文(即被涂抹/清理的文件的完整路径名)进行转换.
这是 J.C. Hamano 明确禁止的:
虽然我最初考虑插入%P"；对于路径名，我最终决定反对它，以阻止人们滥用过滤器进行有状态转换，根据时间、路径名、提交、分支和其他内容来更改结果.
甚至 Linus Torvalds 当时对 all 机制有一些保留:
<块引用>我不得不说，我显然不是玩游戏的忠实粉丝，但差异非常干净.
它们实际上有用吗?我不知道.我有点担心这对于该功能的任何实际用户意味着什么，但我不得不承认我被一个干净的实现所吸引.
我怀疑这会引起我们的一些抱怨，但我也怀疑人们实际上最终会用这样的事情自欺欺人，然后责怪我们并造成巨大的痛苦当我们支持这一点并且人们想要扩展语义"时；不再干净.
但我不确定这个论点到底有多有效.我碰巧相信给他们绳子"哲学.我认为你可能会因此而自欺欺人，但是嘿，任何这样做的人只能怪他自己
因此，添加某种保存/恢复机制(并有效地忽略对 Git 中一组跟踪文件的任何更改)的正确位置应该是 钩子:
post-checkout:在更新工作树后运行 git checkout 时调用.在那里，您可以运行一个脚本来收集所有要忽略的文件并将它们保存在某处.pre-commit:在获取建议的提交日志消息并进行提交之前，您可以运行第二个脚本来恢复这些文件的内容.
I am currently working with a subversion repository but I am using git to work locally on my machine. It makes work much easier, but it also makes some of the bad behavior going on in the subversion repo quite glaring and that creates problems for me.
There is a somewhat complex local build process after pulling down the code and it creates (and unfortunately modifies) a number of files. Obviously these changes are not meant to be committed back to the repository. Unfortunately the build process is actually modifying some tracked files (yes, most likely because someone mistakenly committed these build artifacts at some point to the subversion repository). Since these are modifications adding them to my ignore file does nothing for me.
I can avoid checking these changes back it, I simple don't stage or commit them, but having unstaged local changes means I can't rebase without first cleaning them up.
What I would like to know is if there any way to ignore future changes to a set of tracked files? Alternatively, is there another way to handle the problem I am having, or will I just have to tell whoever checked in these files to clean them up?
As Nathan said, cleaning up those files (un-tracking them) is the smart move.
But if you must ignore tracked files (which is not the native Git way when it comes to ignoring files: Git only ignores non-tracked files), you can setup a process copying the content of files you want to ignore, and restoring on commit.
I initially believed that a smudge/clean process, that is a gitattributes filter driver could do the trick:
, where:
- the smudge process will make a copy of those files (when updating the working tree)
- some modifications take place during the build
- the clean step (during commit) will erase the files content with the copy made in step 1.
BUT, as stated in this post, that would mean abusing this stateless file content transformation by adding a stateful context (i.e. the full path name of the file being smudged/clean).
And that is explicitly forbidden by J.C. Hamano:
Although I initially considered interpolating "
%P" with pathname, I ended up deciding against it, to discourage people from abusing the filter for stateful conversion that changes the results depending on time, pathname, commit, branch and stuff.
and even Linus Torvalds had some reservations at the time about the all mechanism:
I have to say, I'm obviously not a huge fan of playing games, but the diffs are very clean.
Are they actually useful? I dunno. I'm a bit nervous about what this means for any actual user of the feature, but I have to admit to being charmed by a clean implementation.
I suspect that this gets some complaining off our back, but I also suspect that people will actually end up really screwing themselves with something like this and then blaming us and causing a huge pain down the line when we've supported this and people want "extended semantics" that are no longer clean.
But I'm not sure how valid an argument that really is. I do happen to believe in the "give them rope" philosophy. I think you can probably screw yourself royally with this, but hey, anybody who does that only has himself to blame
So the right place to add some kind of save/restore mechanism (and effectively ignoring any changes to a set of tracked files in Git) would be in hooks:
post-checkout: invoked when a git checkout is run after having updated the worktree. There you can run a script collecting all the files to ignore and saving them somewhere.pre-commit: you can run a second script which will restore the content of those files, before obtaining the proposed commit log message and making a commit.
这篇关于使用 Git 处理 subversion:忽略对跟踪文件的修改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
