See the original GDoc document http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOTloamhkNm1ocw&hl=en to have access to the nice drawing ;-). http://docs.google.com/Doc?docid=0ARkLUElWcqxDZGdkOWo3c2ZfOTloamhkNm1ocw&hl=en
Erick
Git Notes
Following changes from a remote directory with custom modifications
Git provides tools which can be used to ease maintaining a set of patches in sync with an evolving project. The instrumentation of WebKit is an example of that kind of usage. The most interesting usage is the automatic application of modifications to newer code, when no conflicts arise. This can be done either by merging with newer commits or rebasing commits on top of newer ones. For a comparison between the two approches, see this blog post http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html. Rebasing will be preferred here because it allows an easier review of the commits by someone not familiar with the code by only requiring understanding how the changes are made related to a specific version of the master code.
However that kind of usage is potentially dangerous in a distributed version control system. It modifies the history of commits which renders merging between independently developed branches a lot harder when someone else has made commits on top of a rebased branch. Without care, it creates duplicates entries in the history. Even with care, it forces everyone with a copy of the branch to manually fix their history. See the official git-rebase documentation http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html, especially the section "Recovering from upstream rebase".
By leaving the old branches into place, we should avoid having people manually fix their history. They will simply have to track an additional branch each time we rebase the changes. It also has the effect of leaving previous versions available, should we need to reproduce the traces we made in the past (as long as the website's javascript code doesn't change significantly...).
In the case of WebKit, I suggest having branches with the following naming convention: "prof_svn<rev nb>" where <rev nb> is the svn revision number mentioned in the commit message of the base git commit. In the following example:
The profiler should have a branch name of "prof_svn40". After some time, when we want to profile a more recent version of WebKit we use the following commands:
git checkout master git pull upstream master # Add the latest changes in the master branch git log -n 1 # Retrieve the svn revision number from the commit message git checkout prof_svn40 # Switch to the profiler branch git checkout -b prof_svn42 # Create a new branch containing the same commits git rebase master # Rebase all the commits on top of the HEAD of master
We should end up with the following repository:
Note that further modifications of older branches will need to be ported manually to newer versions so we should restrain from doing this.
Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. Google Docs logo http://docs.google.com