So I'm starting to lose faith in git, since I seem to be able to demonstrate it losing my changes. (Note: Not a gamedev project, this is from work) The file that's mystifying me is v5/employer/controllers/_employer.php. In the first image, you'll see that Brian changed the file in a commit on 14:55:47 called "time to commit stuff". But that commit's only child (second image), a merge operation Brian did at 14:56:45, does not show any changes to that file. But it's different! When you look at the actual contents of that file after the merge operation, you can see it's different than the version before it, but nothing shows up in the patch view. So basically, Brian's changes in that "time to commit stuff" commit got lost, at least for that file. Now if I run gitk --all v5/employer/controllers/_employer.php, I get the third image--which doesn't show the commit at all! What's going on here? Are we all crazy, or is git really losing our data? img96.imageshack.us/img96/850/figure1.png img190.imageshack.us/img190/7787/figure2u.png img704.imageshack.us/img704/7135/figure3.png

I've read your post several times, and I just don't see anything to do with game development. Maybe I have misread it, in which case I apologize.

It looks like you have confused gamedev.net, a site for discussing game development, with the git mailing list, used to discuss, diagnose, and fix possible bugs on the git version control system.

I suppose it is a natural mistake, as they both start with the letter 'g'.

Easy, frob. It's the Lounge. BeanDog has been here long enough to know which site he's on, I'm sure.

Sadly, I have no experience with Git; understanding scenarios like you've described is part of the reason why I'm presently avoiding it.

I started using git at home sometime last year and I'm really liking it.
I haven't noticed anything like that happen. But have you actually looked at the output of 'git log' or 'git blame' to see if the file in question actually has the changes in the history? If they were "lost" you can probably find out exactly where and why.
At work atleast, I find that sometimes merging files in perforce will cause things to get lost, because it randomly selects X as newer than Y when it really isn't and merges the file the wrong direction.

Are you sure Brian didn't screw up the merge? Was there a conflict (it looks like there was; Ben Dents also touched that file in a commit at 13:50, which is manifested in the --all log, as well as its children merge commits.)

It looks to me like two things are going on.

1) somebody screwed up a merge. which is why that file is "different", but doesn't show any over all changes. because it is different.

2) It kind of looks like that particular commit path is orphaned, like somebody is not working on a branch and just has a stream of commits that have a parent of branch "pop" but, or somebody rebased and orphaned a particular commit line.

I am pretty sure that --all doesn't really mean all commits, it means any commit that that is a child any referenced commit in refs/heads or refs/tags.

But due to git's distributed nature its hard to tell without looking at the repositories in question in more detail.

Yep, it's starting to look like it was a conflicted merge gone bad. The merge commit that's a child of "time to commit stuff" has another parent (obviously; it's a merge), and the note states there was a conflict in _employer.php.

We went back and walked through what happened in that merge. It turns out we used git gui's "Use remote version" to try and resolve the conflict rather than an external merge tool like meld, since the conflict was really trivial. As it turns out, that button doesn't just resolve conflicts with the remote version, it bulldozes the entire file with either the local or remote version it's merging from.

And since the file is identical to one of its parent commits, it doesn't show up as a modified file in that revision. That was confusing to me at first, since the file was changed after merging in another branch. But the reality is, I wasn't merging in a branch, I was merging two branches, and it might as well have been a merge in the other direction where the file genuinely didn't change.

Ugh. Well, it was user error (surprise, surprise). Let this be a warning to always use an external merge tool to resolve conflicts.

Another thing I noticed is that in your second screenshot, gitk's display mode is "tree" instead of "patch". In that mode it won't highlight changes, it just shows the raw file. The other screenshots are in "patch" mode.

The 3rd screenshot is trying to show some changes, but you'd have to scroll down to see them. You can configure how many contextual lines it shows (those unchanged lines before and after a change), and it looks like you guys have it configured to show lots of them.