Changes between Version 47 and Version 48 of UsingGitWithWebKit


Ignore:
Timestamp:
Jul 9, 2010 3:52:08 PM (9 years ago)
Author:
ojan@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UsingGitWithWebKit

    v47 v48  
    7474== webkit-patch, check-webkit-style and git ==
    7575
    76 webkit-patch commands all work with git. There's a couple extra flags that help dealing with git branches and local commits, namely --squash, --no-squash and --git-commit.
    77 
    78 There are two camps on using git with webkit-patch. branch-per-bug and commit-per-bug. In the former, there is one patch per bug and all local commits are essentially one patch. In the latter, there's 1+ local commits per bug and possibly multiple bugs addressed on a single branch. The branch-per-bug use case is met entirely by always using --squash. The commit-per-bug use case is met by a combination of --git-commit and --no-squash, both of which have non-trivial and overlapping FIXMEs.
    79 
    80 If you get sick of typing --squash or --no-squash, you can set the webkit-patch.squash git config parameter to true/false.
    81 
    82 --squash: Treat all changes in the local branch as a single patch (local commits + working copy changes). Doesn't actually modify your tree until you land, at which point it squashes all local changes into a single local commit and then lands that.
    83 
    84 --git-commit: operate on the given git commit(s). Commits can be specified as single commits (e.g. HEAD^) or multiple (e.g. HEAD~2..HEAD).
    85  * FIXME: landing doesn't work if it needs to modify the ChangeLog https://bugs.webkit.org/show_bug.cgi?id=39073.
    86  * FIXME: When passing a commit range, all the commits get squashed into one. --git-commit should respect --squash and --no-squash instead.
    87  * FIXME: Until the above is fixed, specifying both should throw an error https://bugs.webkit.org/show_bug.cgi?id=38393.
    88 
    89 --no-squash: Operate only on working-copy changes, with the exception of webkit-patch land.
    90   land: If there are *only* working copy changes, commit them locally and then git svn dcommit. Otherwise, if there are local commits, then just git svn dcommit.
    91  * FIXME: --no-squash is unfinished. It needs a lot of work. It's not 100% clear what the right behavior is. Ideally someone from the commit-per-bug camp could iterate on this and make it work for that use-case. One world that would make things consistent and reliable: a) Always operate on both working copy changes and local commits. b) Always treat each local commit separately, not just for land, e.g., webkit-patch upload will upload each local commit and working-copy changes separately. FWIW, fixing --no-squash to operate on local commits is 99% of the work to making --git-commit ranges respect --no-squash.
    92  * FIXME: This also suffers from https://bugs.webkit.org/show_bug.cgi?id=39073 in the same way --git-commit does.
    93 
    94 If you leave out --squash and --no-squash and there's only a single local commit or only working copy changes in a branch, then the commands will work on that single patch. Otherwise they raise an error saying to use --squash or --no-squash.
    95  * FIXME: Make one of --squash or --no-squash the default. The current default is inconsistent and confusing.
     76webkit-patch commands all work with git. By default all webkit-patch commands will treat all changes in your branch as a single commit (i.e. all local commits + working copy changes get uploaded/committed as a single commit). To operate on a specific commit, use --git-commit=commitish or "-g commitish". "commitish" can be a single commit (e.g. HEAD^), a commit range (e.g. HEAD~3..HEAD~1, operates on HEAD~2 and HEAD~1 as a single commit) or the working copy (i.e., HEAD..).
    9677
    9778== Commit manually through git-svn directly ==