Differences between revisions 26 and 28 (spanning 2 versions)
Revision 26 as of 2008-04-12 17:35:40
Size: 5247
Editor: GuillemJover
Comment: Add step about self building dpkg
Revision 28 as of 2008-04-29 12:05:35
Size: 5441
Editor: SvenJoachim
Comment: git co does not work, use git checkout instead
Deletions are marked like this. Additions are marked like this.
Line 62: Line 62:
 * To update the repository use the commands: {{{git fetch && git rebase origin/master}}}    * If updating for lenny:
     * Switch to that branch: {{{git checkout -b lenny origin/lenny}}}
     * Use origin/lenny as <remote>.
   * If updating for lenny+1:
     * Use origin/master as <remote>.
 * To update the repository use the commands: {{{git fetch && git rebase <remote>}}}
Line 68: Line 73:
If the {{{git push}}} fails, redo the command {{{git fetch && git rebase origin/master}}} 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. 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.
Line 71: Line 76:
 * {{{git rebase -i origin/master}}}  * {{{git rebase -i <remote>}}}

Git usage in the dpkg team

Recommandations for handling the [http://en.wikipedia.org/wiki/Git_%28software%29 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.
    • Check the ["Alioth/FAQ"] if you want to verify the public SSH host key.
  • For anonymous: git clone git://git.debian.org/git/dpkg/dpkg.git

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:

First line should be a small summary

* src/file.c (foo): Made the foo() function check bla to avoid stuff.
* src/other.c: Fixed usage of foo() to match the previous change.
  • The extended description should follow the [http://www.gnu.org/prep/standards/html_node/Change-Logs.html GNU ?ChangeLog format].

  • 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 [http://www.backports.org backports.org].

How to release

  • Verify that you're in sync with the remote repository.
  • Finalize the changelogs, update the version in configure.ac, commit the changes.
    •  git commit -a -m "Release <version>" 

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

  • Generate a source tarball:
    • 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

    • git push origin refs/tags/<version>

  • Upload to Debian.
  • For a release from the stable branch:
    • Switch to the master branch
    • Merge the stable branch (fix conflicts on changelogs).
    • Commit and push.
  • For a release from the master branch:
    • Start a new version:
      • On configure.ac, use '<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 lenny:
      • Switch to that branch: git checkout -b lenny origin/lenny

      • Use origin/lenny as <remote>.

    • If updating for lenny+1:
      • 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:

  • git rebase -i <remote>

  • You get a list of your own commits that are going to be rebased, each line starts with pick. You have top edit that list so that the first line contains a pick command and the subsequent one contain a squash command. See example below:

Before:

pick 7ce2b6c Log message of the first commit
pick 2fbd2c4 Log message of the second commit
pick 9d3196a Log message of the third commit

After:

pick 7ce2b6c Log message of the first commit
squash 2fbd2c4 Log message of the second commit
squash 9d3196a Log message of the third commit
  • Once you save the file and exit the editor, the process starts and you'll soon be asked to provide a new log message for the single commit that will replaces the multiples ones.
  • When it's over, you can proceed to push the changes.


EddyP: Wouldn't it be easier to advice translators who want to use several local commits, to use a local branch, and at the end git checkout master && git merge --squash translationbranch instead of the complicated file editing?