Am 4/11/2011 11:31, schrieb Miklos Vajna: > On Mon, Apr 11, 2011 at 02:49:21PM +0530, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote: >>> Is this a bug? I don't exactly understand why this would be necessary. >> >> From config.txt: >> - 'clean' is "The command which is used to convert the content of a >> worktree file to a blob upon checkin". >> - 'smudge' is "The command which is used to convert the content of a >> blob object to a worktree file upon checkout." >> >> According to the documentation, 'smudge' is *supposed* to be invoked >> on a clone/ pull, since it involves a checkout. I don't see how you >> can avoid running these filters on every checkin/ checkout unless you >> cache the result somewhere. > > That's not a problem - the issue I pointed out is that the 'clean' one > is invoked on pull/clone, and it takes time if it's applied to several > files. The invocation is only needed when files are marked as "racily clean", because in this case git has to check whether the worktree contents are what is recorded in the index or not. This can happen a lot when you have a fast machine where many worktree files and the index itself can be written within the same (wall clock) second. You example is so short that it triggers this case almost reliably. When git pull merges the fetched commit, it has to determine whether there are no changes in any of the files that are to be updated by the merge. If one such file is marked as racily clean, the worktree contents must be inspected, which in turn means that the clean filter has to be used. If you insert before the final 'git pull': sleep 1 git reset sleep 1 you will notice that some clean filter calls happen before the 'git pull' because git 'git reset' rectifies the racily-clean entry. This just explains what you observed. I haven't thought about how you should change your workflow to avoid this behavior. My guess is that the extra clean filters called by 'git pull' don't actually happen that frequently during normal interactive work that touches the index. Perhaps you are also bitten by a regression in 'git status', which does not correct the racily-clean entries even though it should (fixed in git 1.7.4.4.), and therefore the clean filter is run more often than necessary. > > 'smudge' is just a 'cat', I don't care about it. :) Then you can just remove it from the config and save a fork(). You don't have to configure both clean and smudge filters. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html