On Fri, 09 Mar 2012 17:55:59 -0800, Ryosuke Niwa <rn...@webkit.org> wrote:
On Mar 9, 2012 3:16 PM, "Pablo Flouret" <pab...@motorola.com> wrote:
On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva
<g...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
