[Webkit-unassigned] [Bug 71262] Web Inspector: Add colorpicker functionality to color swatches in Styles Sidebar

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Nov 28 12:35:36 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=71262





--- Comment #26 from Alexander Pavlov (apavlov) <apavlov at chromium.org>  2011-11-28 12:35:36 PST ---
(In reply to comment #24)
> Thanks for replying to this.  I am already on a topic branch, not sure if that was clear or not.  I understand what you are saying about making a new branch and applying a patch to get a fresh state - I'll do that along with the other changes for the next patch.  
> 
> Being new to this project, I want to make sure I am doing this right.  I have been looking through all the docs I can find on contributing, but still have a couple questions about this (maybe I am just missing something):
> 
> 1) Why can't I generate the changelog from multiple commits?  It seems silly that you have to squash all your commits into one for a changelog, since you don't have to do that for a patch.  I like to do small commits so I can see related changes together, and rebasing them together seems like counterproductive work to me.  Is there a way to just generate one from a patch?

I believe it's a limitation of prepare-ChangeLog - it was originally written for svn (which is the VCS for webkit). Eric Seidel is the webkit tool master who usually handles this kind of issues.

> 2) When you do a branch like this, do you rebase into master every time you want to generate a patch?  What if you need to make changes to the patch based on feedback - do you revert the rebased commit, then rebase again, then generate the ChangeLog again, then do a patch?  What if I have updated from origin/master in the meantime and had to resolve conflicts - do you have to do that every time also?  Maybe I am just misunderstanding what you meant by this.

My workflow is close to the following:

Pull in the latest changes from the repo:
[master]
git pull
git svn rebase
git checkout topic

[topic]
git rebase master
...edit...
git commit / git commit --amend (I keep no more than one commit in the topic branch for the sake of prepare-ChangeLog)
(optionally goto begin)

Upload a patch:
Tools/Scripts/prepare-ChangeLog -g HEAD --bug=<bug_number>
...edit ChangeLogs...
git commit -a --amend
Tools/Scripts/webkit-patch upload

Hope this helps.

And sorry for the confusion about the colors: I don't remember when I used keywordish colors last :)

> (In reply to comment #21)
> > (In reply to comment #20)
> > > Created an attachment (id=116686)
 --> (https://bugs.webkit.org/attachment.cgi?id=116686&action=review) [details] [details] [details]
> > > Updating whitespace / webkit style
> > > 
> > > This handles most of the feedback from my latest patch.  I realize there isn't a changelog entry here.  I am having a hard time generating a changelog from multiple git commits, and am not able to easily rebase now that I have merged from master.  Any tips for handling this?  I basically want to generate a changelog based on 3 or so commits, separated by multiple merged commits if that makes sense.  Here is the output when I try to generate the changelog (my last commit was reverting the latest changelog):
> > > 
> > > Tools/Scripts/prepare-ChangeLog --git-commit HEAD --bug 71262
> > >    Running status to find changed, added, or removed files.
> > >    No changes found.
> > 
> > Well, I usually do "git rebase master" instead of "git merge master", since rebasing is what you most likely want to do, that is, apply your current changes on top of the current master state, instead of the reverse (applying your latest master on top of you changes). Actually, "git merge" is intended for the opposite task, according to "git help merge": apply your development branch changes to the master branch (since it modifies the commits from the branch merged).
> > 
> > In situations like yours (branch goofed up), I usually run "git diff master > work.patch", branch off of master (e.g. git checkout -b topic master) and apply work.patch against the "topic" working copy: patch -p1 -F3 < work.patch (-F3 handles ChangeLog merges if you are having problems with them, but may ruin your source code merges if the code you have changed also got changed in "master" - use with care.) Then commit and "git show > colorpicker.patch" (you have the only commit after "master" in your "topic" branch now.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list