> > Does this sound reasonable? > > It sounds very reasonable indeed Ah, cool, thanks for validating our approach. We have so far been slowly figuring it out and it has been nice. > but then I don't understand why you held off pushing the merge. Ah, yes, that is the trick, to get it out quickly. Usually it is not a problem, but in ~2-3 months of using git, it's happened on high-churn branches about 4-5 times (usually it is the next release candidate branch where people are actively making small bug fixes and one guy gets caught with a non-trivial merge in from stable). Not all that bad, really, other than it caused a few "wtf git" comments. Which is unfortunate as, while I enjoy git, the team as a whole is still learning. Seeing the DAGs, and understanding the patch/apply approach of the non-interactive rebase, it makes sense to me what git is doing. And so while I know to watch for it, I'm trying to find a more bullet proof approach. > That's beside the point though, as I firmly believe git should be more > helpful in this situation. If "git rebase -i -p" doesn't help you fix > the problems, I'll see what I can do to help. That's very cool, thanks. I'll start writing a test now. - Stephen -- 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
