3

10 something commits back, I made a change to .gitignore file. Today when I pulled the latest code, my change was not there. So I ran this command:

git log -p .gitignore

And it showed me that the last change to the file was mine. Then I pulled all the commits between now and my commit, and pinpointed the commit that removed my change. Then I took the diff of That commit, and the one before that, and in the diff I could see the change to the file.

But why can't I see the change through above command? And I don't even see this change when I use 

gitk .gitignore

Also I am wondering, might this happen when I try to see the history of some other file as well?

Sylvain Defresne
  • 42,429
  • 12
  • 75
  • 85
Saad Rehman Shah
  • 926
  • 2
  • 10
  • 28
  • Are you sure it's all happening on the current branch? You might want to use --all with the log, and check your diff options (do you have .gitattributes?) – sehe Dec 21 '12 at 14:33
  • `git log --all .gitignore` also shows my commit as the last one. What is .gitattributes? I don't see it in the .git folder. – Saad Rehman Shah Dec 21 '12 at 14:36
  • [`gitattributes`](http://git-scm.com/docs/gitattributes) is used to explicitly tell git how to handle certain (or all) files. The `.gitattributes` file is not there unless you create it. About your question: Do you have anything in .git/info/exclude (which also has .gitignore patters, but those are not local-only). – Nevik Rehnel Dec 21 '12 at 17:36

1 Answers1

0

Maybe change you're talking about was introduced by merge with another branch? There are different merge strategies, and despite your commit might be chronologically last one, the merge procedure might prefer older commit which complies with the strategy rules.

By default git uses recursive strategy which will arrange commits in the order they was created. But maybe in your case merge was done using ours and heirs strategy preferring commits from one branch over commits from another. That's why you might not see what you actually expect.

Please visit this Q&A to get more information on strategies.

Community
  • 1
  • 1
shytikov
  • 9,155
  • 8
  • 56
  • 103
  • The change that undid my code, was indeed a result of merge. And since one member of team is actually outsourced from another company to work on the same project our team is working on, and he uses a turtoisegit instead of typing commands in the shell, It's very likely that his version of git used some other strategy. There is no way of finding out what strategy was used to make the merge, is there? – Saad Rehman Shah Jan 18 '13 at 11:33
  • As far as I remember, there is no way to find out for sure about strategy. But it's definitely possible using common logic. If you see that in your log commits are not chronological, despite they should... this was none-recursive merge. You should ask the company did this merge to start following common practice. For example this link would help: http://nvie.com/posts/a-successful-git-branching-model/ Despite it might look a bit complex it makes sense. At least one advice should be considered — merge with `--no-ff` flag. This at least will not toss all your commits during merge operation. – shytikov Jan 18 '13 at 11:54