Re: cherry picking and merge
- From
Keller, Jacob E <jacob.e.keller@intel.com>
- Date
- Aug 21, 2014, 17:36 UTC
- Message-ID
- <1408642561.20771.7.camel@jekeller-desk1.amr.corp.intel.com>
- In-Reply-To
- <AC750A73-4FE9-4BCB-9A51-4DE28F2110A7@comcast.net>
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