Peter Krefting:
However, as I have set the "ident" attribute, Git wants to expand it itself
and check in files with "$Id$". When I do a reset, it seems it records the
entry as clean against a version stored with just "$Id$", but the record in
history has an expanded "$Id$", and the entry is thus never deemed clean.
Actually, that is not the case. It seems to be the filter that causes the
problems, all by itself. I cannot seem to reproduce this *reliably*. I tried
setting up a minimal repository and a reproduction recipe, but I get
different behaviour when I perform the steps manually, and when I run it
from a shell script.
Here is the reproduction recipe:
#!/bin/bash
# Reproduction recipe for $Date$ dirty issue
ORIGINREPO=git://git.debian.org/users/peterk/gitfilterproblem.git
DESTINATIONREPO=gitfilterproblem-testrepo
# Set up repository
echo -- Cloning
git clone ${ORIGINREPO} ${DESTINATIONREPO}
cd ${DESTINATIONREPO}
# Status should be clean
echo -- After cloning, status should be clean
git status
# Set up filter
echo -- Set up filter, status should be clean
./reposetup.sh
git status
# Create tracking branch
echo -- Create tracking branch for changed file, status should be clean
git branch --track changed-text-files origin/changed-text-files
git status
# Merge the branch
echo -- Merge the changes from the branch, now status gets unclean
git merge changed-text-files
echo
git status
git diff
--
\\// Peter - http://www.softwolves.pp.se/
--
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