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
person B commits and pushes.
person A commits -- now merge is required
a few more commits on top of person B's commit
person A merges - this removes the files that B added. There is no log
of the files being deleted
Clearly this is possible - was this a user error?
Thanks
On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott [off-list ref] 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
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.
From: "Phil Hord" <redacted>
On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott
[off-list ref] wrote:
quoted
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?
quoted
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?
quoted
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").
quoted
Clearly this is possible - was this a user error?
Probably, but we'd need to see how the user got there.
--
Philip
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 [off-list ref] wrote:
From: "Phil Hord" <redacted>
quoted
On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott [off-list ref]
wrote:
quoted
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?
quoted
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?
quoted
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?
quoted
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").
quoted
Clearly this is possible - was this a user error?
Probably, but we'd need to see how the user got there.
--
Philip