Re: Creating new remote branch in git?

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.

Should this process get documented at
http://wiki.postgresql.org/wiki/Committing_with_Git ?
Right at the moment that only explains how to set up a local
copy of an already-existing branch.

regards, tom lane

On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
> On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)freedomcircle(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joe Abbate <jma(at)freedomcircle(dot)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(at)hagander(dot)net> wrote:
> On Fri, Jun 10, 2011 at 06:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Joe Abbate <jma(at)freedomcircle(dot)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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

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

> Joe Abbate <jma(at)freedomcircle(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Uh, I think someone needs to add this to our wiki:

I did.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)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.

This is ironclad evidence that you followed the directions out of
order, but yes, running that for every branch will fix it.

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

Robert Haas wrote:
> On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)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.
>
> This is ironclad evidence that you followed the directions out of
> order, but yes, running that for every branch will fix it.

I found the cause. When I added 'github' to ~/.gitconfig a few months
ago, I copied this line from .git/config:

fetch = +refs/heads/*:refs/remotes/origin/*

If this line is in ~/.gitconfig for both 'origin' and 'github', git
cannot create .git/config entries.

Attached is my corrected ~/.gitconfig file. I now use only the 'url'
branch entries, which is all that is needed.

Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On 06/13/2011 02:26 PM, Bruce Momjian wrote:
> I found the cause. When I added 'github' to ~/.gitconfig a few months
> ago, I copied this line from .git/config:
>
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> If this line is in ~/.gitconfig for both 'origin' and 'github', git
> cannot create .git/config entries.
>
> Attached is my corrected ~/.gitconfig file. I now use only the 'url'
> branch entries, which is all that is needed.
>
[...]
> [remote "origin"]
> url = ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
> # Do not add the next line or .git/config is not updated.
> # fetch = +refs/heads/*:refs/remotes/origin/*
> [remote "github"]
> url = git(at)github(dot)com:bmomjian/postgres.git

Is putting remotes in your ~/.gitconfig good practice? I certainly
don't have any in mine.

The one for "origin" seems a particularly bad idea to me, although I
don't claim that my git-fu is of the highest.

> pager = "less -x4 -E"

I experimented with this setting quite a bit before getting it the way I
wanted. You might find this works better:

pager = less -+$LESS -FRSX

cheers

andrew

Andrew Dunstan wrote:
>
>
> On 06/13/2011 02:26 PM, Bruce Momjian wrote:
> > I found the cause. When I added 'github' to ~/.gitconfig a few months
> > ago, I copied this line from .git/config:
> >
> > fetch = +refs/heads/*:refs/remotes/origin/*
> >
> > If this line is in ~/.gitconfig for both 'origin' and 'github', git
> > cannot create .git/config entries.
> >
> > Attached is my corrected ~/.gitconfig file. I now use only the 'url'
> > branch entries, which is all that is needed.
> >
> [...]
> > [remote "origin"]
> > url = ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
> > # Do not add the next line or .git/config is not updated.
> > # fetch = +refs/heads/*:refs/remotes/origin/*
> > [remote "github"]
> > url = git(at)github(dot)com:bmomjian/postgres.git
>
>
> Is putting remotes in your ~/.gitconfig good practice? I certainly
> don't have any in mine.

Putting 'github' in there allows me to push/pull from github branches
without having to specify the github URL.

> The one for "origin" seems a particularly bad idea to me, although I
> don't claim that my git-fu is of the highest.

Yeah, it isn't necessary, but it does allow me to do:

git clone origin

again without having to specify the URL.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On 06/13/2011 06:38 PM, Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>> On 06/13/2011 02:26 PM, Bruce Momjian wrote:
>>> I found the cause. When I added 'github' to ~/.gitconfig a few months
>>> ago, I copied this line from .git/config:
>>>
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>
>>> If this line is in ~/.gitconfig for both 'origin' and 'github', git
>>> cannot create .git/config entries.
>>>
>>> Attached is my corrected ~/.gitconfig file. I now use only the 'url'
>>> branch entries, which is all that is needed.
>>>
>> [...]
>>> [remote "origin"]
>>> url = ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
>>> # Do not add the next line or .git/config is not updated.
>>> # fetch = +refs/heads/*:refs/remotes/origin/*
>>> [remote "github"]
>>> url = git(at)github(dot)com:bmomjian/postgres.git
>>
>> Is putting remotes in your ~/.gitconfig good practice? I certainly
>> don't have any in mine.
> Putting 'github' in there allows me to push/pull from github branches
> without having to specify the github URL.
>
>> The one for "origin" seems a particularly bad idea to me, although I
>> don't claim that my git-fu is of the highest.
> Yeah, it isn't necessary, but it does allow me to do:
>
> git clone origin
>
> again without having to specify the URL.

Well, TIMTOWTDI, but I suspect you'd be much better off using git
aliases for both these purposes. Then you would not have got yourself
into the trouble that gave rise to this conversation.

cheers

andrew

Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
> Andrew Dunstan wrote:

> > Is putting remotes in your ~/.gitconfig good practice? I certainly
> > don't have any in mine.
>
> Putting 'github' in there allows me to push/pull from github branches
> without having to specify the github URL.

I think his point is that they are more properly specified in each
repo's .git/config file, not the global $HOME/.gitconfig. If you were
to check out some other, unrelated project, you could end up pushing
unrelated branches to PG's repo ... Not sure if this is really
possible, but it certainly seems scary to do things that way.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
> > Andrew Dunstan wrote:
>
> > > Is putting remotes in your ~/.gitconfig good practice? I certainly
> > > don't have any in mine.
> >
> > Putting 'github' in there allows me to push/pull from github branches
> > without having to specify the github URL.
>
> I think his point is that they are more properly specified in each
> repo's .git/config file, not the global $HOME/.gitconfig. If you were
> to check out some other, unrelated project, you could end up pushing
> unrelated branches to PG's repo ... Not sure if this is really
> possible, but it certainly seems scary to do things that way.

I understand now --- that it is risky to create an "origin" branch in
~/.gitconfig. I am now using an alias:

[alias]
pgclone = clone ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git

I assume the 'github' branch in ~/.gitconfig is fine.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Alvaro Herrera wrote:
>> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
>> > Andrew Dunstan wrote:
>>
>> > > Is putting remotes in your ~/.gitconfig  good practice? I certainly
>> > > don't have any in mine.
>> >
>> > Putting 'github' in there allows me to push/pull from github branches
>> > without having to specify the github URL.
>>
>> I think his point is that they are more properly specified in each
>> repo's .git/config file, not the global $HOME/.gitconfig.  If you were
>> to check out some other, unrelated project, you could end up pushing
>> unrelated branches to PG's repo ...  Not sure if this is really
>> possible, but it certainly seems scary to do things that way.
>
> I understand now --- that it is risky to create an "origin" branch in
> ~/.gitconfig.  I am now using an alias:
>
>        [alias]
>                pgclone = clone ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
>
> I assume the 'github' branch in ~/.gitconfig is fine.

That, too, would better off inside $REPO/.git/config, although it's
certainly less risky than the other one. It doesn't make much sense
to have an upstream that applies across every repository you have
checked out.

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

Robert Haas wrote:
> On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Alvaro Herrera wrote:
> >> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
> >> > Andrew Dunstan wrote:
> >>
> >> > > Is putting remotes in your ~/.gitconfig ?good practice? I certainly
> >> > > don't have any in mine.
> >> >
> >> > Putting 'github' in there allows me to push/pull from github branches
> >> > without having to specify the github URL.
> >>
> >> I think his point is that they are more properly specified in each
> >> repo's .git/config file, not the global $HOME/.gitconfig. ?If you were
> >> to check out some other, unrelated project, you could end up pushing
> >> unrelated branches to PG's repo ... ?Not sure if this is really
> >> possible, but it certainly seems scary to do things that way.
> >
> > I understand now --- that it is risky to create an "origin" branch in
> > ~/.gitconfig. ?I am now using an alias:
> >
> > ? ? ? ?[alias]
> > ? ? ? ? ? ? ? ?pgclone = clone ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
> >
> > I assume the 'github' branch in ~/.gitconfig is fine.
>
> That, too, would better off inside $REPO/.git/config, although it's
> certainly less risky than the other one. It doesn't make much sense
> to have an upstream that applies across every repository you have
> checked out.

Wouldn't I conceivably use github with a variety of projects? I try to
use ~/.gitconfig so I don't have to redo a lot of stuff when I reinstall
my PG git tree.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Tue, Jun 14, 2011 at 14:40, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > Alvaro Herrera wrote:
>> >> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
>> >> > Andrew Dunstan wrote:
>> >>
>> >> > > Is putting remotes in your ~/.gitconfig ?good practice? I certainly
>> >> > > don't have any in mine.
>> >> >
>> >> > Putting 'github' in there allows me to push/pull from github branches
>> >> > without having to specify the github URL.
>> >>
>> >> I think his point is that they are more properly specified in each
>> >> repo's .git/config file, not the global $HOME/.gitconfig. ?If you were
>> >> to check out some other, unrelated project, you could end up pushing
>> >> unrelated branches to PG's repo ... ?Not sure if this is really
>> >> possible, but it certainly seems scary to do things that way.
>> >
>> > I understand now --- that it is risky to create an "origin" branch in
>> > ~/.gitconfig. ?I am now using an alias:
>> >
>> > ? ? ? ?[alias]
>> > ? ? ? ? ? ? ? ?pgclone = clone ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
>> >
>> > I assume the 'github' branch in ~/.gitconfig is fine.
>>
>> That, too, would better off inside $REPO/.git/config, although it's
>> certainly less risky than the other one.  It doesn't make much sense
>> to have an upstream that applies across every repository you have
>> checked out.
>
> Wouldn't I conceivably use github with a variety of projects?  I try to
> use ~/.gitconfig so I don't have to redo a lot of stuff when I reinstall
> my PG git tree.

Yes, but your reference goes to a specific repository at github
(bmomjian/postgres). Which wouldn't be correct for any other
project...

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

Magnus Hagander wrote:
> >> > I understand now --- that it is risky to create an "origin" branch in
> >> > ~/.gitconfig. ?I am now using an alias:
> >> >
> >> > ? ? ? ?[alias]
> >> > ? ? ? ? ? ? ? ?pgclone = clone ssh://git(at)gitmaster(dot)postgresql(dot)org/postgresql.git
> >> >
> >> > I assume the 'github' branch in ~/.gitconfig is fine.
> >>
> >> That, too, would better off inside $REPO/.git/config, although it's
> >> certainly less risky than the other one. ?It doesn't make much sense
> >> to have an upstream that applies across every repository you have
> >> checked out.
> >
> > Wouldn't I conceivably use github with a variety of projects? ?I try to
> > use ~/.gitconfig so I don't have to redo a lot of stuff when I reinstall
> > my PG git tree.
>
> Yes, but your reference goes to a specific repository at github
> (bmomjian/postgres). Which wouldn't be correct for any other
> project...

Ah, I see your point. Thanks. I renamed it 'pggithub'. I think I need
to read Pro Git (http://progit.org/book/), though I am not sure that
would have helped me in this exact case.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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