CC: debian-devel. Please subscribe to vcs-pkg-discuss@lists.alioth.debian.org
to follow this topic!
martin f krafft:
also sprach Thomas Koch tho...@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
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
