# files deleted with no record? 5 messages from 2014-06-24 to 2014-06-26. Participants: Jeremy Scott, Phil Hord, Philip Oakley. Thread: https://gitlist.dev/t/36985 ## Jeremy Scott, 2014-06-24 01:15 Subject: files deleted with no record? Message-ID: URL: https://gitlist.dev/e/CAFDwLfyXrUZUUuaciAjamn-cXJ6mAv_D41zLwT4AZE%3DcmAX7rg%40mail.gmail.com ``` 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 ``` ## Phil Hord, 2014-06-26 16:47 Subject: Re: files deleted with no record? Message-ID: URL: https://gitlist.dev/e/CABURp0p6amKmhMhOUzdKy0a8TY7bmPoSLM0sUnZfGErhyfLsEQ%40mail.gmail.com In-Reply-To: ``` On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott 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. ``` ## Philip Oakley, 2014-06-26 19:53 Subject: Re: files deleted with no record? Message-ID: <7298A047128B405F94F5E73903089107@PhilipOakley> URL: https://gitlist.dev/e/7298A047128B405F94F5E73903089107%40PhilipOakley In-Reply-To: ``` From: "Phil Hord" > On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott > 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 ``` ## Jeremy Scott, 2014-06-26 20:57 Subject: Re: files deleted with no record? Message-ID: URL: https://gitlist.dev/e/CAFDwLfwdcka25o0S_-ekb%2BAAFRVDADeiZD1f5kXJczqei%3De3eg%40mail.gmail.com In-Reply-To: <7298A047128B405F94F5E73903089107@PhilipOakley> ``` 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 wrote: > From: "Phil Hord" > >> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott >> 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 ``` ## Jeremy Scott, 2014-06-26 21:00 Subject: Re: files deleted with no record? Message-ID: URL: https://gitlist.dev/e/CAFDwLfzVX_A-6dEVpJccjfrQD7266dzgG9t-KeC4p15dvN1gyQ%40mail.gmail.com In-Reply-To: ``` we're all using source tree. I'm really interested to try and reproduce this so I'll find some time today to do it. Thanks again On Fri, Jun 27, 2014 at 6:56 AM, Jeremy Scott wrote: > 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 wrote: >> >> From: "Phil Hord" >> >>> On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott >>> 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 > > ```