I've been using git for quite a while now, and I consider myself a pretty 
advanced user.
I like GIT, but I think it is too complex for most people.
This has been illustrated by a change of a novice user who managed to undo 
a lot of changes in our repository,
without any traceability of these changes. This is not acceptable.
If a file was changed, I want this to be visible in the 'git log' listing.

This is what happened:
- Remote branch has commits A B C D E F
- User has commits A B C X Y Z

User does a pull and is presented with some merge conflicts.
Novice user does not know how to handle this, and brings his working tree 
back to the state he wants,
and in the process annihilates all changes of commits D E and F .

This causes the following graph:
- Remote: A-B-C-D-E-F--------M--
- User:   A-B-C-------X-Y-Z-/

However, in commit M (the merge) all changes of commits D E and F have been 
If however you issue a 'git log' command, this is not visible.
When looking at the log a file that was changed in commit F, no change is 
listed in commit M.
=> Changes done in a merge commit are not visible!

This means a merge commit is a free pass for anyone to make any changes 
they want,
without any traceability of these changes! (Not visible in log, not visible 
with git annotate, ...)
The only way to diagnose this is by manually diff'ing between the merge and 
it's parents to
see what exactly happened in the merge.

In my opinion, this is not acceptable.
If I remove a block of code in commit F, and this is reverted in the merge 
M, I would expect the following:
- git log shows that the file was changed in commit M (the merge)
- git annotate shows the lines in the file were added again in the merge M

I cannot believe that a file can be changed in a merge without GIT 
mentioning this in the log!

This is a serious turnoff for me...
I expect a versioning system to tell me exactly when and how a file was 
changed in all points in time.
GIT does this for regular commits, but merges present a loophole where 
anything can happen without easy traceability.
The VCS should not rely on the user knowing exactly what he/she is doing to 
guarantee correctness!

I would really appreciate any advice on this. Am I wrong in this vision, 
Maybe my viewpoint is wrong, but this is a no-go for a VCS for me ...
I hope someone can put this in another perspective ...

Best regards,

Dieter Van de Walle

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to