Обсуждение: 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@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:
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.
Joe Abbate <jma@freedomcircle.com> writes:Yes, I was reading exactly that before posting. It talks about pushing
> 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
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
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_Githttp://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.2Checking out files: 100% (3851/3851), done. $ cd 8.2 $ git checkout -b REL8_2_STABLE origin/REL8_2_STABLEChecking out files: 100% (3908/3908), done.error: Not tracking: ambiguousinformation for ref refs/remotes/origin/REL8_2_STABLESwitched to a new branch 'REL8_2_STABLE' $ git pullYou asked me to pull without telling me which branch youwant to merge with, and 'branch.REL8_2_STABLE.merge' inyourconfiguration file does not tell me, either. Pleasespecify which branch you want to use on the command line andtryagain (e.g. 'git pull <repository> <refspec>').See git-pull(1) for details.If you often merge with the same branch,you may want touse 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 pullAlready 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 = originmerge = refs/heads/REL9_1_STABLErebase = 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. + [user] name = Bruce Momjian email = bruce@momjian.us [core] excludesfile = "/u/postgres/.gitignore" editor = "emastd" pager = "less -x4 -E" [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://git@gitmaster.postgresql.org/postgresql.git [remote "github"] fetch = +refs/heads/*:refs/remotes/origin/* url = git@github.com:bmomjian/postgres.git [diff] external = git-external-diff [branch] autosetuprebase = always [branch "master"] rebase = true [gc] auto = 0 [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://git@gitmaster.postgresql.org/postgresql.git [branch "master"] remote = origin merge = refs/heads/master rebase = true
On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian <bruce@momjian.us> wrote: > 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. 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@momjian.us> wrote: > > 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. > > 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + [user] name = Bruce Momjian email = bruce@momjian.us [core] excludesfile = "/u/postgres/.gitignore" editor = "emastd" pager = "less -x4 -E" [diff] external = git-external-diff [remote "origin"] url = ssh://git@gitmaster.postgresql.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@github.com:bmomjian/postgres.git [branch] autosetuprebase = always rebase = true [gc] auto = 0
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@gitmaster.postgresql.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@github.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@gitmaster.postgresql.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@github.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@momjian.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@gitmaster.postgresql.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@github.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@commandprompt.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@gitmaster.postgresql.org/postgresql.git I assume the 'github' branch in ~/.gitconfig is fine. -- Bruce Momjian <bruce@momjian.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@momjian.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@gitmaster.postgresql.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@momjian.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@gitmaster.postgresql.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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@gitmaster.postgresql.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@momjian.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@momjian.us> wrote: > Robert Haas wrote: >> On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian <bruce@momjian.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@gitmaster.postgresql.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/