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

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, Johannes Schindelin wrote:
> 
> > 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.

Right.  But a rebase "merge strategy" doesn't work for those people,
because it's not possible in general for their git to know exactly which
part is their work (which needs to be rebased) and which is your old
work (which should be discarded).  Manual inspection is required.

> And in this case, constant rebasing is a perfectly fine work flow to me. 

Again, if you have people basing work on top of yours, I think the best
option may really be to add a merge commit on top of each new version of
the series with first parent the new series and second parent the
previous history.

That way the history does have the information necessary to rebase their
work automatically.

--b.