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-discus...@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
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.
HTH,
Raghu
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.
The README explains how it works:
http://neugierig.org/software/git/index.cgi?url=git-cl/tree/README
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 is now Rietveld's uploader's domain. Each patch you upload has
an associated message (e.g. "fixed whitespace mentioned in review
comments").
>
>> 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
>
> [branch "dbg"]
> remote = origin
> merge = refs/heads/master
>
> (ie. dbg is tracking origin/master)
Good idea!
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.
http://codereview.appspot.com/5066
> * It asks for mail addresses; it's unclear which addresses (is it for
> the google login, the reviewer, the mailing list).
http://codereview.appspot.com/5065
> * Can we skip the 'uncommitted files?' question? I know what I am
> doing.