[Top][All Lists]

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

Re: Pushing patches to staging

From: David Kastrup
Subject: Re: Pushing patches to staging
Date: Fri, 18 Nov 2011 18:22:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]