Differences between revisions 38 and 39
Revision 38 as of 2012-07-25 18:20:07
Size: 5925
Editor: ThomasKoch
Comment:
Revision 39 as of 2014-05-03 23:36:37
Size: 6058
Editor: GuillemJover
Comment: Update with current times, minor typo fixes, minor rewording
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= Git usage in the dpkg team = = git usage in the dpkg team =
Line 4: Line 4:
Recommendations for handling the [[http://en.wikipedia.org/wiki/Git_%28software%29|Git]] repository. Recommendations for handling the [[http://en.wikipedia.org/wiki/Git_%28software%29|git]] repository.
Line 15: Line 15:
   * Guillem Jover: {{{ git://git.hadrons.org/git/debian/dpkg.git}}} ([[http://git.hadrons.org/?p=debian/dpkg.git|web]])    * Guillem Jover: {{{ git://git.hadrons.org/git/debian/dpkg/dpkg.git}}} ([[http://git.hadrons.org/?p=debian/dpkg/dpkg.git|web]])
Line 22: Line 22:
   * etch, lenny, squeeze: branches for corresponding Debian release    * etch, lenny, squeeze, wheezy: branches for the corresponding Debian release
Line 29: Line 29:
 * Do not forget to let [[Git]] know who you are: {{{git config user.name "John Doe" && git config user.email my.email@addre.ss}}} (you can also use the {{{--global}}} option if you want to configure it the same for all git repositories)  * Do not forget to let git know who you are: {{{git config user.name "John Doe" && git config user.email my.email@addre.ss}}} (you can also use the {{{--global}}} option if you want to configure it the same for all git repositories)
Line 46: Line 46:
   * {{{ git commit -a -m "Release <version>" }}}    * {{{dch -r }}}
   * {{{
git commit -a -m "Release <version>"}}}
Line 50: Line 51:
   * {{{git clean -Xdf}}}
Line 78: Line 80:
     * Use origin/wheezy as <remote>.
   * If updating for jessie:
Line 87: Line 91:
<!> Git, as a distributed VCS, allows you to make multiple commits without pushing your changes back, please avoid that if possible. We advise you to not multiply commits uselessly because they clutter the historical log and it's more difficult to see important changes on the code (instead of the translations). If you have multiple commits waiting to be pushed, Git offers you a possibility to "merge" them in a single commit. Proceed as following (we assume you're on the branch where you did the mutiple commits, all the changes are already commited, and the branch is named $BRANCH): <!> git, as a distributed VCS, allows you to make multiple commits without pushing your changes back, please avoid that if possible. We advise you to not multiply commits uselessly because they clutter the historical log and it's more difficult to see important changes on the code (instead of the translations). If you have multiple commits waiting to be pushed, git offers you a possibility to "merge" them in a single commit. Proceed as following (we assume you're on the branch where you did the multiple commits, all the changes are already commited, and the branch is named $BRANCH):

git usage in the dpkg team

Recommendations for handling the git repository.

URLs

  • For committers:
    • git clone ssh://git.debian.org/git/dpkg/dpkg.git

    • See ?Alioth/SSH for instructions to configure your SSH access.

  • For anonymous: git clone git://git.debian.org/git/dpkg/dpkg.git

  • Web view: http://git.debian.org/?p=dpkg/dpkg.git

  • Private repositories of current maintainers:
    • Raphael Hertzog: git://git.debian.org/~hertzog/dpkg.git (web)

    • Guillem Jover:  git://git.hadrons.org/git/debian/dpkg/dpkg.git (web)

Public branches

  • In the main repository we have the following branches:
    • master: main development tree
    • sid: bug fixes only branch (used when important fixes have to be pushed out before the end of the current development cycle)
    • etch, lenny, squeeze, wheezy: branches for the corresponding Debian release
    • test-build: branch containing a version that should be run (and thus tested) by all contributors and also any external beta-tester, it's usually a snapshot of master or a merge of several branches
    • all other branches are "topic" branches which are renamed with a "merged-" prefix once they are not relevant any more.
  • In the private repositories of maintainers, you might find other topic branches. Beware that those prefixed with "pu/" are "proposed-updates" that can be rebased at any time, don't use them for long-lived work.

Generic recommendations

  • Do not forget to let git know who you are: git config user.name "John Doe" && git config user.email my.email@addre.ss (you can also use the --global option if you want to configure it the same for all git repositories)

  • When you write commit messages, try to follow the recommended format:

possible-subsystem: short summary

The rest is the long description. It explains the change in more
details and gives the rationale associated to it. You can be as
verbose as you want.
  • If you commit someone else's work, please use git commit --author "Random Joe <his.email@isp.com>" to properly attribute the change.

  • If you're working on a patch that will take some time to be merged, better work on it in a private topic branch that you can rebase (later and as many times as you want) before merging it in the master branch and pushing it. This will avoid cluttering the history with merge commits.
  • Use git 1.5.x at least. If you run etch there are backports on backports.org.

How to release

  • Verify that you're in sync with the remote repository.
  • Finalize the changelogs, commit the changes.
    • dch -r 

    • git commit -a -m "Release <version>"

  • Create a signed tag:
    • git tag -m "Release <version>" -s <version>

  • Generate a source tarball:
    • git clean -Xdf

    • autoreconf -f -i; ./configure; make distcheck

  • Do the real build based on the generated tarball.
  • In general, install the resulting packages and rebuild
    • (this ensures the generated packages are accepted by the archive).
  • Push stuff to the remote repository:
    • git push origin master <version>

  • Upload to Debian.
  • For a release from the sid branch:
    • Switch to the master branch.
    • Merge the sid branch (fix conflicts on changelogs).
    • Commit and push.
  • For a release from the master branch:
    • Start a new version:
      • On debian/changelog, '<version>' and suite UNRELEASED (dch -i should do).

    • Commit and push.

For translators

  • To setup the repository:
    • Clone the repository as above.
    • Enable the pre-commit hook with chmod +x dpkg/.git/hooks/pre-commit (this will prevent committing conflicts by error)

    • Tell Git who you are: git config user.name "John Doe" && git config user.email my.email@addre.ss

    • If updating for squeeze:
      • Switch to that branch: git checkout -b squeeze origin/squeeze

      • Use origin/squeeze as <remote>.

    • If updating for wheezy:
      • Use origin/wheezy as <remote>.

    • If updating for jessie:
      • Use origin/master as <remote>.

  • To update the repository use the commands: git fetch && git rebase <remote>

  • Once you finished your work use the following commands to commit and push your changes:
    • git add <list of modified files>

    • git commit

    • git push

If the git push fails, redo the command git fetch && git rebase <remote> and try again. Note that git rebase can be interrupted if there's a conflict between your work and the changes made on the remote repository. In that case, fix the conflicts by editing the conflicted files, then git add <conflicted files> and ask the rebase process to continue with git rebase --continue. Once it's over, git push should work.

<!> git, as a distributed VCS, allows you to make multiple commits without pushing your changes back, please avoid that if possible. We advise you to not multiply commits uselessly because they clutter the historical log and it's more difficult to see important changes on the code (instead of the translations). If you have multiple commits waiting to be pushed, git offers you a possibility to "merge" them in a single commit. Proceed as following (we assume you're on the branch where you did the multiple commits, all the changes are already commited, and the branch is named $BRANCH):

  • git branch -f l10n (create a new branch l10n containing all your changes, remove any preexisting l10n branch)

  • git reset --hard origin/$BRANCH (drop your changes in the current branch)

  • git merge --squash l10n (merge your changes in a single commit, you have to edit the commit message)

  • You can proceed to push the changes.


CategoryGit