[webkit-dev] (no subject)

Dirk Pranke dpranke at chromium.org
Mon Feb 27 17:56:03 PST 2012

Hi all,

If you don't use webkit-patch and Git, you can stop reading now. Otherwise ...

Currently, webkit-patch -g has some special logic for figuring out
what to diff against for Git checkouts.

Specifically, webkit-patch "-g commitish" gets translated to the git
equivalent of 'git diff commitish^..commitish'. Then, we have an
additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to
pick up any uncommitted changes, and if nothing is specified, we will
attempt to diff against the remote master/trunk version.

This is very useful if you typically want to just upload a single
commit issue, but is a bit un-git-like, and actually thwarts some
other use cases.

My questions are:

1) Do you use "-g foo" to upload a single change? If so, would you be
annoyed if I changed that syntax to a different argument, or
eliminated it completely (so that you would have to type foo^..foo)?

2) Do you object to changing the default to match what 'git diff'
does? This would change the defaults so that:
  a) instead of no arguments meaning "diff against remote master", it
would mean "diff against what is staged for commit"
  b) 'git diff commitish" would show the diff between commitish and
your current working directory

If there is a consensus that we shouldn't change the defaults, I will
likely implement a different command line argument that does mirror
what git does.

As an aside, I will probably be adding a patch that will figure out
what the 'tracking' branch (as defined by branch.<branchname>.merge)
is for your current checkout, and give webkit-patch a way to use that
instead of the remote head (this would make using stacked local
branches much easier). I haven't decided if this should be the default
or if you should have to request this via something like 'webkit-patch
diff -g UPSTREAM' instead; if you have an opinion, feel free to

There is a bug tracking this work at
https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment
there instead of here or follow along with whatever ends up happening.


-- Dirk

More information about the webkit-dev mailing list