Re: Pushing patches to staging

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

>> git fetch (to be sure you have the current version of staging)
>> git checkout origin/staging
>> ... commit your simple change ...
>> git push origin HEAD:staging
>>
>> This assumes that you have staging in the branches you fetch.  If that
>> is not the case, add an appropriate fetch line to the [remote "origin"]
>> section in your .git/config file.
>
> David,
>
> I updated my .config as you suggested, and followed the instructions
> above. My patch pushed successfully to staging, thanks.  Unless anyone
> screams, I'll add this to the CG.

Using origin/staging here (instead of staging) makes sure that you'll
always get the current upstream version of staging painlessly regardless
of how it has been changed or rebased or whatever.

It also means that you don't have a copy of the simple change accessible
in your repository if you don't keep it elsewhere.  So "... commit your
simple change ..." will commonly mean cherry-picking or merging from a
"proper" branch you are working on.

If somebody decides to clean out the upstream staging instead of merging
it to master, this might imply losing work (actually, git reflog will
likely give you a pointer to the commit id made in that manner on a
detached HEAD, but such commits are usually garbage-collected after a
few months and are then gone for good).

-- 
David Kastrup