{"thread":{"id":"47907","subject":"[BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","startedAt":"2018-02-22T22:47:30Z","lastAt":"2018-03-05T15:46:39Z","messageCount":8,"participants":["Marcel 'childNo͡.de' Trautwein","Jonathan Nieder","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"339985","messageId":"741A56BF-93C0-41EA-856F-C1170803F0A7@childno.de","threadId":"47907","inReplyTo":null,"subject":"[BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Marcel 'childNo͡.de' Trautwein","fromEmail":"c0d3+gitscm@childno.de","sentAt":"2018-02-22T22:41:20Z","receivedAt":"2018-02-22T22:47:30Z","isPatch":false,"sender":{"key":"c0d3+gitscm@childno.de","avatar":null},"body":"Hi,\n\nI think we have a problem … or at least I had\nand I’m not quite sure if this is „working as designed“\nbut I’m sure it „should not work as it did“.\n\nBecause? It pruned a lot of files and even the local repository.\nby pull\nby giving another repository URL instead of a known remote\n\nWhile working in a subpath of my homedir\n(that is a git repository itself, without any changes in worktree or index: https://bitbucket.org/childnode/marcel/ )\nI wanted to clone another repository … but yeah … it’s late for me today and I put\nin s.th. `git pull git@private.gitlab.instance.example.com:aGroup/repository.git`\n\nnext … all committed files are zapped and the repository given has been checked out in my home directory 🤯👻\n\nwhat? Shouldn’t this just fail? Why can I pass another remote to pull?\n\n🙏 god any untracked / ignored files are still alive\n\na, yeh, I’m on a mac \n(for any git configuration … have a look in my repository \nhttps://bitbucket.org/childnode/marcel/src/88ff8d0c28bb90dfde3aea9e6c39bb551bea8ca8/.gitconfig?at=master&fileviewer=file-view-default\n\nthe console out was:\n```\n-bash:$ git pull git@private.gitlab.instance.example.com:aGroup/repository.git\nWarning: Permanently added the ECDSA host key for IP address '10.1.2.3' to the list of known hosts.\nwarning: no common commits\nremote: Counting objects: 2301, done.\nremote: Compressing objects: 100% (710/710), done.\nremote: Total 2301 (delta 1040), reused 2239 (delta 1004)\nReceiving objects: 100% (2301/2301), 405.41 KiB | 635.00 KiB/s, done.\nResolving deltas: 100% (1040/1040), done.\nFrom private.gitlab.instance.example.com:aGroup/repository\n * branch            HEAD       -> FETCH_HEAD\nFetching submodule .shapps/willgit\nFetching submodule .vim\nFetching submodule .vim/autoload/pathogen\nwarning: redirecting to https://github.com/tpope/vim-pathogen.git/\nFetching submodule .vim/bundle/ack\nwarning: redirecting to https://github.com/mileszs/ack.vim.git/\nFetching submodule .vim/bundle/colors-solarized\nwarning: redirecting to https://github.com/altercation/vim-colors-solarized.git/\nFetching submodule .vim/bundle/flake8\nFetching submodule .vim/bundle/fugitive\nwarning: redirecting to https://github.com/tpope/vim-fugitive.git/\nFetching submodule .vim/bundle/kwbdi\nwarning: redirecting to https://github.com/vim-scripts/kwbdi.vim.git/\nFetching submodule .vim/bundle/markdown\nwarning: redirecting to https://github.com/tpope/vim-markdown.git/\nFetching submodule .vim/bundle/nerdtree\nwarning: redirecting to https://github.com/scrooloose/nerdtree.git/\nFetching submodule .vim/bundle/unimpaired\nwarning: redirecting to https://github.com/tpope/vim-unimpaired.git/\nFetching submodule gists/bitbucket/childnode/2015-06-16_G4pLy_prevent-empty-version-comment-in.git\nFetching submodule gists/bitbucket/childnode/2015-06-21_kyAAM_plasticscm-addcurrentworkdir-batch-task\nFetching submodule gists/github/childnode/18de20f4448692257aa3e99c8319b70d\nFetching submodule gists/github/childnode/295dbd6e_hasSize.regex\nFetching submodule gists/github/childnode/4a0de936_gradle_buildSrc_dogfood\nFetching submodule gists/github/childnode/66d4b982_git.rebaseAllBranches\nFetching submodule gists/github/childnode/6df6d14c_ideaGradleProjectSetupForAdditionalSourceSets\nFetching submodule gists/github/childnode/81ae6468_build_jar_manifest.gradle\nFetching submodule gists/github/childnode/85958ff8_extendedHelp.gradle_secret\nFetching submodule gists/github/childnode/88304258_git_deleteAllRemoteBranches.sh\nFetching submodule gists/github/childnode/8f100f90_dockerSaveAllImages.sh\nFetching submodule gists/github/childnode/9741c4d1_idea.warnGenerateWorkspace.gradle_secret\nFetching submodule gists/github/childnode/a175d954_ext.props.gradle_secret\nFetching submodule gists/github/childnode/d15cd5e9_atlassian-confluence-config\nFetching submodule gists/github/childnode/d35cf810dd28775ac5c0e491107215fd\nFetching submodule gists/github/childnode/da08e8a6f989ce0f94077ae1a6b1573b\nFetching submodule gists/github/childnode/e7ef876c_html2ical_secret\nFetching submodule gists/github/childnode/eb3199790f2f82785f62c3150f352ede\nSuccessfully rebased and updated refs/heads/master.\n\n```\n\ntrying to fix this up by doing another pull failed:\n```\n-bash:$ git remote -v\norigin\tgit@bitbucket.org:childnode/marcel.git (fetch)\norigin\tgit@bitbucket.org:childnode/marcel.git (push)\n\n-bash:$ git pull\nfatal: refusing to merge unrelated histories\n\n-bash:$ git pull git@bitbucket.org:childnode/marcel.git\nFrom bitbucket.org:childnode/marcel\n * branch            HEAD       -> FETCH_HEAD\nfatal: refusing to merge unrelated histories\n\n```\n\nthese messages and the fact that it doesn’t work backward let me think I ran into\na collision? really?\n\nrevlog looks a bit strange too\n```\n04f3066 (HEAD -> master) HEAD@{0}: pull git@private.gitlab.instance.example.com:aGroup/repository.git: checkout 04f3066d03e09323c7341c472be4c45ea5e3a4ff: returning to refs/heads/master\n04f3066 (HEAD -> master) HEAD@{1}: pull git@private.gitlab.instance.example.com:aGroup/repository.git: checkout 04f3066d03e09323c7341c472be4c45ea5e3a4ff\n88ff8d0 (origin/master, origin/HEAD) HEAD@{2}: pull --rebase=preserve: checkout 88ff8d0c28bb90dfde3aea9e6c39bb551bea8ca8: returning to refs/heads/master\n```\n\nwhere 88ff8d0 was the latest from marcel.git\nand logs look like the pulled repository is like an orphan aside my original one. \n\n~Marcel\n\nP.S: I reverted by `$ git reset 88ff8d0 && git checkout -- .`"},{"id":"339987","messageId":"20180222232031.GE256918@aiede.svl.corp.google.com","threadId":"47907","inReplyTo":"741A56BF-93C0-41EA-856F-C1170803F0A7@childno.de","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-02-22T23:20:31Z","receivedAt":"2018-02-22T23:20:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Marcel,\n\nMarcel 'childNo͡.de' Trautwein\" wrote:\n\n> I think we have a problem … or at least I had\n> and I’m not quite sure if this is „working as designed“\n> but I’m sure it „should not work as it did“.\n[...]\n> I wanted to clone another repository … but yeah … it’s late for me today and I put\n> in s.th. `git pull git@private.gitlab.instance.example.com:aGroup/repository.git`\n>\n> next … all committed files are zapped and the repository given has\n> been checked out in my home directory 🤯👻\n>\n> what? Shouldn’t this just fail? Why can I pass another remote to pull?\n\nSorry, this is not the most helpful reply but:\n\nCan you describe a reproduction recipe so that I can experience the\nsame thing?\n\nThat is:\n\n 1. steps to reproduce\n 2. expected result\n 3. actual result\n 4. the difference and why it was unexpected\n\nI suspect that this information is in your message, somewhere, but it\nis (understandably) unfocussed and I am having trouble pulling it out.\n\n[...]\n> trying to fix this up by doing another pull failed:\n> ```\n> -bash:$ git remote -v\n> origin\tgit@bitbucket.org:childnode/marcel.git (fetch)\n> origin\tgit@bitbucket.org:childnode/marcel.git (push)\n>\n> -bash:$ git pull\n> fatal: refusing to merge unrelated histories\n\nOk, this part is something I might be able to help shed some light on.\n\nSearching for 'unrelated' in \"git help pull\" finds:\n\n       --allow-unrelated-histories\n\t   By default, git merge command refuses to merge histories that do not\n\t   share a common ancestor. This option can be used to override this\n\t   safety when merging histories of two projects that started their\n\t   lives independently. As that is a very rare occasion, no\n\t   configuration variable to enable this by default exists and will not\n\t   be added.\n\nSo that explains the \"what\" of that error message.\n\nThe \"why\" is a separate question.  Could you share output from\n\n  git log --all --graph --decorate --oneline --simplify-by-decoration\n\nand\n\n  git status\n\nto help us understand your current state?\n\nAlso, suggestions for improvements to the 'refusing to merge' message\nwould be very welcome.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"339995","messageId":"8A26AAB4-E2E5-4681-87D4-0D6727CA423A@childno.de","threadId":"47907","inReplyTo":"20180222232031.GE256918@aiede.svl.corp.google.com","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Marcel 'childNo͡.de' Trautwein","fromEmail":"c0d3+gitscm@childno.de","sentAt":"2018-02-23T05:29:55Z","receivedAt":"2018-02-23T05:30:08Z","isPatch":false,"sender":{"key":"c0d3+gitscm@childno.de","avatar":null},"body":"> Am 23.02.2018 um 00:20 schrieb Jonathan Nieder <jrnieder@gmail.com>:\n> \n> Hi Marcel,\n> \n> …\n> Sorry, this is not the most helpful reply but:\n> \n> Can you describe a reproduction recipe so that I can experience the\n> same thing?\n> \n> That is:\n> \n> 1. steps to reproduce\n> 2. expected result\n> 3. actual result\n> 4. the difference and why it was unexpected\n> \n\n1. steps to reproduce\n=====================\n```\nLast login: Fri Feb 23 00:33:11 on ttys001\n~ PATH variable not enhanced, no applications found in ~/Applications/*-latest\n\n\n-bash:/Users/marcel:$ mkdir /tmp/$$\nchange to new directory '/tmp/2608'? [Y/n] \n\n\n-bash:/tmp/2608:$ mkdir a.git\nchange to new directory 'a.git'? [Y/n] \n\n\n-bash:/tmp/2608/a.git:$ git init\nInitialized empty Git repository in /private/tmp/2608/a.git/.git/\n\n\n-bash:/tmp/2608/a.git:$ touch foo\n\n\n-bash:/tmp/2608/a.git:$ git add foo\n\n\n-bash:/tmp/2608/a.git:$ git commit -m \"foo\" foo\n[master (root-commit) ed191c4] foo\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 foo\n\n\n-bash:/tmp/2608/a.git:$ cd -\n/tmp/2608\n\n\n-bash:/tmp/2608:$ mkdir b.git\nchange to new directory 'b.git'? [Y/n] \n\n\n-bash:/tmp/2608/b.git:$ git init\nInitialized empty Git repository in /private/tmp/2608/b.git/.git/\n\n\n-bash:/tmp/2608/b.git:$ touch bar\n\n\n-bash:/tmp/2608/b.git:$ git add bar\n\n\n-bash:/tmp/2608/b.git:$ git commit -m \"bar\" bar\n[master (root-commit) 80b0355] bar\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 bar\n\n\n-bash:/tmp/2608/b.git:$ cd -\n/tmp/2608\n\n\n-bash:/tmp/2608:$ git clone a.git c\nCloning into 'c'...\ndone.\n\n\n-bash:/tmp/2608:$ cd c\n\n\n-bash:/tmp/2608/c:$ ll\ntotal 0\ndrwxr-xr-x  12 marcel  wheel   384B 23 Feb 05:47 .git\n-rw-r--r--   1 marcel  wheel     0B 23 Feb 05:47 foo\n\n\n-bash:/tmp/2608/c:$ git pull ../b.git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom ../b\n * branch            HEAD       -> FETCH_HEAD\nSuccessfully rebased and updated refs/heads/master.\n\n\n-bash:/tmp/2608/c:$ ll\ntotal 0\ndrwxr-xr-x  14 marcel  wheel   448B 23 Feb 05:47 .git\n-rw-r--r--   1 marcel  wheel     0B 23 Feb 05:47 bar\n\n\n-bash:/tmp/2608/c:$ git reflog\n80b0355 (HEAD -> master) HEAD@{0}: pull ../b.git/: checkout 80b03552466bc526b1130ce5ca4a991ba31a0546: returning to refs/heads/master\n80b0355 (HEAD -> master) HEAD@{1}: pull ../b.git/: checkout 80b03552466bc526b1130ce5ca4a991ba31a0546\ned191c4 (origin/master, origin/HEAD) HEAD@{2}: clone: from /tmp/2608/a.git\n\n\n-bash:/tmp/2608/c:$ git remote -v\norigin\t/tmp/2608/a.git (fetch)\norigin\t/tmp/2608/a.git (push)\n\n\n-bash:/tmp/2608/c:$  git log --all --graph --decorate --oneline --simplify-by-decoration\n* 80b0355 (HEAD -> master) bar\n* ed191c4 (origin/master, origin/HEAD) foo\n```\n\n2. expected result\n==================\njust an error in case the too trees have no common ancestors\n\n```\n-bash:/tmp/2608/c:$ git pull ../b.git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom ../b\n * branch            HEAD       -> FETCH_HEAD\nfatal: refusing to merge unrelated histories\n```\n\n3. actual result\n================\npulls out, removes all files from the first tree\n\n4. the difference and why it was unexpected\n===========================================\nI can’t find words on it … it should not work but it did? somehow … with unexpected results to my local repository\n\nit somehow seems to be an issue of my config, because resetting it, will not allow the pull as expected\n\n```\n-bash:/tmp/2608/c:$ GIT_CONFIG_NOSYSTEM=1 HOME=. git config -l\ncore.repositoryformatversion=0\ncore.filemode=true\ncore.bare=false\ncore.logallrefupdates=true\ncore.ignorecase=true\ncore.precomposeunicode=true\nremote.origin.url=/tmp/2608/a.git\nremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\nbranch.master.remote=origin\nbranch.master.merge=refs/heads/master\n\n\n-bash:/tmp/2608/c:$ GIT_CONFIG_NOSYSTEM=1 HOME=. git pull ../b.git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom ../b\n * branch            HEAD       -> FETCH_HEAD\nfatal: refusing to merge unrelated histories\n\n\n-bash:/tmp/2608/c:$ git pull ../b.git/\nFrom ../b\n * branch            HEAD       -> FETCH_HEAD\nSuccessfully rebased and updated refs/heads/master.\n```\n\nthe logs tells me he rebases ...\n```\n-bash:/tmp/2608/c:$ git config -l | grep merge\ndiff.tool=p4merge\nmerge.tool=p4merge\nmerge.branchdesc=true\nmerge.log=true\nbranch.autosetupmerge=true\nbranch.master.merge=refs/heads/master\n\n\n-bash:/tmp/2608/c:$ git config -l | grep pull\npull.rebase=preserve\n\n\n-bash:/tmp/2608/c:$ git config -l | grep fetch\nfetch.recursesubmodules=true\nremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n```\n\n\n> I suspect that this information is in your message, somewhere, but it\n> is (understandably) unfocussed and I am having trouble pulling it out.\n> \n\nI’m sorry, I just wanted to write down first any helpful information without - being late - having time to go into further investigations myself … hopefully to get some answers that „this is ok, you’re just stupid and didn’t read the spec/doc“ or „ok, this seems strange to me too, can we go forward in details and analysis“ ;)\n\n> [...]\n>> trying to fix this up by doing another pull failed:\n>> ```\n>> -bash:$ git remote -v\n>> origin\tgit@bitbucket.org:childnode/marcel.git (fetch)\n>> origin\tgit@bitbucket.org:childnode/marcel.git (push)\n>> \n>> -bash:$ git pull\n>> fatal: refusing to merge unrelated histories\n> \n> Ok, this part is something I might be able to help shed some light on.\n> \n> Searching for 'unrelated' in \"git help pull\" finds:\n> \n>       --allow-unrelated-histories\n> \t   By default, git merge command refuses to merge histories that do not\n> \t   share a common ancestor. This option can be used to override this\n> \t   safety when merging histories of two projects that started their\n> \t   lives independently. As that is a very rare occasion, no\n> \t   configuration variable to enable this by default exists and will not\n> \t   be added.\n> \n> So that explains the \"what\" of that error message.\n> \n> The \"why\" is a separate question.  Could you share output from\n> \n>  git log --all --graph --decorate --oneline --simplify-by-decoration\n> \n> and\n> \n>  git status\n> \n\n```\n-bash:/tmp/2608/c:$ git status\nOn branch master\nYour branch and 'origin/master' have diverged,\nand have 1 and 1 different commits each, respectively.\n  (use \"git pull\" to merge the remote branch into yours)\n\nnothing to commit, working tree clean\n\n\n-bash:/tmp/2608/c:$ git branch -avv\n* master                80b0355 [origin/master: ahead 1, behind 1] bar\n  remotes/origin/HEAD   -> origin/master\n  remotes/origin/master ed191c4 foo\n\n```\n\n\n> to help us understand your current state?\n> \n> Also, suggestions for improvements to the 'refusing to merge' message\n> would be very welcome.\n> \n> Thanks and hope that helps,\n> Jonathan\n\njust to say: the latter „refused pull“ is what I expect the first time too!\n\n\nSUSPECTED / PROVEN to found a guilty setting\n=============================================\n```\n-bash:/tmp/2608/c:$ GIT_CONFIG_NOSYSTEM=1 HOME=. git -c user.name=\"me\" -c user.email=me@example.com pull -r ../b.git/\nwarning: no common commits\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom ../b\n * branch            HEAD       -> FETCH_HEAD\nFirst, rewinding head to replay your work on top of it...\nApplying: foo\n\n\n-bash:/tmp/2608/c:$ ll\ntotal 0\ndrwxr-xr-x  14 marcel  wheel   448B 23 Feb 06:21 .git\n-rw-r--r--   1 marcel  wheel     0B 23 Feb 06:21 bar\n-rw-r--r--   1 marcel  wheel     0B 23 Feb 06:21 foo\n\n```\nshows me a quite different behavior, so solely rebase not seems the full problem\nBUT\n`--rebase=preserve` will .. o’man , really, is this intended?\n\nYes, I see, rebase is a harmful operation and yes, you might now tell me a fool\nto apply this per default\n\nbut why is this unrelated history check different from pull (merge) to rebase to rebase -p ?\nCan’t find a word on it\nhttps://git-scm.com/docs/git-rebase#git-rebase---preserve-merges\n\n\nWith regards,\n~Marcel"},{"id":"339997","messageId":"20180223064549.GA19791@sigill.intra.peff.net","threadId":"47907","inReplyTo":"8A26AAB4-E2E5-4681-87D4-0D6727CA423A@childno.de","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-23T06:45:50Z","receivedAt":"2018-02-23T06:45:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 23, 2018 at 06:29:55AM +0100, \"Marcel 'childNo͡.de' Trautwein\" wrote:\n\n> shows me a quite different behavior, so solely rebase not seems the full problem\n> BUT\n> `--rebase=preserve` will .. o’man , really, is this intended?\n\nYeah, the bug seems to be in --preserve-merges. Here's an easier\nreproduction:\n\n  git init\n  >one && git add one && git commit -m one\n  git checkout --orphan other\n  git mv one two && git commit -m two\n\n  git rebase --preserve-merges master\n\nat which point we've dropped commit \"two\" and its files entirely.\n\nI don't know much about how preserve-merges works. It looks like in the\nloop around git-rebase--interactive.sh:931 that we mark commit \"two\"\nwith preserve=t, and so we _don't_ add it to the list of commits to\npick.\n\nI think that stems from the fact that it has no parent marked to be\nrewritten.\n\nSo something like this helps:\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 81c5b42875..71e6cbb388 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -921,15 +921,20 @@ else\n \n \t\tif test -z \"$rebase_root\"\n \t\tthen\n \t\t\tpreserve=t\n+\t\t\tp=\n \t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)\n \t\t\tdo\n \t\t\t\tif test -f \"$rewritten\"/$p\n \t\t\t\tthen\n \t\t\t\t\tpreserve=f\n \t\t\t\tfi\n \t\t\tdone\n+\t\t\tif test -z \"$p\"\n+\t\t\tthen\n+\t\t\t\tpreserve=f\n+\t\t\tfi\n \t\telse\n \t\t\tpreserve=f\n \t\tfi\n \t\tif test f = \"$preserve\"\n\nBecause it at least adds \"two\" to the list of commits to pick. But\noddly, it picks it directly as a root commit again. Whereas a rebase\nwithout --preserve-merges (and even \"-i\") picks it on top of commit\n\"one\" (which is what I'd expect).\n\n+cc Dscho, as the --preserve-merges guru.\n\n-Peff\n"},{"id":"340348","messageId":"nycvar.QRO.7.76.6.1802270032520.56@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47907","inReplyTo":"20180223064549.GA19791@sigill.intra.peff.net","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-02-26T23:33:56Z","receivedAt":"2018-02-26T23:34:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Fri, 23 Feb 2018, Jeff King wrote:\n\n> On Fri, Feb 23, 2018 at 06:29:55AM +0100, \"Marcel 'childNo͡.de' Trautwein\" wrote:\n> \n> > shows me a quite different behavior, so solely rebase not seems the\n> > full problem BUT `--rebase=preserve` will .. o’man , really, is this\n> > intended?\n> \n> Yeah, the bug seems to be in --preserve-merges. Here's an easier\n> reproduction:\n> \n>   git init\n>   >one && git add one && git commit -m one\n>   git checkout --orphan other\n>   git mv one two && git commit -m two\n> \n>   git rebase --preserve-merges master\n> \n> at which point we've dropped commit \"two\" and its files entirely.\n> \n> I don't know much about how preserve-merges works. It looks like in the\n> loop around git-rebase--interactive.sh:931 that we mark commit \"two\"\n> with preserve=t, and so we _don't_ add it to the list of commits to\n> pick.\n> \n> I think that stems from the fact that it has no parent marked to be\n> rewritten.\n> \n> So something like this helps:\n> \n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 81c5b42875..71e6cbb388 100644\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -921,15 +921,20 @@ else\n>  \n>  \t\tif test -z \"$rebase_root\"\n>  \t\tthen\n>  \t\t\tpreserve=t\n> +\t\t\tp=\n>  \t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)\n>  \t\t\tdo\n>  \t\t\t\tif test -f \"$rewritten\"/$p\n>  \t\t\t\tthen\n>  \t\t\t\t\tpreserve=f\n>  \t\t\t\tfi\n>  \t\t\tdone\n> +\t\t\tif test -z \"$p\"\n> +\t\t\tthen\n> +\t\t\t\tpreserve=f\n> +\t\t\tfi\n>  \t\telse\n>  \t\t\tpreserve=f\n>  \t\tfi\n>  \t\tif test f = \"$preserve\"\n> \n> Because it at least adds \"two\" to the list of commits to pick. But\n> oddly, it picks it directly as a root commit again. Whereas a rebase\n> without --preserve-merges (and even \"-i\") picks it on top of commit\n> \"one\" (which is what I'd expect).\n> \n> +cc Dscho, as the --preserve-merges guru.\n\nYour analysis makes sense to me. Please note, though, that I would not\nconsider myself a guru on preserve-merges. I think this mode is broken by\ndesign (you can blame me if you want).\n\nCiao,\nDscho"},{"id":"340562","messageId":"20180228132807.GA6206@sigill.intra.peff.net","threadId":"47907","inReplyTo":"nycvar.QRO.7.76.6.1802270032520.56@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-28T13:28:08Z","receivedAt":"2018-02-28T13:28:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote:\n\n> > So something like this helps:\n> > \n> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> > index 81c5b42875..71e6cbb388 100644\n> > --- a/git-rebase--interactive.sh\n> > +++ b/git-rebase--interactive.sh\n> > @@ -921,15 +921,20 @@ else\n> >  \n> >  \t\tif test -z \"$rebase_root\"\n> >  \t\tthen\n> >  \t\t\tpreserve=t\n> > +\t\t\tp=\n> >  \t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)\n> >  \t\t\tdo\n> >  \t\t\t\tif test -f \"$rewritten\"/$p\n> >  \t\t\t\tthen\n> >  \t\t\t\t\tpreserve=f\n> >  \t\t\t\tfi\n> >  \t\t\tdone\n> > +\t\t\tif test -z \"$p\"\n> > +\t\t\tthen\n> > +\t\t\t\tpreserve=f\n> > +\t\t\tfi\n> >  \t\telse\n> >  \t\t\tpreserve=f\n> >  \t\tfi\n> >  \t\tif test f = \"$preserve\"\n> > \n> > Because it at least adds \"two\" to the list of commits to pick. But\n> > oddly, it picks it directly as a root commit again. Whereas a rebase\n> > without --preserve-merges (and even \"-i\") picks it on top of commit\n> > \"one\" (which is what I'd expect).\n> > \n> > +cc Dscho, as the --preserve-merges guru.\n> \n> Your analysis makes sense to me. Please note, though, that I would not\n> consider myself a guru on preserve-merges. I think this mode is broken by\n> design (you can blame me if you want).\n\nI think that is doing the right thing for half of the problem. But\nthere's something else funny where we do not include the \"upstream\"\ncommits from the split history (i.e., we rebase onto nothing,\nwhereas a normal \"git rebase\" with a split history will graft the two\ntogether).\n\nI haven't figured that part out. But I do kind of wonder if we should\nsimply punt early and say \"what you're doing is crazy and unsupported\".\nAfter all, the only known case of this was somebody doing it\naccidentally.\n\n-Peff\n"},{"id":"341023","messageId":"nycvar.QRO.7.76.6.1803051546200.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47907","inReplyTo":"20180228132807.GA6206@sigill.intra.peff.net","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-05T14:49:13Z","receivedAt":"2018-03-05T14:49:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Wed, 28 Feb 2018, Jeff King wrote:\n\n> On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote:\n> \n> > > So something like this helps:\n> > > \n> > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> > > index 81c5b42875..71e6cbb388 100644\n> > > --- a/git-rebase--interactive.sh\n> > > +++ b/git-rebase--interactive.sh\n> > > @@ -921,15 +921,20 @@ else\n> > >  \n> > >  \t\tif test -z \"$rebase_root\"\n> > >  \t\tthen\n> > >  \t\t\tpreserve=t\n> > > +\t\t\tp=\n> > >  \t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)\n> > >  \t\t\tdo\n> > >  \t\t\t\tif test -f \"$rewritten\"/$p\n> > >  \t\t\t\tthen\n> > >  \t\t\t\t\tpreserve=f\n> > >  \t\t\t\tfi\n> > >  \t\t\tdone\n> > > +\t\t\tif test -z \"$p\"\n> > > +\t\t\tthen\n> > > +\t\t\t\tpreserve=f\n> > > +\t\t\tfi\n> > >  \t\telse\n> > >  \t\t\tpreserve=f\n> > >  \t\tfi\n> > >  \t\tif test f = \"$preserve\"\n> > > \n> > > Because it at least adds \"two\" to the list of commits to pick. But\n> > > oddly, it picks it directly as a root commit again. Whereas a rebase\n> > > without --preserve-merges (and even \"-i\") picks it on top of commit\n> > > \"one\" (which is what I'd expect).\n> > > \n> > > +cc Dscho, as the --preserve-merges guru.\n> > \n> > Your analysis makes sense to me. Please note, though, that I would not\n> > consider myself a guru on preserve-merges. I think this mode is broken by\n> > design (you can blame me if you want).\n> \n> I think that is doing the right thing for half of the problem. But\n> there's something else funny where we do not include the \"upstream\"\n> commits from the split history (i.e., we rebase onto nothing,\n> whereas a normal \"git rebase\" with a split history will graft the two\n> together).\n\nLet me ask to make sure I am understanding you correctly. Are you\nreferring to \"split history\" as the case where the commit graph has *two*\nroot commits?\n\nIf so: when you perform a merge-preserving rebase, then those two root\ncommits will be recreated as new root commits, by design.\n\nThe non-merge-preserving mode cannot create two root commits, as it does\nnot allow for introducing merge commits (and you'd need that to combine\nthe two strands).\n\nIt is quite possible that I misunderstand completely, though. Care to\nenlighten me?\n\nCiao,\nDscho\n"},{"id":"341025","messageId":"20180305154626.GA26740@sigill.intra.peff.net","threadId":"47907","inReplyTo":"nycvar.QRO.7.76.6.1803051546200.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-03-05T15:46:26Z","receivedAt":"2018-03-05T15:46:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote:\n\n> > I think that is doing the right thing for half of the problem. But\n> > there's something else funny where we do not include the \"upstream\"\n> > commits from the split history (i.e., we rebase onto nothing,\n> > whereas a normal \"git rebase\" with a split history will graft the two\n> > together).\n> \n> Let me ask to make sure I am understanding you correctly. Are you\n> referring to \"split history\" as the case where the commit graph has *two*\n> root commits?\n\nYes, I mean two root commits. But especially when one is in the history\nto be rebased, and the other is in the \"upstream\" history.\n\nSo as a concrete example, if I have this repo:\n\n  git init\n  >one && git add one && git commit -m one\n  git checkout --orphan other\n  git mv one two && git commit -m two\n\nand I do this:\n\n  git rebase master\n\nI end up with a two-commit history, with \"two\" on top of \"one\". That\nmakes sense to me. Similarly if I instead do:\n\n  git rebase -i master\n\nthe todo list has \"pick two\", and if I leave it as-is then I get the\nsame history. But if I do:\n\n  git rebase --preserve-merges master\n\nI end up with a single-commit history, with only commit \"one\". That's\nwrong, because it threw away the history on the \"other\" branch.\n\nIf I apply the patch I showed earlier, then I get a single-branch\nhistory, but this time it contains only \"two\". That also seems wrong,\nbecause we didn't build on top of \"master\". I'd expect this command to\ngive the same results as a non-merge-preserving rebase.\n\nDoes that make more sense?\n\n-Peff\n"}]}