I've recently been using a supporting utility I called "git-cl": http://neugierig.org/software/git/?r=git-cl (just one file, viewable here: http://neugierig.org/software/git/index.cgi?url=git-cl/tree/git-cl ) This lets you associate git branches with a Rietveld issue, and then when it's time to commit, it squashes the branch into one svn commit and uses the description from the issue as the description of the commit. I was easily juggling three separate reviews in the same working copy without needing to remember any issue numbers.
Example workflow: # check out a git-svn repo, make a branch, and hack on it $ git svn clone svn://whatever; cd whatever $ git checkout -b mywork $ hack; git commit
# tell git-cl some info about your project. $ git config rietveld.server "localhost:8080" $ git config rietveld.cc "my-discussion-l...@gmail.com"
# upload the branch for review. this runs upload.py and prompts you for the message, etc. # if you run it again later it sends a follow-up patch to the previous review. $ git cl upload git-svn # the last arg here is passed to upload.py; here it means "diff against svn trunk"
# see status. prints out issue number and description from rietveld site. $ git cl status
# commit the branch to the git-svn repo. $ git cl dcommit
On Mon, Aug 18, 2008 at 6:12 AM, Evan Martin <mart...@danga.com> wrote:
> I've recently been using a supporting utility I called "git-cl": > http://neugierig.org/software/git/?r=git-cl > (just one file, viewable here: > http://neugierig.org/software/git/index.cgi?url=git-cl/tree/git-cl ) > This lets you associate git branches with a Rietveld issue, and then > when it's time to commit, it squashes the branch into one svn commit > and uses the description from the issue as the description of the > commit. I was easily juggling three separate reviews in the same > working copy without needing to remember any issue numbers.
> Example workflow: > # check out a git-svn repo, make a branch, and hack on it > $ git svn clone svn://whatever; cd whatever > $ git checkout -b mywork > $ hack; git commit
> # tell git-cl some info about your project. > $ git config rietveld.server "localhost:8080" > $ git config rietveld.cc "my-discussion-l...@gmail.com"
> # upload the branch for review. this runs upload.py and prompts you > for the message, etc. > # if you run it again later it sends a follow-up patch to the previous review. > $ git cl upload git-svn # the last arg here is passed to upload.py; > here it means "diff against svn trunk"
> # see status. prints out issue number and description from rietveld site. > $ git cl status
> # commit the branch to the git-svn repo. > $ git cl dcommit
On 18 aug, 01:12, "Evan Martin" <mart...@danga.com> wrote:
> I've recently been using a supporting utility I called "git-cl":
> http://neugierig.org/software/git/?r=git-cl > (just one file, viewable here:http://neugierig.org/software/git/index.cgi?url=git-cl/tree/git-cl)
> This lets you associate git branches with a Rietveld issue, and then
> when it's time to commit, it squashes the branch into one svn commit
> and uses the description from the issue as the description of the
> commit. I was easily juggling three separate reviews in the same
> working copy without needing to remember any issue numbers.
Hi there,
Could someone point me to a webpage that explains how to setup code
reviews for git projects?
I am fairly familiar with both git and being a googler, fairly
familiar with code review, but I would like to learn about the hoops I
need to jump to get an external git project to use rietveld.
> I am fairly familiar with both git and being a googler, fairly
I am neither :-). I don't think you need to do anything special to use Rietveld. Just use upload.py with "-l" option (I am not sure if that is default now) and the rest should be automatically taken care of.
On Sun, Sep 7, 2008 at 12:11 PM, han...@xs4all.nl <hanw...@gmail.com> wrote: > Could someone point me to a webpage that explains how to setup code > reviews for git projects?
I don't think there is one. I'll submit a patch to the rietveld wiki documenting how it's done.
> I am fairly familiar with both git and being a googler, fairly > familiar with code review, but I would like to learn about the hoops I > need to jump to get an external git project to use rietveld.
Basically, you just need to upload reviews and you're done. No setup required, really.
Two options: 1) use the upload.py provided by rietveld (linked from the create issue page: http://codereview.appspot.com/new). Passing --help should explain the git-specific flags. Briefly, it's something like upload.py trunk # upload diff against "trunk" tree-ish That will print out the issue number you've been assigned. Then you can: upload.py -i 1234 trunk # upload a follow-up diff on issue 1234
2) use my git-cl, linked above, which integrates upload.py better within git. I've been using it for Chromium and have a couple happy users.
> On Sun, Sep 7, 2008 at 12:11 PM, han...@xs4all.nl <hanw...@gmail.com> wrote:
> > Could someone point me to a webpage that explains how to setup code
> > reviews for git projects?
> I don't think there is one. I'll submit a patch to the rietveld wiki
> documenting how it's done.
> > I am fairly familiar with both git and being a googler, fairly
> > familiar with code review, but I would like to learn about the hoops I
> > need to jump to get an external git project to use rietveld.
> Basically, you just need to upload reviews and you're done. No setup
> required, really.
> Two options:
> 1) use the upload.py provided by rietveld (linked from the create
> issue page:http://codereview.appspot.com/new). Passing --help should
> explain the git-specific flags. Briefly, it's something like
> upload.py trunk # upload diff against "trunk" tree-ish
> That will print out the issue number you've been assigned.
> Then you can:
> upload.py -i 1234 trunk # upload a follow-up diff on issue 1234
> 2) use my git-cl, linked above, which integrates upload.py better
> within git. I've been using it for Chromium and have a couple happy
> users.
This was the right one, but it takes an optional argument of what to diff against. So if this is a git clone, it'd be: git cl upload origin/master
The error message is from it trying to guess what to diff against -- right now I have code in there to try to diff against a git-svn trunk.
Better UI suggestions are welcome! Perhaps it should try origin/master if available? Maybe it should remember what you uploaded the first time and use that in the future?
> This was the right one, but it takes an optional argument of what to
> diff against.
> So if this is a git clone, it'd be:
> git cl upload origin/master
I think I tried that, but then it goes
Are you sure to continue?(y/N) y
Upload server: codereview.appspot.com (change with -s/--server)
Message describing this patch set:
suggesting I'm creating a new issue.
> The error message is from it trying to guess what to diff against --
> right now I have code in there to try to diff against a git-svn trunk.
It would be nice if the git-svn detection were automatic. If there is
no git-svn, it should probably look at the config
On Wed, Sep 10, 2008 at 7:56 AM, han...@xs4all.nl <hanw...@gmail.com> wrote: > On 10 sep, 00:44, "Evan Martin" <mart...@danga.com> wrote:
>> Better UI suggestions are welcome! Perhaps it should try
> * Some other ideas: init the description from git-log from..HEAD.
Yeah! I've wanted this as well.
> * It asks for mail addresses; it's unclear which addresses (is it for > the google login, the reviewer, the mailing list).
Rietveld uploader. I can try to clarify.
> * CC-s should probably be set once per repository
They should be -- could you elaborate? "git cl config" asks for a default CC.
> * Can we skip the 'uncommitted files?' question? I know what I am > doing.
Other have asked me this as well. It's again from the Rietveld uploader. I could have it internally set the flag saying "don't ask me about this". I have two minds on this: - on one hand, behavior should be consistent across VCSes - on the other, it's already different (you're not using svn, after all) and it's more in the git style to silently act.
