Thanks Jeffrey

... I'll have another look at cherry-picking.  Last I looked, it
wasn't quite the bees-knees.  Don't get me wrong, I think GIT is a
great tool.  Like every tool, "not everything is a nail".  Therein
lies the rub *lol*  Just for establishing my credibility; Git might be
something like my 15th source/version control package.

I don't have answers to some of those propositions -- Each project
demands its own //stuff// ... Philosophically I accept that ends don't
justify the means.  I tend to FEEL quite strongly these days (as a
largely kinaesthetic person) that the process should serve "decent"
END-s.  Or in a TQM / SixSigma frame: "agreed Ends".

I have a pretty good handle on the 'best bits' as well as the 'missing
bits' from those 15 experiences -- I ignored the big bad corporate #16
a former employer kept telling me "was better" than JADE for version-
ed objects.  And, ...

That is the main reason I prefer Git -- you can't 'version
objects' (in any pragmatic form, that I've found).  I realise that may
sound deluded.  That's OK too.

You have good tips Jeffrey and I'm letting go of my un-git sinful ways
until needs must (as they always do).


On Mar 4, 11:58 am, Jeffrey <> wrote:
> Unfortunately I don't have time for a full reply right now, but
> essentially everything I said about actually implementing auto-merging
> applies to implementing auto-cherry-picking.  (Cherry-picking means
> taking a commit from one place, and applying the same patch somewhere

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to