Confused about "degenerate" combined diff for merge commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(Git newbie alert. Please be patient with me if I'm missing obvious
things...)

I'm converting a moderately large repository from Subversion to git.  As
part of the process, I'm experimenting with correctly representing
merges in the resulting git repository. In Subversion, we used commit
logs such as "Merged r1234:1279 from branch_xyz", so in most cases it
should be possible to use this information to create the proper parents
in git. I'm currently trying how well this works by using grafts; but
that's not the question.

Now, I'm using "gitk --all --merges" to look at my synthesized merge
commits; and I assume that I manufactured them correctly if the
resulting combined diff is empty.  I only expect diff output for merge
conflicts with a non-trivial resolution, i.e. neither ours nor theirs
was used to resolve the conflict. Is this assumption correct so far?

However, for some of these merge commits I see diff output such as this:

diff --cc Src/ClipBoard.cpp
index 4357ea0,4357ea0..3fad79a
--- a/Src/ClipBoard.cpp
+++ b/Src/ClipBoard.cpp
@@@ -71,7 -71,7 +71,7 @@@ AClipBoard* AClipBoard::SNew(
  
  AClipBoard* AClipBoard::SClipBoard()
  {
--  static AClipBoard* spClipBoard = SNew();
++  static TPtr<AClipBoard> spClipBoard = SNew();
    return spClipBoard;
  }
  
It looks like both merge parents had an identical diff here, so this is
not a conflict; why does diff --cc even show this to me?


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]