This describes how you can use msysgit on Windows to work on the Chromium git repository, without setting up Cygwin or hacking the
git try and other scripts to work under a regular Windows shell.
The basic setup is to set up a regular git checkout on a Linux (or Mac) box, and use this exclusively to create your branches and run tools such as
git cl, and have your Windows box treat this git repository as its upstream.
The advantage is, you get a pretty clean setup on your Windows box that is unlikely to break when the various custom git tools like
git cl change. The setup is also advantageous if you regularly build code on Windows and then want to test it on Linux, since all you need to test on your Linux box is a
git push from Windows followed by building and testing under Linux.
The disadvantage is that it adds an extra layer between the Chromium git repo and your Windows checkout. In my experience (email@example.com) this does not actually slow you down much, if at all.
The most frequently used alternative to this workflow on Windows seems to be using Cygwin and creating a checkout directly according to the instructions at UsingGit. The advantage of that approach is you lose the extra overhead, the disadvantage seems to be mostly speed and having to run a Cygwin shell rather than just a normal Windows cmd.
Please note that the instructions below are mostly from memory so they may be slightly incorrect and steps may be missing. Please feel free to update the page with corrections and additions based on your experience.
Create your checkouts:
Starting a new topic branch:
git branch mytopic(or you may want to use e.g. the LKGR script from UsingGit).
git checkout mytopic
Normal workflow on Windows:
git commit -a -m "my awesome change"
git commit -a -m "follow-up awesomeness"
Normal workflow on Linux:
git pushfrom windows):
git cl upload && git try
git cl commit(but note the
tot-mytopictrick in the pipelining section below)
Avoiding excessive file changes (to limit amount of Visual Studio rebuilds when switching between branches):
git mergeit to all of my topic branches.
git diffto figure this out), then you will also have a good idea whether you need to run
gclient runhooksor not when you switch branches. Another nice thing is that you should never have to run
gclient syncwhen you switch between branches with the same base revision, unless some of your branches have changes to DEPS files.
git checkout lk0426-mytopic
git checkout -b lk0426-mytopic-nextstep
git fetch && git checkout lk0426-mytopic-nextstep
git merge lk0428 lk0426-mytopic
git branch -m lk0426-mytopic lk0428-mytopic(to rename)
git merge lk0428-mytopic lk0426-mytopic-nextstep
git branch -m lk0428-mytopic-nextstep lk0428-mytopic-nextstep(to rename)
Janitorial work on Windows:
lk0426-mytopicopen on Windows and then
git fetch, you will still have
lk0426-mytopiceven if that was renamed on the Linux side to
git checkout lk0428-mytopicto switch to the renamed (and likely updated) branch. Then
git branch -d lk0426-mytopicto get rid of the tracking branch for the older name. Then, occasionally,
git remotes prune originto prune remote tracking branches (you don't normally see these listed unless you do
git branch -a).
git pushfrom Windows will fail if your Linux repo is checked out to the same branch. It is easy to switch back manually, but I also have a script I call
safepushthat switches the Linux-side branch for you before pushing; let me (firstname.lastname@example.org) know if interested.