[webkit-dev] (no subject)

[Dirk Pranke]

On Mon, Feb 27, 2012 at 6:02 PM, Oliver Hunt <oliver at apple.com> wrote:
>
> On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote:
>
>> 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"
>
> This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included.
>
> Or do you mean git diff HEAD ?

I did not (i.e., I explcitly meant what you get with 'git diff' and
not 'git diff HEAD'). In order to include both staged and unstaged
changes, you would have to do 'webkit-patch -g HEAD' (just like you
would have to do 'git diff HEAD'). Your annoyance is duly noted, and
it might make more sense for 'HEAD' to be the default; if we did that,
though, we might want some other way to indicate "just the unstaged
changes" ...

As a broader point ... there are obviously a lot of different use
cases possible with git, and any logic we have is likely to work
really well for some and really annoy others. My thinking in proposing
the change above is that at least we'd match what git does by default,
and so it's fairly understandable (if you understand git).

We could also add some sort of preference to webkit-patch here ...
that has the usual discoverability issues, but might make sense given
git's TMTOWTDI nature.

-- Dirk