Hi, Matseitz_cisco: thanks for your extensive reply!
On Thursday, June 7, 2012 9:04:11 PM UTC+2, matseitz_cisco wrote: > > Is this because, from the point of view of the "User" branch, the > "Remote" commits of D, E, and F were never committed to "User"? So, > in branch "User", the file that was changed in commit F has never been > changed. In other words, commit Z and commit M have identical > content, so there is no change to report in 'git log'. > But isn't the goal of the pull exactly to integrate the remote commits in the local branch? When I look at the log, I also see the changes of both users (DEF and XYZ). My main problem is that when I ask GIT to show all commits that have changed a certain file (git log -- path/to/file), the merge commit is not in the list. So this creates a crazy situation: For example the last commit in the log list for this file says I added changeset X, so I would expect this change to be in the current version. However when examining the file, changeset X is not there! But the log says that the last change to the file added this changeset! Same thing for git annotate: git annotate says the source commit for the lines of changeset X is some commit far in the past that orginaly added the lines. However, these changes have been removed in commit X, and added again during the merge. However this is not visible. There exists a whole range of commits where this file is changed, but neither git annotate or git log make this visible.. Git log -m does not fix this. Although when doing git log -pm and examining the diffs, the revert is made visible. That's an improvement, but still pretty hard to find ... > > 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, ...) > > Would the changes become visible and traceable when they are pushed > back to the "Remote" branch? > In the situation where I saw the problem, all changes had already been pushed back to the remote branch. So I had user 1 committing and pushing DEF, and user 2 pulling, merging and pushing XYZ, resulting in a remote branch with changes DEFXYZ . However, after the merge the changes from commits DEF were lost. > - Remote: A-B-C-D-E-F-------+--N > | ^ > V | > - User: A-B-C-------X-Y-Z-M--+ > > At this point, when viewing commit "N", I would expect git to report > that in commit N the changes in D-E-F were reverted. > I don't think this is the case ... When checking out commit N and examining the files, you will see the changes are not there. But when querying the history of a affected file, git will report the last commit to the file was the commit ADDING the changes. Very confusing! When this occurs, you have to KNOW some merge commit probably changed something, and examine these merges in detail. However, I feel git should make this visible in some way. I would at least expect 'git log -- path/to/file' to show the merge commit because it affected the file! > > If I remove a block of code in commit F, and this is reverted in the > merge M, I would expect the following: > > But you haven't "reverted" the change from the perspective of the > "User" branch. Commit F was never committed to Branch "User", so it > is not "reverted" by this merge. > After the pull, commit F is part of the User branch right? So before the merge, the changes are present, and after the merge they are gone. So the affected files are most definitly changed! > 1. You are assuming that "git log" would show you the difference > between Commit F and Commit M. In fact, it only shows you the > difference between Commit Z and Commit M. The "git log" command shows > you changes between commits within a branch, not between branches. > Correct. 2. You are overlooking that running "git log" on branch "Remote" will > report the changes between Commit F and Commit M if and when Commit M > is committed back to branch Remote (as commit N). > All the changes were already pushed back to remote, so I don't think this is right? > Normally, "git log" shows you the changes within your branch. If > commit "M" is identical to commit "Z", then branch "User" has no > changes as a result of commit "M". > I would expect after both users have pushed their changes to remote, that both branches have been merged like this: A-B-C-D-E-F-M- I guess this problem would probably not have happened if the user did a 'git pull --rebase' right? I'm used to rebasing always before pushing to remote (git-svn user), so probably merging clashes with my rebasing way-of-thinking... I'll probably stick to rebasing, seems to fit a lot better with my expectations. Best regards, Dieter -- 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 https://groups.google.com/d/msg/git-users/-/Nft9p8iG4SMJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
