we're all using source tree. I'm really interested to try and reproduce this so I'll find some time today to do it. Thanks again On Fri, Jun 27, 2014 at 6:56 AM, Jeremy Scott <jeremy@xxxxxxxxxxxxxxxx> wrote: > 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