Difference between revisions of "Development using git:Developer repositories"

From Alpine Linux
Jump to: navigation, search
(explain when git send-email should be used instead of the developer repo)
(reword a little to make text fit more with the distributed workflow diagrams)
Line 1: Line 1:
Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access can review and pull from this or can choose to reject if the changes needs more fixing.
+
Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.
  
 
The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.
 
The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.
  
 
== Git Push (Distributed Workflows) ==
 
== Git Push (Distributed Workflows) ==
If working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developer ''(who has write access to public repository)'' 'pulls' you changes from your publically accessed repository into the public repository.  
+
When working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.  
  
To make it easier for you to work, you can configure 'git push' to push your work to your publically accessible repository ''('git pull' would still pull from same repository as you cloned from)''.
+
To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
 
{{cmd|cd /your/private/repo/where/you/work/reponame
 
{{cmd|cd /your/private/repo/where/you/work/reponame
 
git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}
 
git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}
Now 'git pull' pulls the public repository and 'git push' pushes to '''your''' public repository.
+
Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.
 
{{Note|The path where you want to push to should first be prepared with {{cmd|git clone --bare ...}} as described below in section 'Upload the new project'}}
 
{{Note|The path where you want to push to should first be prepared with {{cmd|git clone --bare ...}} as described below in section 'Upload the new project'}}
  
Line 15: Line 15:
 
Before asking for merging the developer repo into the official make sure that:
 
Before asking for merging the developer repo into the official make sure that:
 
# All modified packages builds
 
# All modified packages builds
# The commit history looks nice. You can use the [http://git.alpinelinux.org/cgit cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future. So avoid changing multiple packages with single commits.
+
# The commit history looks nice. You can use the [http://git.alpinelinux.org/cgit cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.
  
 
Before asking for a pull, rebase your public repo with the official repo. This is done with:
 
Before asking for a pull, rebase your public repo with the official repo. This is done with:
{{Cmd|git pull --rebase}}
+
{{Cmd|git pull --rebase
{{Cmd|git push}}
+
git push}}
  
 
If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.
 
If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.

Revision as of 20:07, 16 May 2012

Some git repositories of Alpine developer are hosted at git.alpinelinux.org. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, integration managers, can review and pull from this or can choose to reject if the changes needs more fixing.

The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use git send-email. It might also be better to use git send-email for single commits.

Git Push (Distributed Workflows)

When working with Distributed Workflows you would 'pull' from public repository, 'push' to another publically accessible repository (where you have write access), main developeres or integration managers who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).

cd /your/private/repo/where/you/work/reponame git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"

Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to your public developer repository.

Note: The path where you want to push to should first be prepared with

git clone --bare ...

as described below in section 'Upload the new project'

Requesting a pull from developer repo to official

Before asking for merging the developer repo into the official make sure that:

  1. All modified packages builds
  2. The commit history looks nice. You can use the cgit interface for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.

Before asking for a pull, rebase your public repo with the official repo. This is done with:

git pull --rebase git push

If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.

You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. git://git.alpinelinux.org/user/aports.git) that can easily be copied and pasted and please also mention why the merge is needed. This explanation is meant to be copied and pasted in the merge commit.

Example request on IRC:

please pull git://git.alpinelinux.org/ncopa/aports
It includes a new python application pyfoo with all its dependencies.

Example email:

Subject: please pull git://git.alpinelinux.org/ncopa/aports

The libfoo was upgraded to 2.0. This upgrade breaks ABI so all packages linking
to libfoo was rebuilt. The rebuilt packages was:
- libbar
- bazapp
- bar-utils