{"thread":{"id":"34402","subject":"subtree merge strategy - merge upstream branches that share history","startedAt":"2013-07-11T10:35:39Z","lastAt":"2013-07-11T10:35:39Z","messageCount":1,"participants":["Volkmar Glauche"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"223048","messageId":"20130711123539.kya5rtfpc4gs08w4@webmail1.uniklinik-freiburg.de","threadId":"34402","inReplyTo":null,"subject":"subtree merge strategy - merge upstream branches that share history","fromName":"Volkmar Glauche","fromEmail":"volkmar.glauche@uniklinik-freiburg.de","sentAt":"2013-07-11T10:35:39Z","receivedAt":"2013-07-11T10:35:39Z","isPatch":false,"sender":{"key":"volkmar.glauche@uniklinik-freiburg.de","avatar":null},"body":"Dear list,\n\nI would like to set up a repository that has multiple branches from a  \nupstream project merged at different paths. Also, I would like to be  \nable to access upstream history in my project (it is interpreted code,  \nand I would like to git-blame to display a mix of local and upstream  \nhistory line-by-line in the code).\nI have documented the steps to demonstrate my desired repository  \nlayout in the attached shell script snippet. It is self-contained and  \nsets up two repositories upstream and main-repo in /tmp. It then reads  \ntwo branches featureA and featureB from upstream into separate paths  \nin main-repo.\nThen, the script modifies contents in the upstream repository. There  \nare modifications that apply to both featureA and featureB as well as  \nmodifications to one branch only.\nUp to this point, things seemed to work well using either git-subtree  \nor a combination of git-read-tree and \"subtree\" merge strategy.\nFinally, the changes to upstream are to be pulled into the  \ncorresponding paths in main-repo. Here, neither git-subtree nor git  \npull with subtree merge do what I want. The changes that apply to one  \nof the features only are applied correctly. However, changes from the  \ncommon history of featureA and featureB are only applied to the path  \nthat is updated first.\nApparently, git records that the common change has been applied and  \ndoesn't apply it a second time (which is correct for ~99.9999999% of  \nall use cases). In this special case however, git does not take into  \naccount that it applied the common change to a different path.\nI found that git pull --squash would apply the right set of updates to  \nboth featureA and featureB in main-repo (i.e. in this case, the common  \nchange would be applied on each path). However, this would leave me  \nunlinked to upstream history.\nNow:\n1) Am I doing something completely wrong, am I missing some important detail?\n2) Am I asking for something impossible?\n3) Is it expected behaviour, that --squash adds a different set of  \ntext changes than a pull without squash?\n\nBest,\n\nVolkmar\n\n\n\n\n-- \nFreiburg Brain Imaging\nhttp://fbi.uniklinik-freiburg.de/\nTel. +761 270-54783\nFax. +761 270-54819\n\n"}]}