Thread (29 messages) flat view 29 messages, 9 authors, 2016-06-15

Re: cherry picking and merge

From: "Keller, Jacob E" <jacob.e.keller@intel.com>
Date: 2016-06-15 23:02:19

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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help