git has modified files after clean checkout

here's what I did

rm -r portage
git clone git@github.com:xenoterracide/portage.git
cd portage
git checkout origin/regen2 -b regen2
git status

# On branch regen2
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:
x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff
#       modified:
x11-themes/metacity-themes/files/metacity-themes-1.2-gentoo.diff
#
no changes added to commit (use "git add" and/or "git commit -a")

why are there files claiming to be modified? this is a clean clone.
I've had this before I usually end up doing a git reset --hard HEAD,
but I'm thinking it's a bug, since I've seen it vary on the same clone
and sometimes even disappear.

git version 1.6.0.6
-- 
Caleb Cushing

http://xenoterracide.blogspot.com

On Wed, Dec 31, 2008 at 12:23 PM, Caleb Cushing [off-list ref] wrote:

here's what I did

rm -r portage
git clone git@github.com:xenoterracide/portage.git

Here's the anonymous clone URL (the one you provided is private)
    $ git clone git://github.com/xenoterracide/portage.git

Read on below...

cd portage
git checkout origin/regen2 -b regen2
git status

# On branch regen2
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:
x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff
#       modified:
x11-themes/metacity-themes/files/metacity-themes-1.2-gentoo.diff
#
no changes added to commit (use "git add" and/or "git commit -a")

why are there files claiming to be modified? this is a clean clone.
I've had this before I usually end up doing a git reset --hard HEAD,
but I'm thinking it's a bug, since I've seen it vary on the same clone
and sometimes even disappear.

git version 1.6.0.6
--
Caleb Cushing

http://xenoterracide.blogspot.com

I followed the steps above and did not run into any such issues.

$ git status
# On branch regen2
nothing to commit (working directory clean)

$ git version
git version 1.6.1.28.gc32f76
(Junio's latest master at the moment)

Here's my quick guess based on what I'm seeing --

The files you mention contain CRLF.  Do you have core.autocrlf set
globally somewhere, perhaps in your ~/.gitconfig?

It's possible that the autocrlf stuff is messing with those files.
They seem to be a mix of both unix LF and CRLF (the CRLF stuff doesn't
start until line 104 of
x11-themes/metacity-themes/files/metacity-themes-1.0-gentoo.diff, for
example, which is kinda odd but maybe be intentional?)

Check your autocrlf settings.
The following commands print out nothing for me:

    $ git config core.autocrlf
    $ git config --global core.autocrlf

Anyways.. like I said -- I couldn't reproduce your problem so this is
pure speculation on my part =)

Good luck,

-- 
    David

 The files you mention contain CRLF.  Do you have core.autocrlf set
 globally somewhere, perhaps in your ~/.gitconfig?

yes I have it set to input

 Anyways.. like I said -- I couldn't reproduce your problem so this is
 pure speculation on my part =)

it's inconsistent although I see something more often than not, and
only with this particular repository. Sometimes it's one set of files
other times it's others. this time it was 2 sometimes it's more like
40 (just throwing numbers around) and that can be the same unchanged
clone. seem to happen on checkout. heck even noticed a git reset
--hard HEAD didn't clear it all the first time today, in one case.

after sleep I'll see if 1.6.1 fixes my issue.

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Caleb Cushing wrote:

quoted

 The files you mention contain CRLF.  Do you have core.autocrlf set
 globally somewhere, perhaps in your ~/.gitconfig?

yes I have it set to input

Do you have any .gitattributes?  A few days ago, ludde on IRC bumped
into the problem that git-checkout applies the .gitattributes that are
present in the tree *before* the checkout.  Naturally this means that
the .gitattributes do not apply at all during the first checkout at
the end of cloning.  In ludde's case, this caused git-blame to think
the file had all line endings changed compared to the index version.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Do you have any .gitattributes?  A few days ago, ludde on IRC bumped
 into the problem that git-checkout applies the .gitattributes that are
 present in the tree *before* the checkout.  Naturally this means that
 the .gitattributes do not apply at all during the first checkout at
 the end of cloning.  In ludde's case, this caused git-blame to think
 the file had all line endings changed compared to the index version.

no, no .gitattributes to my knowledge (file doesn't exist). but it's
not just during the first checkout.

# On branch regen2
# Your branch is ahead of 'funtoo/funtoo.org' by 1 commit.
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   app-admin/petrovich/files/petrovich-1.0.0-gentoo.diff
#       modified:   app-cdr/mode2cdmaker/files/mode2cdmaker-1.5.1-gentoo.patch
#       modified:   app-crypt/mhash/files/mhash-0.9.9-mutils-align.patch
#       modified:   app-crypt/rainbowcrack/files/rainbowcrack-1.2+gcc-4.3.patch
#       modified:   app-crypt/rainbowcrack/files/rainbowcrack-1.2-share.patch
#       modified:   app-crypt/rainbowcrack/files/rainbowcrack-1.2-types.patch
#       modified:   app-editors/leo/files/leoConfig.py.patch
#       modified:
app-emacs/aspectj4emacs/files/aspectj4emacs-1.1_beta2-browse-url-new-window-gentoo.patch
#       modified:
app-emacs/aspectj4emacs/files/aspectj4emacs-1.1_beta2-compile-log-gentoo.patch
...
that continues on for a while, all that was done was a git pull funtoo
funtoo.org

I haven't had time to test 1.6.1 yet


-- 
Caleb Cushing

http://xenoterracide.blogspot.com

testing 1.6.1 release (not head) and still see the issue. right now
I'm assuming disabling autocrlf = input would help. regardless is this
behavior a bug or anticipated?

-- 
Caleb Cushing

http://xenoterracide.blogspot.com