Re: Migrating debian policy into a git repository

[Russ Allbery <rra@debian.org>]

Manoj Srivastava <srivasta@debian.org> writes:

>         The next proposal was to have per-member topic branches -- in
>  other words, every team member opens a new branch for each topic they
>  are working in, using branch names like bug12345-manoj.  This way, it
>  is easy to see who is working on what, and which issues are being
>  considered for inclusion in the next release of policy.
>
>         While usually only one of us works a topic for packaging, this
>  scheme allows there to be multiple solutions that can be discussed in
>  parallel, in case of need. It also allows people to create branches
>  without name space conflicts, simply. 
>
>         The topic branch bug12345-manoj is public, allowing for
>  discussion; people on the policy team can voice their approval on the
>  mailing list, and the branch owner can use git --amend to add in the
>  approves line into the HEAD.,
>
>         When a consensus emerges, and the final wording exists in one of
>  these topic branches, it can be squished/rebased into master, and we
>  move on to the next issue.

This sounds very good to me (I think the diagram included wasn't the right
one, though).  I like this idea.

Are we generally standardizing on using git merge --squash to merge those
per-bug branches onto master?  Also, are we rebasing bug branches?  Since
they're public, I wasn't sure if that was a good idea, but I'm still a bit
fuzzy on the strategies.

For simple build-system changes, typo fixes, fixes for references to
external man pages and other informative changes, and the like, do we
still use a branch or should Policy team maintainers just commit directly
to master?

What would help me a lot is if someone wrote up specific step-by-step git
commands for the common operations on the repository.  I want to
understand the theory too, but I always understand theory better by
starting from a practical set of instructions and then investigating
further why things are working that way.  For example, is this correct for
working on bug 12345 (omitting all of the steps of waiting for discussion
and consensus, and starting with no repo at all):

    git clone ssh://rra@git.debian.org/git/dbnpolicy/policy.git
    cd policy
    git checkout -b bug12345-rra
    # edit files
    # git add files
    git commit
    git push origin bug12345-rra # is this right?
    # iterate until good
    git checkout -b master
    git merge --squash bug12345-rra
    git commit
    git push origin master
    git branch -d bug12345-rra # how do I do this on the shared repo?

If I can get feedback and clarification on the above, I can start using
the new repository and get my still-pending bug branches loaded into it.
I may need some verification for a while that what I'm doing with git is
the right way to do it, since I'm pretty new to DVCSes.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>