CC: debian-devel. Please subscribe to 
to follow this topic!

martin f krafft:
> also sprach Thomas Koch <> [2011.07.30.1229 +0200]:
> > Martin F. Krafft (madduck) was so kind to remind me posting this here.
> > We're right now at debconf discussing different patch mgmt workflows.
> > Thanks to contributions from Joachim Breitner and Guido G√ľnther I've
> > written down an appealing (IMHO) patch mgmt workflow:
> > 
> >
> Here's a summary of what Thomas told me about this:
>   1. you develop your features on branches, but you do not push the
>      branch heads;
>   2. the feature branches get merged into an integration/build
>      branch, which is pushed. This way, all contributors get the
>      commits;
>   3. as part of the build process, the feature branches are exported
>      to a debian/patches series, and each patch file includes
>      additional information, such as dependency data, and also the
>      SHA-1 of the feature branch head at the time when the patch
>      was made;
>   4. at a later stage, when someone wants to edit a patch, they can
>      create a branch off the SHA-1, merge the branch into the build
>      branch and provide the updated patch (with updated SHA-1), or
>      just provide an updated patch file and let the maintainer
>      update the branch with an interdiff.
> I see an advantage in this approach because it focuses on
> debian/patches/* rather than using a potentially-confusing set of
> branch heads.
> However, it employs a possibly brittle way to keep track of branch
> heads (SHA-1's in text files).
> The thing I do not like about it is that the build branch has all
> features merged (hence applied to the worktree), *in addition* to
> tracking the generated patch files in debian/patches/* in the
> repository.
> Finally, I would like to highlight that this is very much like the
> TopGit workflow used in mdadm, with the exception that features are
> not merged into the build branch, but instead the branch heads are
> kept around. It is my hope that I can simplify TopGit a bit to make
> this an equally viable approach, which would be more natural and
> closer to normal Git usage, at least to me.
> Cheers,
Hallo Martin,

seems you've also arrived well at home? Thank you for your additional 
explanations, I'll work them in my wiki page. I hope I can also address your 

It was my initial thought to work on build branches and merge the patch 
branches in, since this would reflect my latest personal workflow. This is 
however totally optional. The only thing needed is to get a hold on the 
commits to save them from garbage collection and a possibility to push them.

So as a variation of the described workflow you can establish a special branch 
that holds references to all feature branch commits in its history. The 
content of this branch does not matter. A status command should warn you if 
the head of any feature branch is not in the history this special branch. 
Another command could create a new commit in this special branch with the 
parent pointing to all new heads.

The concern about brittleness depends a bit on personal judgement. The 
greatest risk I see is that commit objects could be lost. The tools for this 
workflow should detect dangling commits in patch branches and print big 

The canonical information is stored in debian/patches/*. Inconsistencies 
between the patch branches and debian/patches/* can also be detected 

I had some time on my way back to think about patch bases. Is it right, that 
it isn't actually necessary to save the commit sha-1s of patch bases? It is my 
understanding that you could calculate them:

  1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES)
  2. for each $PATCH_BRANCH_HEAD
       if NOT $PATCH_BRANCH_HEAD in_history_of $CANDIDATE 
         echo "WARNING! $PATCH_BRANCH_HEAD has unmerged commits!"

I'll leave on a two weeks bycycle tour on wednesday and have a lot of time to 
think how the above could go wrong.

Best regards,

Thomas Koch,

vcs-pkg-discuss mailing list

Reply via email to