Re: What's cooking in git.git (topics)

From: Nicolas Pitre <nico@cam.org>
Date: Nov 27, 2007, 14:29 UTC
Message-ID: <alpine.LFD.0.99999.0711270917580.9605@xanadu.home>
In-Reply-To: <Pine.LNX.4.64.0711271109130.27959@racer.site>

On Tue, 27 Nov 2007, Johannes Schindelin wrote:

Show 12 quoted lines

> Hi,
> 
> On Tue, 27 Nov 2007, しらいしななこ wrote:
> 
> > Was it coded poorly, buggy or were there some other issues?
> 
> It is very well possible that it was coded poorly ;-)
> 
> The main reason, I believe, was that some old-timers who know the 
> implications said that it would encourage a wrong workflow.  One thing 
> that could go possibly wrong, for example, is to rebase commits that you 
> already published.

Being much more involved in the maintenance of a published Git tree lately, I must disagree with the "wrong workflow" statement. Until the stuff I maintain is finally merged upstream, I have to constantly amend/replace/fold/split random commits in my repo to follow the review cycles involved. yet I have to publish the result to let others base their work on top of my latest tree. A fetch+rebase is the only option for those following my tree, and I made it clear that they have to rebase after a fetch because I constantly rebase commits that I have already published myself.

And in this case, constant rebasing is a perfectly fine work flow to me. Otherwise I might just use Git as a glorified tarball downloader and use quilt on top, but this is somehow not as appealing.

Nicolas