I would also like to add that I intend to use this repository for other things than code. It can be used to help us synchronize work on papers to be published, for example. This kind of use is better served by a private repository.
- Maxime
Maxime Chevalier-Boisvert wrote:
Do we actually want our code to be immediately publicly available?
Don't forget we're actually going to be competing with other teams.
Marc? What's your opinion?
- Maxime
Erick Lavoie wrote:
I chose to set up the git repository at Gitorious mainly for the following reasons:
- No administration of users/git server/etc on OS X, simply
high-level management of users on Gitorious 2. Public repository so anybody can clone our project on Gitorious and eventually provide patches 3. Free and no publicity 4. No security hassle
The repository will be essentially a mirror of the official WebKit git repo with our own branches for our work. We will be able to share our changes through it.
It won't be automatically kept in sync with the WebKit repo because we don't need to. However, it should be fairly easy from time to time to reapply our modifications on top of the latest version of WebKit by manually fetching the latest commits from WebKit and doing a "git-rebase" on top of the latest revision. We will be able to tag the project at different points to still have access to earlier work.
Example Scenario:
- We instrument WebKit for logging traces in a branch forked from the
current up-to-date Webkit Repo 2. Let's say we publish results on traces done. We git-tag the current HEAD of our branch with a name like "Conference XYZ". 3. Further work is done on the main WebKit project. 4. We decide to regenerate traces for a newer WebKit for another paper. We obtain the latest commits from Webkit with git-fetch, then git-rebase all the work we have done on top of the newer version, resolving conflicts along the way. We git-tag the current HEAD of our branch with "Conference ABC". 5. Etc. until WebKit considers our work to be oh-so wonderful that they decide to integrate it. We then submit a single patch with all our changes (on top of the latest WebKit revision) using git-diff.
The really interesting thing is that git-rebase, git-fetch, git-tag and git-diff automate most of the work we need to do to follow the WebKit project without continually having to resolve conflicts because they are working on similar parts of the code base, as would be the case with svn.
The same steps would equally apply to a rewriting of the javascript engine.
The project can be found at:
I will push the 1.7 GB of commits from WebKit later today, when I am on the campus network.
Erick
Le 10-05-02 10:23 , chevalma@iro.umontreal.ca a écrit :
This should be easier to work with than the svn bridge, but will you still be setting us up a repository based on this? We need somewhere to keep our own code so we can easily share it (and have it backed up).
- Maxime
Here is a link to the wiki page describing how to use git with webkit:
http://trac.webkit.org/wiki/UsingGitWithWebKit
There is really nothing fancy to do, since we are not committers on webkit. Simply:
git clonegit://git.webkit.org/WebKit.git WebKitEach revision in svn corresponds to a different commit in git. In bonus the whole repository in git is 1.7 GB compared to 2.0 GB for the latest revision checkout of the svn repo!
Erick _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list