On Aug 6, 2014, at 10:11 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > Nah. Sun managed this for decades without a hitch, and for products > much larger than GCC. See above. Ok. Ah, ok, perfect. I see how that method of working would cure the cherry-pick and merge don’t work problem mentioned at the top of the thread. > Do some experiments based on the above hardcopy. If that doesn't > convince you that it works, oh well, I'll have given it a good try. Thank you for taking the time to diagram that as it appears to violate everyones how to use git guide. I see the workflow does an onto, which was the ‘fix’ people talked about on stack overflow, and I see just how things would work. If the old master branches are deleted and gc is run, then all the old references go away, and then the refs from email and bugzilla then don’t work. Did you guys ever remove them and then prune (or gc)? Now, the biggest issue, if that is recognized as `fixing’ the cherry-pick problem, then certainly the problem is understood to be a problem. If one recognized it as a problem, then one can envision cherry-pick and merge working together so that the problem doesn’t need fixing in the first place. And, if it doesn’t need fixing, then the cost of the solution isn’t needed either. The biggest problem with git, is that two features don’t work nicely together when they could; in this case, cherry-pick and merge). Because they don’t, it makes it hard for people to predict what will happen when they use it. This makes it more expensive to use and less suitable than a system that is more predictable. You improve git, by fixing the problem and making the features work nicely together and making it predicable. I still favor fixing the underlying problem with cherry-pick and merge not working. :-) That said, I see how to work around the bug with rebase, if I need to. I wish the top google hit were your guide and I wish I never saw all the other pages… I see now your position, and I see why all the guides are wrong, if you know just how to use rebase. I wish the git documentation were improved to say as the first sentence under cherry-pick, this feature sucks and doesn’t really work well, it can cause excess merge conflicts. rebase can be used to work around the bugs in cherry-pick for now. And under rebase, instead of saying what it said now, that how one can can trivially and effortlessly use git, instead of saying, Do not rebase commits that you have pushed to a public repository which I now see is wrong.-- 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