On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> 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.
I don't follow.
Their work is always origin/master@{1}..HEAD after origin/master has
been updated through a fetch, and it needs to be rebased on
origin/master.
> > 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.
And my repo will then be full of clutter which no one upstream will ever
accept to merge. Can't do that.
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
