Hi. Thanks for getting back to me.
here is a screenshot from source tree to visualise the scenario:
I will attempt a script to reproduce this later today.
On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley <philipoak...@iee.org> wrote:
> From: "Phil Hord" <phil.h...@gmail.com>
>> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott <jer...@great-scotts.org>
>>> 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
>>> 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:
>> 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
>> git log --oneline --graph --stat
>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html