[Top][All Lists]

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

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

From: Carl Sorensen
Subject: Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Date: Mon, 16 Jan 2012 16:39:58 +0000
User-agent: Microsoft-MacOutlook/

On 1/16/12 9:26 AM, "Phil Holmes" <address@hidden> wrote:

>Before you start thinking about pushing a patch to staging, you
>need to ensure you have the correct local branches up to date.
>One time only, edit the .git/config file to look like this (there
>will be other lines and sections, don't touch these):
>[remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = ssh://
>@end example
>Now, each time you want to make a change and push to staging, do
>the following:
>git fetch # (to be sure you have the current version of staging)
>git checkout origin/staging
># ... make and commit your change ... e.g. with git am patchname
>git push origin HEAD:staging
>@end example
>Note that this does not work well for complex changes on other
>branches - if you're doing this you'll need to have better git
>understanding.  However, "make your change" could include applying
>a patch previously you've made.

This set of instructions works great if you are maintaining your work in
patches.  Getting the latest staging and then applying patches to it
before pushing will always work.

Of course if your patches are not based on staging, then they may not

The current instructions on working with branches in the cg are ideal for
working with  a staging that may be destroyed at any time.  I think that
they are sound, and can be effectively used by anybody.

Although Graham may not appreciate it, I think I may modify lilygit.tcl to
create an advanced mode that readily supports switching branches, posting
for review, and pushing to staging.



reply via email to

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