Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/Git"
(→Current Repos) |
(→Current Repos) |
||
Line 43: | Line 43: | ||
# commit them with a useful commit message | # commit them with a useful commit message | ||
# add 2 tags. One will be ''initial-import''. The other should be a time tag, like v20101124-0800 | # add 2 tags. One will be ''initial-import''. The other should be a time tag, like v20101124-0800 | ||
+ | # I split the next step up into 2: | ||
+ | ## git push origin master | ||
+ | ## git push --tags origin | ||
+ | |||
Revision as of 10:57, 24 November 2010
For working in git lately I've been using the latest eGit. Functionality has been increasing week over week, so I just use their latest nightly:
http://download.eclipse.org/egit/updates-nightly
Some resources:
- Git - http://git-scm.com/
- Pro Git - http://progit.org/book/
Git in e4
We have a place in e4 for git repositories.
Current Repos
- git://git.eclipse.org/gitroot/e4/org.eclipse.e4.deeplink.git
- git://git.eclipse.org/gitroot/e4/org.eclipse.e4.utils.git
- git://git.eclipse.org/gitroot/e4/org.eclipse.e4.installer.git
- git://git.eclipse.org/gitroot/e4/org.eclipse.e4.search.git
A repo then follows our standard subdir convention:
- bundles
- features
- examples
- tests
When creating a repo on the server, follow these steps (Please update them if there are better steps :-)
- log into git.eclipse.org
- cd /gitroot/e4
- mkdir component.id.git # ex: mkdir org.eclipse.e4.search.git
- cd component.id.git
- git init --bare
This creates a bare repo that can be cloned. Then on your work machine
- git clone ssh://pwebster@git.eclipse.org/gitroot/e4/component.id.git
- cd component.id
- mkdir bundles features examples tests
- add a useful .gitignore. See below
- copy in your plugins into bundles, features into features, test plugins into tests, etc
- add all of your files: git add -A
- commit them with a useful commit message
- add 2 tags. One will be initial-import. The other should be a time tag, like v20101124-0800
- I split the next step up into 2:
- git push origin master
- git push --tags origin
Example .gitignore
bin/ *~ *.rej *.bak
We build our git repos still using map files, checked into CVS in the /cvsroot/eclipse e4/releng module.
Submitting for a build
We have 2 scripts used for submitting for the build. One to update the map files, and one to generate the submission report for our mailing list e4-dev@eclipse.org
git-map.sh is used to update the map files.
git-submission.sh is used to generate a build submission report.
Note: We have a policy that all commits have the associated bug number. Usually our format is:
Bug <number> - <bug title>
and then any specific comments after the title or on the next line. It's important that we only list 1 bug # per line, and at the beginning of the line. A line with "bug #" or "Bug #" without the title is also acceptable.
When ready to submit deeplinking for the build, you have to submit 2 repos, org.eclipse.e4.deeplink and org.eclipse.e4.utils. For each repo:
- cd into the repo (make sure it's up to date, you're on the master branch, etc)
- tag the repo: git tag v20101022-1030 # we use vDATE-TIME as our tag
- make sure you push the tag back to the public repo
- run the script (see example below)
- You'll have to execute the script for each subdiretory: bundles, examples, features, tests.
- Repeat the steps for the second repo.
- Then refresh your workspace and commit.
git-map.sh example:
$ /bin/bash git-map.sh v20101022-1030 /opt/pwebster/workspaces/e4/releng/org.eclipse.e4.deeplink.releng/maps/deeplink.map bundles
Then when done you can generate your build submission report for the e4-dev list:
$ /bin/bash git-submission.sh >report.txt