{"action":"created","issue":{"url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/98","labels_url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/98/labels{/name}","comments_url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/98/comments","events_url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/98/events","html_url":"https://github.com/ingydotnet/git-subrepo/issues/98","id":114548037,"number":98,"title":"Pull twice from subrepo loses changes from main repo","user":{"login":"grimmySwe","id":6480514,"avatar_url":"https://avatars.githubusercontent.com/u/6480514?v=3","gravatar_id":"","url":"https://api.github.com/users/grimmySwe","html_url":"https://github.com/grimmySwe","followers_url":"https://api.github.com/users/grimmySwe/followers","following_url":"https://api.github.com/users/grimmySwe/following{/other_user}","gists_url":"https://api.github.com/users/grimmySwe/gists{/gist_id}","starred_url":"https://api.github.com/users/grimmySwe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grimmySwe/subscriptions","organizations_url":"https://api.github.com/users/grimmySwe/orgs","repos_url":"https://api.github.com/users/grimmySwe/repos","events_url":"https://api.github.com/users/grimmySwe/events{/privacy}","received_events_url":"https://api.github.com/users/grimmySwe/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-11-02T08:31:50Z","updated_at":"2015-11-14T09:14:06Z","closed_at":null,"body":"Using subrepo v0.2.3 (679ad12fd684bd72feff90d445c373d9a3d2aa0f)\r\ngit version 1.9.3, 2.6.0\r\nAlso tested dzzh fork (f21fb34c676ea9949d870f38b1f934d89772c148)\r\n\r\nThe following workflow seems to lose things:\r\n\r\nI start with this\r\n```\r\nbar\r\n-----------------\r\nfoo\r\nfoo/bar\r\n```\r\n```cd foo; git add foo/bar/foo1```\r\n```cd bar; git add bar/bar1```\r\n\r\n```\r\nbar\r\nbar/bar1\r\n-----------------\r\nfoo\r\nfoo/bar\r\nfoo/bar/foo1\r\n```\r\n```cd foo; git subrepo pull bar```\r\n```\r\nbar\r\nbar/bar1\r\n-----------------\r\nfoo\r\nfoo/bar\r\nfoo/bar/bar1\r\nfoo/bar/foo1\r\n```\r\n```cd bar; git add bar/bar2```\r\n```cd foo; git subrepo pull bar```\r\n```\r\nbar\r\nbar/bar1\r\nbar/bar2\r\n-----------------\r\nfoo\r\nfoo/bar\r\nfoo/bar/bar1\r\nfoo/bar/bar2\r\n```\r\nSo where did foo/bar/foo1 go!!!!\r\n\r\nI will see if I can create a test case for this."},"comment":{"url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/comments/156673887","html_url":"https://github.com/ingydotnet/git-subrepo/issues/98#issuecomment-156673887","issue_url":"https://api.github.com/repos/ingydotnet/git-subrepo/issues/98","id":156673887,"user":{"login":"wkornewald","id":134387,"avatar_url":"https://avatars.githubusercontent.com/u/134387?v=3","gravatar_id":"","url":"https://api.github.com/users/wkornewald","html_url":"https://github.com/wkornewald","followers_url":"https://api.github.com/users/wkornewald/followers","following_url":"https://api.github.com/users/wkornewald/following{/other_user}","gists_url":"https://api.github.com/users/wkornewald/gists{/gist_id}","starred_url":"https://api.github.com/users/wkornewald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wkornewald/subscriptions","organizations_url":"https://api.github.com/users/wkornewald/orgs","repos_url":"https://api.github.com/users/wkornewald/repos","events_url":"https://api.github.com/users/wkornewald/events{/privacy}","received_events_url":"https://api.github.com/users/wkornewald/received_events","type":"User","site_admin":false},"created_at":"2015-11-14T09:14:06Z","updated_at":"2015-11-14T09:14:06Z","body":"@grimmySwe This goes into the direction I'm experimenting with. Is there a reason why you use -X theirs instead of --merge --interactive? After all, if there's a conflict it must be resolved manually and won't it be more difficult to fix after the rebase -X theirs?\r\n\r\nAlso, I'm still trying to find a good solution for sharing the rebased state with others. After all, it might contain non-trivial changes which we don't want every developer to reconstruct. Not sure if it's a good idea to commit all rebased patches into the project, so others can reuse those (subrepo could automatically load those patches when building the branch).\r\n\r\nFinally, one issue I've stumbled upon is that sometimes the common ancestor was imported with slight modifications, so the treehash won't match. It should still be possible to build the branch in that case, e.g. by rebasing from the first commit or even by allowing to specify the common ancestor revision."}}