Re: files deleted with no record?

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 26, 2014, 16:47 UTC
Message-ID: <CABURp0p6amKmhMhOUzdKy0a8TY7bmPoSLM0sUnZfGErhyfLsEQ@mail.gmail.com>
In-Reply-To: <CAFDwLfyXrUZUUuaciAjamn-cXJ6mAv_D41zLwT4AZE=cmAX7rg@mail.gmail.com>

On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott <jeremy@great-scotts.org> wrote:

Show 6 quoted lines

> 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

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.