From: Philip Oakley <philipoakley@iee.org>
Date: Thu, 26 Jun 2014 19:53:36 GMT
Subject: Re: files deleted with no record?
Message-ID: <7298A047128B405F94F5E73903089107@PhilipOakley>
In-Reply-To: <CABURp0p6amKmhMhOUzdKy0a8TY7bmPoSLM0sUnZfGErhyfLsEQ@mail.gmail.com>

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