Hi. Thanks for getting back to me. here is a screenshot from source tree to visualise the scenario: https://drive.google.com/file/d/0B-Wn7DfHsuhyTEVkRHAzeGVZelpMWjFxZW1kbVBKVlNab3pR/edit?usp=sharing I will attempt a script to reproduce this later today. Thanks On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley <philipoakley@xxxxxxx> wrote: > From: "Phil Hord" <phil.hord@xxxxxxxxx> > >> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott <jeremy@xxxxxxxxxxxxxxxx> >> wrote: >>> >>> I just encountered a situation where a merge was made, with no >>> apparent changes in files (ie no log), but the result was that some >>> files were deleted. >>> >>> person A adds some files >>> person B adds some files from the same point >> >> >> You mean from the same point in history, right? Not files with the >> same filename or path? >> >>> person B commits and pushes. >>> person A commits -- now merge is required >>> a few more commits on top of person B's commit >> >> >> I don't understand this step. Who adds a few more commits on top of B and >> why? >> >>> person A merges - this removes the files that B added. There is no log >>> of the files being deleted > > > A similar issue, by reference, just came up on the [git-users] list. The > reference was: > 1. http://randyfay.com/content/avoiding-git-disasters-gory-story > > In that case the problem was a mixture of tools and misunderstandings. > > It may not be the same as your case, but could give insights into what's > happening between different developers. > > Which Tools are You, person A and Person B using, with --version? > >> >> This sounds like an "evil merge" (see man gitglossary, and google), >> but it's not clear to me how you arrived here. >> >> When I tried to reproduce your issue with this script, it did not >> remove any files unexpectedly: >> ------------------->8----------------------- >> #!/bin/sh >> >> set -e >> mkdir foo && cd foo && git init >> echo foo > foo && git add foo && git commit -mfoo >> >> git checkout -b PersonA master >> echo bar > bar && git add bar >> git commit -m"PersonA: bar" >> >> git checkout -b PersonB master >> echo baz > baz && git add baz >> git commit -m"PersonB: baz" >> >> echo foo-conflict >> foo && git add foo >> git commit -m"PersonB: foo" >> >> git checkout PersonA >> echo foo-different >> foo && git add foo >> git commit -m"PersonA: foo (conflicts with PersonB)" >> >> git log --oneline --all --stat >> >> if ! git merge PersonB ; then >> git checkout PersonA foo >> git commit --no-edit >> fi >> git log --oneline --graph --stat >> ------------------->8----------------------- >> >> A sneaky issue with merges is that they do not have a clear way to >> show patch information -- the diff between the commit and its ancestor >> -- because they have multiple ancestors. You can show diffs for a >> merge relative to each of its parents, but it is not usually done for >> you automatically. This is why making changes in a merge which are >> not actually required for the merge is bad ("evil"). >> >>> Clearly this is possible - was this a user error? >> >> >> Probably, but we'd need to see how the user got there. >> -- > > Philip -- 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