On Aug 6, 2014, at 10:11 PM, Nico Williams <n...@cryptonector.com> 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
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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html