[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rietveld workflow problems
From: |
Reinhold Kainhofer |
Subject: |
Re: Rietveld workflow problems |
Date: |
Wed, 21 Sep 2011 15:32:30 +0200 |
User-agent: |
KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; i686; ; ) |
Am Wednesday, 21. September 2011, 15:04:05 schrieb David Kastrup:
> Reinhold Kainhofer <address@hidden> writes:
> > Am Wednesday, 21. September 2011, 10:52:37 schrieb David Kastrup:
> >> Perhaps it would be nice if we found a way to play with "Gerrit",
> >> supposedly a git-based system similar to Rietveld.
> >
> > I looked at gerrit a while ago. If you want to take a look at it:
> > http://server.kainhofer.com:8088/
> >
> > Here is a quick summary:
> >
> > -) Each review is basically one commit in a branch on the gerrit server.
>
> Well, that's pretty much what we already have.
No. In gerrit you really need to clean up your patches before you submit them
for review. I typically have lots of small commits in a branch when I upload a
patch to rietveld. git-cl will simply take the diff to origin/master (i.e. all
patches in the branch combined into one large patch) and show the combined
diff. gerrit, on the other hand, will show each small patch as one review.
So, I would have to clean up my local branch before submitting for review
(i.e. rebase -i and squash and reorder the patches). That's a very fundamental
difference in the approach. Rietveld works on the diff level, gerrit on the
git commit level.
> If one can't link
> related reviews in a manner that you can, say, _pull_ a reviewed patch
> (which should automagically fetch any dependencies), I am not all that
> clear of what it actually gives us in addition.
You'll have to check that yourself. The gerrit review page for a patch gives
the pull URL, and it lists the dependencies. I would expect that it correctly
pulls also the dependencies.
> The basic advantage that I see is a separately maintained repository for
> reviews, meaning that review material does not clutter up the main
> repository permanently (once a commit has entered a repository, it is
> close to impossible to remove all traces of it again).
If you use a developer branch and remove that branch, there are no direct
references any more. IIUC, the next garbage collection run on the server will
clean those stale commits....
Of course, if you merge your developer branch into master, then the commits
are there in the history forever.
Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
- Rietveld workflow problems, David Kastrup, 2011/09/21
- Re: Rietveld workflow problems, address@hidden, 2011/09/21
- Re: Rietveld workflow problems, David Kastrup, 2011/09/21
- Re: Rietveld workflow problems, Reinhold Kainhofer, 2011/09/21
- Re: Rietveld workflow problems, David Kastrup, 2011/09/21
- Re: Rietveld workflow problems,
Reinhold Kainhofer <=
- Re: Rietveld workflow problems, Janek Warchoł, 2011/09/21
- Re: Rietveld workflow problems, David Kastrup, 2011/09/21
- Re: Rietveld workflow problems, Janek Warchoł, 2011/09/21
- Re: Rietveld workflow problems, Carl Sorensen, 2011/09/21
- Re: Rietveld workflow problems, Graham Percival, 2011/09/21
- Re: Rietveld workflow problems, Janek Warchoł, 2011/09/22
- Re: Rietveld workflow problems, Carl Sorensen, 2011/09/22
Re: Rietveld workflow problems, Peekay Ex, 2011/09/21