Dear git people, The rsync source repository has recently been migrated from CVS to git at my encouragement ( http://git.samba.org/rsync.git/ ), and I am trying to figure out a better way to structure the repository (to propose to the maintainer, Wayne Davison, or to use myself). Rsync presents a unique challenge because it has a number of long-term feature patches that are maintained and distributed with the main source code. Furthermore, some of the patches depend on other patches. With CVS, the patch files were just stored in the repository; this worked, but browsing and developing the branched versions represented by the patches required a lot of extra work. My hope now is to represent these branches and their dependencies properly in git so that the git tools handle them with the same elegance with which they handle everything else. The feature branches seem to present two fundamental problems: 1. How to properly represent the history of an individual branch and update it when the trunk (or the branch on which it depends) changes. Right now, Wayne updates the branch by rebasing; unfortunately, if the trunk changes in such a way that one of the intermediate commits no longer makes sense, it is impossible to update the branch while preserving a record that the intermediate commit once existed. Merging gives the right history and is very well-supported by the git tools, but it has one fatal flaw: when a dependency on another branch is removed, there is no way to undo the merge of the other branch. One can revert the tree changes, but the other branch is still present in the ancestry, which causes problems if the dependency is added again. It seems to me that overcoming this flaw would require significant changes to git. Is there some other workflow that does what is needed? Ideally "git blame" would work correctly. 2. How to manage the large number of branches in a practical way. The branch dependency information should be pullable from the main repository to minimize the need for each developer to configure his/her repository manually on initial cloning and when dependencies change. Also, for an rsync release, it should be possible to tag the trunk and all branches as a unit so that developers can ask questions like "which branches changed between these two pre-releases?". My feeling is that the solution will involve a taggable, pullable master tree object that contains the trunk and branches as submodules and also some metainformation (including the dependencies). However, special scripts will then be needed to conveniently check out and update the submodules using a single rsync source/build tree. I'm sure the rsync project could make do without a fully general solution for the feature branches, but it would be awesome (and a testament to git's flexibility) if one existed. Also, Linux distributions maintain packages with evolving and potentially interdependent packages, and a good solution would make it possible for them to do all their package maintenance and patching with git. Ubuntu [1] and Fedora [2] are thinking about this. From my perspective, such a setup would make modifying distribution packages much less painful. [1] https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl [2] http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=38716&start=0#forumpost175743 I would appreciate any ideas toward a solution. I am not subscribed to the list (I once was but the traffic overwhelmed me), so please be sure to CC me in replies. Matt - 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
