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

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