Re: files deleted with no record?

> 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@iee.org> wrote:
>>
>> From: "Phil Hord" <phil.hord@gmail.com>
>>
>>> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott <jeremy@great-scotts.org>
>>> 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
>
>