lilypond-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]