There are two kinds of commits on git-dpm master or whatever branch.
1) those commits that represent new sets of patches. these commits are created when someone does a git-dpm update-patches command. These commits are always merge commits between master and a old "patched" branch. 2) those commits that represent only changes to debian subdirectory. these commits are not merge commits ususally. In this message, I argue for a rule stating that the two types of commits should never be merged together by either 1) git commit --amend 2) git rebase -i squashing or fixing. People use git so that different sets of programmers can make asyncronous sets of edits at the same time. What happens when 2 sets of packagers are merging in commits that representing changes in patches? first set of packagers pushes. origin/master now contains a merge commit representing a git-dpm update-patches. second set of packagers fetches so origin/master now contains a merge commit representing a change of patches. But second set of packagers master branch now also contains another merge commit representing a change of patches. What should the solution be? I believe that in this case a simple merge or rebase is out of the question. Such a merge or rebase will probably involve conflict in the debian/patches subdirectory as well as conflict in the main upstream files' changes. The resolver must keep these conflict resolutions in sync. This is not a realistic solution. The chances of errors is overwhelming! NO! git-dpm was created so users do not have to think about this kind of stuff! The solution is to do a git-dpm checkout-patches on the origin/master branch and a git-dpm checkout-patches on the master branch. This will create 2 "patched" branches! These can be merged or rebased together to create a new combined "patched" branch. git-dpm update-patches can be called on this giving a new merge commit representing both side's patches. *) The commits from both sides which are changes to the debian sub-dir can be cherry picked or rebased onto and off we go! the 2 sets of changes are mixed to gether! But step *) above is impossible if the mods to debian subdir have been mixed in with patched commits! This is the reason for my rule! Rule says that commits that represent changes to the debian subdir shall never be mixed with merge commits that represent changes in patches! This applies to git --amend and git rebase -i squashing or fixing! I am interested in comments! show me where I am wrong! I believe this problem has not come up simply because there have not been multi person packaging teams yet! Please show me where I am wrong. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
Description: Digital signature
_______________________________________________ Git-dpm-user mailing list Gitfirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/git-dpm-user