On Tue, Jul 29, 2008 at 10:36:32AM +0100, Mike Ralphson wrote: > > I just didn't want history thrown away for two reasons: > > > > - historical interest; some of the commits had counterparts in devel > > that were done differently (because the two branches had diverged), > > but it might later be interesting to see how and why the stable > > changes were done (e.g., if a similar situation arose) > > > > - this project did not rebase, favoring the simplicity of "git pull" > > over clean history. > > > > Bear in mind that this project was not very big. I think devel had ~20 > > commits, and stable had about ~5. So it was easy to get such confidence. > > Is there any reason you couldn't have reverted the stable commits in > preparation for the merge from devel? No, there is no technical reason. I think that is a perfectly valid way of accomplishing the same goal (as is switching to the "kept" branch and using "-s ours"). It's just that we had a particular mental model, and the simplest way of translating that model into a git history graph was as I described. Again, I don't think this is a common problem, and I have certainly not been aching for "-s theirs". The question was whether such a thing might be useful, and I think it is, if only because it most directly matches how a user might be thinking of the problem; for other users, or other similar situations, one of the other methods might make more sense. To me, seeing a commit that joins two histories with a comment saying "these two branches are now becoming the same, but we don't care about what happened down this ancestry chain because of X" most directly models what happened (in my case). -Peff -- 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
