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
   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               PMB 181, 11900 Metric Blvd Suite J   Austin TX 78758-3117

Attachment: signature.asc
Description: Digital signature

Git-dpm-user mailing list

Reply via email to