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. - 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
