Re: [PATCH 1/1] Better document version ranking and 0
Manoj Srivastava <srivasta@debian.org> writes:
> I think the new commit goes on the branch, logically speaking,
> since it is part of getting the branch ready. And we really have two
> seconders sending in an ack, and we can record them separately, unless
> they come in close together. In that case, the branch history would be
> "proposed wording -- changes if any -- commit to show ack -- commit to
> show ack "; then
> git checkout master; git merge bug12345-owner
That makes sense, although we'll not want to commit changes to
debian/changelog or a similar file on the branch until right before the
merge or we'll get merge conflicts.
I'm still a little unclear on what commit messages the Acked-by lines go
into if there are several staggered over a period of time. A typical
working branch would have a few commits:
1. The initial wording proposal.
2. Additional tweaks to the wording as needed.
3. The final pre-merge commit with debian/changelog entires and whatnot.
Adding the Acked-by lines into the commit message for 3 makes sense to
me. That's the commit that declares the branch "final" and includes the
metadata saying that it's going into the next Policy release (the
debian/changelog and upgrading-checklist changes), so that's an
appropriate point to record the seconds.
But if we want to record a second in an intermediate commit between 2 and
3, what would we actually be committing? Making some change to a shared
file like debian/changelog seems to me to be just asking for merge
conflicts.
> Under gitk, all the development, acks, etc can be seen on the
> line belonging to the branch, and then when all is set, the branch is
> merged in to master.
>
> At this point, master is merged into all the pending bug
> branches by the owners, a git diff master bug12345-owner will show the
> exact changes being proposed by the unmerged branch.
Right. Something like:
for branch in `git branch | egrep 'bug[0-9]+-rra'`; do
git checkout "$branch" && git merge master
done
I'm not sure how to suppress the * in front of the default branch. I'm
sure there's some way, but running the above from master should be safe.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: