Re: cherry picking and merge

From: Keller, Jacob E <jacob.e.keller@intel.com>
Date: Aug 21, 2014, 17:58 UTC
Message-ID: <1408643887.20771.8.camel@jekeller-desk1.amr.corp.intel.com>
In-Reply-To: <1408642561.20771.7.camel@jekeller-desk1.amr.corp.intel.com>

On Thu, 2014-08-21 at 17:36 +0000, Keller, Jacob E wrote:

Show 23 quoted lines

> On Fri, 2014-08-01 at 09:56 -0700, Mike Stump wrote:
> > Since everything I do goes up and down into repositories and I don’t want my friends and family to scorn me, rebase isn’t the command I want to use.
> 
> You completely mis-understand what "published" means. Published history
> is history from which other people can pull right now.
> 
> That means it has to be in a publicly addressable repository (ie: just
> like the remote that you are pulling from as upstream).
> 
> rebasing commits which are already in the upstream is bad. Rebasing
> commits which you have created locally is NOT bad. These commits would
> not be published until you do a push.
> 
> This is the fundamental issue with rebase, and it is infact easy to
> avoid mis-using, especially if you don't publish changes. The key is
> that a commit isn't published until it's something someone else can
> depend on.
> 
> Doing "git pull --rebase" essentially doesn't ever get you into trouble.
> 
> Regards,
> Jake
> �{.n�+�������+%��lzwm��b�맲��r��z��{ay�ʇڙ�,j��f���h���z��w������j:+v���w�j�m��������zZ+�����ݢj"��!�i

Pardon me. You can actually ignore this post. I read through more of the thread, and actually realize I completely misunderstood what your issue was, and why rebase might not work.

Regards, Jake