Re: cherry picking and merge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2014-08-21 at 17:36 +0000, Keller, Jacob E wrote:
> 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
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]