git branch -m lk0428-mytopic-nextstep lk0428-mytopic-nextstep (to rename).git merge lk0428-mytopic lk0426-mytopic-nextstep.git branch -m lk0426-mytopic lk0428-mytopic (to rename).git fetch & git checkout lk0426-mytopic-nextstep.git checkout -b lk0426-mytopic-nextstep.Another nice thing is that you should never have to run gclient sync when you switch between branches with the same base revision, unless some of your branches have changes to DEPS files. If you are able to remember which of your topic branches have gn changes and which don't (or I guess you could use git diff to figure this out), then you will also have a good idea whether you need to run gclient runhooks or not when you switch branches. Now that all your branch names are prefixed with the base revision (whether you use my naming convention or not), you can know before hand when you switch between branches on Windows whether you should expect a major rebuild, or a minor rebuild.I ( also have a script to update the base branch for topic branches and rename them - let me know if interested. lk0426-topic1, lk0426-topic2 for the topic branches that have all changes merged from lk0426. lk0426 for an LKGR branch created April 26th, then use e.g. To track which base branch topic branches are based off, you can use a naming convention I use e.g.Base all your different topic branches off of the same base branch I generally create a new LKGR branch once every 2-3 working days and then git merge it to all of my topic branches.(after LGTM and successful try): git cl commit (but note the tot-mytopic trick in the pipelining section below)Īvoiding excessive file changes (to limit amount of Visual Studio rebuilds when switching between branches):.(after git push from windows): git cl upload & git try.git commit -a -m "follow-up awesomeness".Windows: git fetch then git checkout mytopic.Linux: git branch mytopic (or you may want to use e.g.The rest of these instructions assume it is located at /home/username/chrome Create a git checkout on your Linux box, with read/write abilities, as per UsingGit. Please feel free to update the page with corrections and additions based on your experience. Please note that the instructions below are mostly from memory so they may be slightly incorrect and steps may be missing. 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. 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. In my experience ( this does not actually slow you down much, if at all. The disadvantage is that it adds an extra layer between the Chromium git repo and your Windows checkout. 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 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 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. This describes how you can use msysgit on Windows to work on the Chromium git repository, without setting up Cygwin or hacking the git cl, git try and other scripts to work under a regular Windows shell.
0 Comments
Leave a Reply. |