Creating new remote branch in git?

On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in git.  I suppose it's some variant of

git checkout master             # if not there already
git branch REL9_1_STABLE
git push origin REL9_1_STABLE

but it's not clear to me whether any options are needed to ensure that
the right branch tracking behavior gets set up.

That looks right, and yeah that won't setup that branch to track
upstream for you. However, it should work for anyone that gets that
branch as part of a fetch/pull. ( that is it will work like any other
remote branch )

Ive always found it easy enought to edit .git/config. If you add an
entry that looks like any of the other RELX_X_STABLE branches it
should work fine. Something along the lines of:
[branch "REL9_1_STABLE"]
remote = origin
merge = refs/heads/REL9_1_STABLE

Should this process get documented at
http://wiki.postgresql.org/wiki/Committing_with_Git

+1 [ Im curious if any git experts chime in with a cleaner way than
mucking with the config file. ]

Alex Hunsaker <badalex@gmail.com> writes:

On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in git. I suppose it's some variant of

git checkout master # if not there already
git branch REL9_1_STABLE
git push origin REL9_1_STABLE

but it's not clear to me whether any options are needed to ensure that
the right branch tracking behavior gets set up.

That looks right, and yeah that won't setup that branch to track
upstream for you. However, it should work for anyone that gets that
branch as part of a fetch/pull. ( that is it will work like any other
remote branch )

So creating the branch trashes my own repo? Surely there's a better
way.

regards, tom lane

On 06/10/2011 12:02 AM, Tom Lane wrote:

Alex Hunsaker <badalex@gmail.com> writes:

On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in git. I suppose it's some variant of

git checkout master # if not there already
git branch REL9_1_STABLE
git push origin REL9_1_STABLE

but it's not clear to me whether any options are needed to ensure that
the right branch tracking behavior gets set up.

That looks right, and yeah that won't setup that branch to track
upstream for you. However, it should work for anyone that gets that
branch as part of a fetch/pull. ( that is it will work like any other
remote branch )

So creating the branch trashes my own repo? Surely there's a better
way.

No, it doesn't trash anything. The branch is just an additional
"pointer" to 'master' (at that point in time). I recommend taking a
look at this:

http://progit.org/book/ch3-5.html

Joe

On Thu, Jun 9, 2011 at 22:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alex Hunsaker <badalex@gmail.com> writes:

On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in git.  I suppose it's some variant of

git checkout master             # if not there already
git branch REL9_1_STABLE
git push origin REL9_1_STABLE

but it's not clear to me whether any options are needed to ensure that
the right branch tracking behavior gets set up.

That looks right, and yeah that won't setup that branch to track
upstream for you. However, it should work for anyone that gets that
branch as part of a fetch/pull. ( that is it will work like any other
remote branch )

So creating the branch trashes my own repo?  Surely there's a better
way.

I dunno where you got trashes from. I must have worded that poorly. It
won't break anything, it just won't "track" origin/upstream.

It looks like if you push the remote branch first everything should work nicely:
git checkout master
git push origin origin:refs/heads/REL9_1_STABLE
git fetch # fetch the new branch
git checkout REL9_1_STABLE

Joe Abbate <jma@freedomcircle.com> writes:

No, it doesn't trash anything. The branch is just an additional
"pointer" to 'master' (at that point in time). I recommend taking a
look at this:

http://progit.org/book/ch3-5.html

Yes, I was reading exactly that before posting. It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch. What I want is to end up
with my local branch tracking the remote branch in the same way as if
I'd not been the branch creator. Preferably without having to do
anything as ugly as delete the branch, or re-clone, or manually hack
config files. This has got to be a use case that the git authors
have heard of before...

regards, tom lane

On Fri, Jun 10, 2011 at 06:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joe Abbate <jma@freedomcircle.com> writes:

No, it doesn't trash anything.  The branch is just an additional
"pointer" to 'master' (at that point in time).  I recommend taking a
look at this:

http://progit.org/book/ch3-5.html

Yes, I was reading exactly that before posting.  It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch.  What I want is to end up
with my local branch tracking the remote branch in the same way as if
I'd not been the branch creator.  Preferably without having to do
anything as ugly as delete the branch, or re-clone, or manually hack
config files.  This has got to be a use case that the git authors
have heard of before...

I think you need the -u parameter to "git push". (Haven't tested, though)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 06/10/2011 12:40 AM, Tom Lane wrote:

Yes, I was reading exactly that before posting. It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch. What I want is to end up
with my local branch tracking the remote branch in the same way as if
I'd not been the branch creator. Preferably without having to do
anything as ugly as delete the branch, or re-clone, or manually hack
config files. This has got to be a use case that the git authors
have heard of before...

You don't have to do any of those ugly steps. By creating the branch,
you see it in your own environment. By pushing it to origin, the remote
branch is created and others can see it. You can checkout master after
the push and continue working.

Joe

On Fri, Jun 10, 2011 at 12:43 AM, Magnus Hagander <magnus@hagander.net> wrote:

On Fri, Jun 10, 2011 at 06:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joe Abbate <jma@freedomcircle.com> writes:

No, it doesn't trash anything.  The branch is just an additional
"pointer" to 'master' (at that point in time).  I recommend taking a
look at this:

http://progit.org/book/ch3-5.html

Yes, I was reading exactly that before posting.  It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch.  What I want is to end up
with my local branch tracking the remote branch in the same way as if
I'd not been the branch creator.  Preferably without having to do
anything as ugly as delete the branch, or re-clone, or manually hack
config files.  This has got to be a use case that the git authors
have heard of before...

I think you need the -u parameter to "git push". (Haven't tested, though)

Yeah. I *think* the right incantation might be:

git branch REL9_1_STABLE
git push -u origin REL9_1_STABLE

Actually, creating the branch is trivial. I do that all the time.
What I'm less sure about is how you get the push configuration set up
right. But I think the above might do it. I'd read .git/config
afterward just to see if it looks sane.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 06/10/2011 12:19 AM, Alex Hunsaker wrote:

It looks like if you push the remote branch first everything should work nicely:
git checkout master
git push origin origin:refs/heads/REL9_1_STABLE
git fetch # fetch the new branch
git checkout REL9_1_STABLE

This is basically the state of the art right now for the most frequently
deployed versions of git. I don't think checking out master first is
necessary though.

Potentially useful automation/trivia for alternate approaches includes:

1) Write a little script to do this messy chore, so you don't have to
remember this weird "create a new branch using a full refspec" syntax.
There is an example named git-create-branch along with a short tutorial
on this subject at
http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/

2) Use git_remote_branch https://github.com/webmat/git_remote_branch
which is the swiss army knife of remote branch hackery automation.

3) Rather than manually hack the config files, use "git config" to do
it. Not sure if this is completely workable, but something like this
might connect the newly created branch to your local one after pushing
it out, without actually opening the config with an editor:

git config branch.REL9_1_STABLE.remote origin
git config branch.REL9_1_STABLE.merge refs/heads/REL9_1_STABLE

4) Use a system with git>=1.7.0, which adds:

git branch --set-upstream REL9_1_STABLE origin/REL9_1_STABLE

--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

On Fri, Jun 10, 2011 at 12:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joe Abbate <jma@freedomcircle.com> writes:

No, it doesn't trash anything. The branch is just an additional
"pointer" to 'master' (at that point in time). I recommend taking a
look at this:

http://progit.org/book/ch3-5.html

Yes, I was reading exactly that before posting. It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch. What I want is to end up
with my local branch tracking the remote branch in the same way as if
I'd not been the branch creator. Preferably without having to do
anything as ugly as delete the branch, or re-clone, or manually hack
config files. This has got to be a use case that the git authors
have heard of before...

I have done this quite a few times on GitHub and has never barfed on me in
any surprising way:

# make sure local master is up-to-date with origin/master, and then do
git checkout master
git checkout -b new_branch
git push origin new_branch

From here on I work as if that new_branch was handed to me from the origin.
I believe this also takes care of setting up the .git/config file properly.

Just in case it is needed: to delete a branch on remote, just do

git push origin :new_branch

It will keep your local branch (if you have it), but will nuke the remote
branch.

Regards,

PS: Play a bit on GitHub
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

On Fri, Jun 10, 2011 at 00:53, Greg Smith <greg@2ndquadrant.com> wrote:

On 06/10/2011 12:19 AM, Alex Hunsaker wrote:

It looks like if you push the remote branch first everything should work
nicely:
git checkout master
git push origin origin:refs/heads/REL9_1_STABLE
git fetch # fetch the new branch
git checkout REL9_1_STABLE

This is basically the state of the art right now for the most frequently
deployed versions of git.  I don't think checking out master first is
necessary though.

I assume it will use the current HEAD as the branch point which is why
I checked out master :)

Potentially useful automation/trivia for alternate approaches includes:

1) Write a little script to do this messy chore, so you don't have to
remember this weird "create a new branch using a full refspec" syntax.
 There is an example named git-create-branch along with a short tutorial on
this subject at
http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/

2) Use git_remote_branch https://github.com/webmat/git_remote_branch which
is the swiss army knife of remote branch hackery automation.

3) Rather than manually hack the config files, use "git config" to do it.
 Not sure if this is completely workable, but something like this might
connect the newly created branch to your local one after pushing it out,
without actually opening the config with an editor:

git config branch.REL9_1_STABLE.remote origin
git config branch.REL9_1_STABLE.merge refs/heads/REL9_1_STABLE

4) Use a system with git>=1.7.0, which adds:

git branch --set-upstream REL9_1_STABLE origin/REL9_1_STABLE

But wait! there's more!

5) delete your local branch and recreate it after you push the branch out
git branch REL9_1_STABLE
git push origin REL9_1_STABLE
# -f is short hand, you could git branch -d REL9_1_STABLE and re-make it
git branch -f REL9_1_STABLE origin/REL9_1_STABLE

6) use push -u
....

Its git so there are probably another half dozen ways to do this...
What Im curious about is what is the 'proper' way? Or is that a
nonsensical question when talking about git :-P

On 06/10/2011 11:26 AM, Alex Hunsaker wrote:

On Fri, Jun 10, 2011 at 00:53, Greg Smith<greg@2ndquadrant.com> wrote:

4) Use a system with git>=1.7.0, which adds:

git branch --set-upstream REL9_1_STABLE origin/REL9_1_STABLE

But wait! there's more!

5) delete your local branch and recreate it after you push the branch out

That's what I've done in the past, and it works, but I suspect #4 is the
best answer.

cheers

andrew

Greg Smith wrote:

On 06/10/2011 12:19 AM, Alex Hunsaker wrote:

It looks like if you push the remote branch first everything should work nicely:
git checkout master
git push origin origin:refs/heads/REL9_1_STABLE
git fetch # fetch the new branch
git checkout REL9_1_STABLE

This is basically the state of the art right now for the most frequently
deployed versions of git. I don't think checking out master first is
necessary though.

Potentially useful automation/trivia for alternate approaches includes:

1) Write a little script to do this messy chore, so you don't have to
remember this weird "create a new branch using a full refspec" syntax.
There is an example named git-create-branch along with a short tutorial
on this subject at
http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/

2) Use git_remote_branch https://github.com/webmat/git_remote_branch
which is the swiss army knife of remote branch hackery automation.

3) Rather than manually hack the config files, use "git config" to do
it. Not sure if this is completely workable, but something like this
might connect the newly created branch to your local one after pushing
it out, without actually opening the config with an editor:

git config branch.REL9_1_STABLE.remote origin
git config branch.REL9_1_STABLE.merge refs/heads/REL9_1_STABLE

4) Use a system with git>=1.7.0, which adds:

git branch --set-upstream REL9_1_STABLE origin/REL9_1_STABLE

Uh, I think someone needs to add this to our wiki:

http://wiki.postgresql.org/wiki/Working_with_Git
http://wiki.postgresql.org/wiki/Committing_with_Git

I needed this when using git-new-workdir so at least it is needed there;
I am unclear how wide this is needed so I cannot add it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce@momjian.us> writes:

Uh, I think someone needs to add this to our wiki:

I did.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Uh, I think someone needs to add this to our wiki:

I did.

I saw your commit that mentioned how to create a new branch. My problem
was with using workdir:

http://wiki.postgresql.org/wiki/Committing_with_Git#Committing_Using_a_Single_Clone_and_multiple_workdirs

I had to use:

pggit config branch.REL9_1_STABLE.remote origin
pggit config branch.REL9_1_STABLE.merge refs/heads/REL9_1_STABLE

or I get errors like this during 'pull':

$ git-new-workdir postgresql/.git/ 8.2
Checking out files: 100% (3851/3851), done.

$ cd 8.2

$ git checkout -b REL8_2_STABLE origin/REL8_2_STABLE
Checking out files: 100% (3908/3908), done.
error: Not tracking: ambiguous information for ref refs/remotes/origin/REL8_2_STABLE
Switched to a new branch 'REL8_2_STABLE'

$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.REL8_2_STABLE.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:

[branch "REL8_2_STABLE"]
remote = <nickname>
merge = <remote-ref>

[remote "<nickname>"]
url = <url>
fetch = <refspec>

See git-config(1) for details.

(Is that "error: Not tracking: ambiguous information" error harmless?)

Once I execute this:

$ git config branch.REL8_2_STABLE.remote origin
$ git config branch.REL8_2_STABLE.merge refs/heads/REL8_2_STABLE

'pull' then works:

$ git pull
Already up-to-date.

So my point is I don't think we document the need to either update
.git/config or run those commands. The pull error message suggests
updating .git/config, but ideally we should tell users how to set this
up.

Editing the config file was mentioned in this email thread:

http://archives.postgresql.org/pgsql-hackers/2011-06/msg00860.php

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce@momjian.us> writes:

I saw your commit that mentioned how to create a new branch. My problem
was with using workdir:

There seems to be something rather broken with your setup, because I
don't find it necessary to do any of that stuff; the recipe in the wiki
page works fine for me. What git version are you using? Maybe a buggy
version of git-new-workdir?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I saw your commit that mentioned how to create a new branch. My problem
was with using workdir:

There seems to be something rather broken with your setup, because I
don't find it necessary to do any of that stuff; the recipe in the wiki
page works fine for me. What git version are you using? Maybe a buggy
version of git-new-workdir?

I am running git version 1.7.3. What is odd is that I didn't need it
when I originally set this up, but now I do, or maybe I manually updated
.git/config last time.

Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
for you or did you create it manually? That is what those 'git config'
commands do.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce@momjian.us> writes:

Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
for you or did you create it manually?

git created them for me. I did no config hacking whatever, but now
I have:

[branch "REL9_1_STABLE"]
remote = origin
merge = refs/heads/REL9_1_STABLE
rebase = true

which exactly parallels the pre-existing entries for the other branches.

One point that might affect this is that in ~/.gitconfig I have

[branch]
autosetuprebase = always

which is as per the setup recommendations on the wiki page.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
for you or did you create it manually?

git created them for me. I did no config hacking whatever, but now
I have:

[branch "REL9_1_STABLE"]
remote = origin
merge = refs/heads/REL9_1_STABLE
rebase = true

which exactly parallels the pre-existing entries for the other branches.

One point that might affect this is that in ~/.gitconfig I have

[branch]
autosetuprebase = always

which is as per the setup recommendations on the wiki page.

I have the same in my ~/.gitconfig:

[branch]
autosetuprebase = always

I am attaching my ~/.gitconfig.

Do I need to run this in every branch?

git config branch.master.rebase true

Right now our wiki only says to run it in the master branch. I am
attaching my postgresql/.git/config file too.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +