Re: Patch mgmt workflow proposal
CC: debian-devel. Please subscribe to vcs-pkg-discuss@lists.alioth.debian.org
to follow this topic!
martin f krafft:
> also sprach Thomas Koch <thomas@koch.ro> [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:
> >
> > http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow
>
> 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
concerns.
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
warnings.
The canonical information is stored in debian/patches/*. Inconsistencies
between the patch branches and debian/patches/* can also be detected
automatically.
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, http://www.koch.ro
Reply to: