[webkit-dev] Moving to Git?

[Pablo Flouret]

On Fri, 09 Mar 2012 17:55:59 -0800, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Mar 9, 2012 3:16 PM, "Pablo Flouret" <pablof at motorola.com> wrote:
>>
>> On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva  
>> <gns at gnome.org>
> wrote:
>>> Tbh, I am much more interested in doing away with ChangeLogs than in
>>> feeling good about using git push instead of git svn dcommit. If we
>>> could find a way around ChangeLogs while keeping svn, then I would be  
>>> an
>>> even happier panda than I am today =).
>>
>> +1
>
> We can do this without moving to git. Here's how it might work:
> 1. When writing a patch, add a new temporary file e.g. ChangeLogEntry  
> that
> stores new change log entry in each directory where ChangeLogs are  
> located.
> 2. ChangeLogEntry files are added to git/svn checkouts
> 3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla  
> shows
> ChangeLogEntry filesas new files (can be tweeked,of course)
> 4. Once you get r+, you land the patch. The commit message editor will
> automatically find ChangeLogEntry files and aggregate the result as the
> commit message.
> 5. You commit. The commit hook ensures no ChangeLogEntry files are  
> actually
> committed into the svn repository.

That doesn't sound like much of an improvement.

I'd prefer to see something closer to what 'git format-patch' spits out.
Basically you give it a commit range and it spits out one diff per commit,  
including the commit message.

This gives a couple of interesting options, like having a single patch  
which can contain multiple commits. Or you can do some mangling like  
webkit-patch does today to take a commit-range diff and pretend that it's  
a single commit.
I imagine it shouldn't be too hard to replicate the format for someone  
using just svn.
A tool's UI for editing the commit message for svn users (or for the  
squash case) could somewhat mirror what the git rebase ui does for  
squashing. So you'd have a patch that includes commit messages ready for  
reviewers' perusal (which i presume is the biggest reason changelogs still  
exist?)

In my most frequent workflow i make a patch, submit it, make a local  
commit in git for myself (in a branch) and then move on to other things  
(in a different branch perhaps). Then when review comments come in, i  
address them, make a local commit with those changes, and upload a patch  
by giving a range to webkit-patch. ChangeLog files are a pain in the ass  
in this case. Also, reviewers don't get to see what changed between the  
two patches i uploaded, which a patch coming from format-patch would show.  
A final, squashed patch could be required for landing. Or both types could  
be submitted through webkit-patch and available in bugzilla. Or something  
else.

Anyway, just brainstorming a bit, haven't thought this through that much.

-- 
pablo flouret
motorola | webkit / browser team