Re: How to tell what paths changed in a merge?

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

 



On Mon, Mar 28, 2011 at 03:48:01PM -0400, Patrick Doyle wrote:

> I have a situation where somebody got confused while trying to
> commit/push/pull from the repository and some changes to some files
> got lost.
> 
> How can I tell which files got selected in a merge?

I'm not exactly sure what you mean by "selected". A merge commit is a
tree state with two parent commits. So you can look at what's different
in the merged state versus either parent, or there are some special ways
of looking at it all together.

You might want to try:

  # show a "combined diff"; lines with +/- in the first column came from
  # the first parent of the merge (i.e., where you were when you ran
  # "git merge" or "git pull"). The ones in the second column came from
  # the second parent (the thing you merged).
  git show -c 1e5e614

  # show a condensed combined diff; this is like "-c", except that it
  # eliminates "uninteresting" hunks, where the merge took the entire
  # hunk from one parent.
  git show --cc 1e5e614

  # show the diff of the merge commit to each of its parents
  # individually
  git show -m 1e5e614

And of course you can use those options with "git log -p" to see all of
the commits and what they did. You might also want to try "git log
--graph" to show the structure (though it is pretty hard to read with
the diffs included).

> I have a log file such as shown below (produced by "git log
> --full-history --name-status --parents --dense")

Doesn't --dense cancel out --full-history?

> I know that commit 693a2 had the correct files, but 1e5e6 does not.
> (It has an older version of the file).

Sounds like somebody botched the conflict resolution. Using the show
commands above should show you what happened in that case. Though from
the commit messages below, I don't see any mention of conflicts, which
the merge should have put in the message automatically.

So it may be that the files simply didn't change in first parent branch,
but somebody reverted them to old versions (or botched a different
merge) in the merged-in branch, with the end effect of reverting during
the merge.

If you're still confused after looking around more, and there is nothing
secret in the repo, it might work to make the repo available and tell us
what you expected to see in 1e5e6, and how it differed.

-Peff
--
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]