Thomas Rast <trast@xxxxxxxxxxx> writes: > But for next time, can there be another solution? It seems that this > process will make it very hard in general to keep the git-gui and core > git translations in sync. That unfortunately is fundamental in the way git-gui and the core git are related to each other, and the story is the same for gitk. The arrangement to pull only in one direction comes from the initial desire from the maintainers of these "merge -s subtree" merged projects. These source trees are designed to be usable without being embedded inside a source tree of the core git, and when people want to work only on one of these projects, their clone will not have to carry any material from the history of the git core side. The git core side didn't _have_ to have them as part of its tree, but because it makes distribution to end users more convenient, and that was the reason why we have these as part of our tree. Theoretically, we could ignore the wish of git-gui/gitk projects and apply patches that touch these two parts directly to the git core tree, and let the maintainers of these projects deal with the consequences. They can cherry-pick only a part of your commit from the git core tree to their trees while still retaining their independence, for example, and my next merge from them will see "both sides added identically or made identical changes", which is not a huge deal. But that adds burden to integrators, which is not a scalable solution when contributors can make the burden smaller. The downside is of course the two projects won't be synchronised, but that is inherent---the contained projects do *not* want to be synchronised in the first place. The price these projects pay is that they cannot affect what is outside of their trees (e.g. they cannot add test scripts to our side to test the new feature in their new tree). Another downside, once "merge -s subtree" is made, is that tracking changes in such a semi-subproject in the context of the containing project becomes harder, as we will continuously seeing what is essentially a renaming merge. But it still is manageable as long as the merge is in one direction only. When inspecting the history of the contained project, you only need to find the last such merge to the containing project, and then follow the history of its second parent, whose history will _not_ contain anything from the containing project. The recent contrib/subtree merge (not to be confused with "merge -s subtree") follows quite an opposite approach from what was used for git-gui/gitk. It decided to cease to be an independent project to eventually integrate it as a part of the core, and further development of it will happen in the context of the layout of having the top of the last of its tree at contrib/subtree. Because it has involved a merge in the "merge -s subtree" style once, it is harder to track its history beyond that point, but by being the part of the larger tree from now on, we only have to suffer once---it is inconvenient to inspect the history before the merge, but that is a one-time transition pain. Incidentally, that is why I would be _very_ reluctant to take further merges for contrib/subtree if the merged history contain "git subtree" merges that ran "merge -s subtree" in both ways. It makes what is supposedly just a one-time transition pain to continuous one. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html