 |
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. 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, 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.
