[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: