[ Don't cull Cc list, please! ]
Sergio Callegari schrieb:
> And if I experiment filter-branch again, with exactly the same
> parameters, apparently some of the files that did not get the new blob
> in the beginning do... which looks completely weird.
I think I know what's going on. filter-branch has this code where the
tree-filter is applied:
git checkout-index -f -u -a ||
die "Could not checkout the index"
This command may take a while to complete, and at the end it writes the
index file. At this point:
(=) Some files may have the same timestamp as the index file.
(<) Others have an earlier timestamp.
Later we have this code:
(
git diff-index -r --name-only $commit
git ls-files --others
) |
git update-index --add --replace --remove --stdin
The files (=) are racily-clean, and are added to the database; they pass
through the clean filter (rezip). The files (<) are regarded as unchanged,
and are not added again, and are not rezipped.
> find ./ -type f -exec touch \{\} \;
This could help, too, because now all files are regarded as either
racily-clean (same timestamp as index file) or as changed (newer timestamp).
-- 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
