2

Today i typed git commit without the file name i was thinking of, and strange things happened.

usually it would just tell me "use a filename or -a, dummie", but this time it showed:

$ git commit -m "some change"
[master 1d75411] some change
 37 files changed, 1566 insertions(+), 1189 deletions(-)
 create mode 100644 fileA
 create mode 100644 fileb
 [...]
 delete mode 100644 fileC
 delete mode 100644 fileD
 [...]

and those changes are already appearing on the server! like if i did a push or merge!!!

Everything is exactly the same as before despite the file i was trying to commit anyway.

No file was deleted, no file was changed. Unix permissions are the same as before!

What happened?!

Edit: now, after every two commits, this happens:

$ git status
 * nothing changed *
$ git diff
 * nothing *
$ edit somefile
$ git commit -m "some change" somefile
[master f875c5b] some change
 21 files changed, 4 insertions(+), 1563 deletions(-)
 delete mode 100644 fileA
 delete mode 100644 fileB
 delete mode 100644 fileC
 [...] (somefile does not even appear on the console output, only if i get log later)

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   fileA
#   new file:   fileB
#   new file:   fileC
[...]

$ git commit -m "re-add files? why?"
$ git push

$ git status
 * nothing changed *

$ git diff
 * nothing *

$ edit somefile

$ git commit -m "some change" somefile
[master f875c5b] some change
 21 files changed, 4 insertions(+), 1563 deletions(-)
 delete mode 100644 fileA
 delete mode 100644 fileB
 delete mode 100644 fileC
 [...]

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   fileA
#   new file:   fileB
#   new file:   fileC
[...]

That's it. i will just take that i'm not smart enough for git and host this project in Subversion. Do not need much history at this stage anyway, so it can be lost for now.

I may give it another go after i have the time to read the git book entirely.

thanks for trying to help, but this just got too weird and unproductive.

also, out of curiosity to someone, my work flow so far have been (two months doing this and everything was fine until today)

$ git fetch
$ git merge origin/master master
$ edit file
$ git add somenewfile
$ git commit -m 'something changed' file somenewfile
$ git push
gcb
  • 12,288
  • 7
  • 58
  • 86
  • `git ls-tree ` shows the same for all files that were allegedly changed by the commit "100644 blob ..." – gcb May 30 '11 at 19:59
  • 1
    Something appears to be messing with your index (where Git records “staged” content) behind your back. It looks like maybe the index is temporarily missing (causing apparent deletions when the index is “missing” and then apparent additions when the index is back). Do you have any hooks (in `.git/hooks/`) active (executable, and not ending with `.sample`)? What OS are you using? What filesystem are you using to hold your working repository (network share? non-standard local filesytem?)? – Chris Johnsen May 31 '11 at 06:52
  • @Chris Johnsen, i'm running that locally on a Ext4 filesystem over raid1. No hooks. – gcb Jun 08 '11 at 21:59
  • I simply got rid of that repo. i had created it following the docs from gitosis. using all stable versions, nothing bleeding edge. never knew what happened. – gcb Aug 15 '11 at 02:05
  • The best lead i got hunting this down was -a in my .gitrc or whatever the rc file for git was called. but it wasn't the case for me. – gcb Aug 15 '11 at 02:06

2 Answers2

2

Since no one can explain this, i'm closing assuming it's a bug.

leaving here just if someone search this in the future.

i've sent the logs to the devs, never heard back, but since there's a few revisions after the one i was using, i will just assume it was fixed... but i will never know since not using git on this project anymore.

gcb
  • 12,288
  • 7
  • 58
  • 86
0

Just looks like the normal behaviour when your specify files in your commit command :

http://git-scm.com/docs/git-commit :

File>…

When files are given on the command line, the command commits the contents of the named files, without recording the changes already staged. The contents of these files are also staged for the next commit on top of what have been staged before.

Romain
  • 186
  • 7