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 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to