{"thread":{"id":"62706","subject":"connecting the local main branch to the remote origin/main without pushing","startedAt":"2024-12-28T15:50:13Z","lastAt":"2024-12-29T14:40:15Z","messageCount":10,"participants":["crstml@libero.it","rsbecker@nexbridge.com","Andreas Schwab","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"509682","messageId":"a69c4e2e-cbb0-c242-a34a-8997a84fefb7@libero.it","threadId":"62706","inReplyTo":null,"subject":"connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"crstml@libero.it","sentAt":"2024-12-28T15:47:27Z","receivedAt":"2024-12-28T15:50:13Z","isPatch":false,"sender":{"key":"crstml@libero.it","avatar":null},"body":"Hello all\n\nI would like to put a set of files under version control and I\nhave some issues with the workflow. Let me explain:\n\nFirst I create the bare repository with the command:\n\n     git init --bare -b main ~/rps/project-x.git\n\nThen I can proceed in one of the following ways:\n\n\n---- Method 1 ----\n\n    By first cloning the remote repository locally and next\n    putting the files under version control. All running the\n    following commands:\n\n    1    cd ~/projects;\n    2    git clone ~/rps/project-x.git project-x\n    3    cp ~/my-existing-project-x-files/* project-x\n    4    cd project-x\n    5    git add .\n    6    git commit -m \"fc\"\n    7    git push origin\n    8    rm -rf ~/my-existing-project-x-files   # clean your home folder\n\n---- Method 2 ----\n\n    By putting the existing files under version control and next\n    adding the remote. Running the following commands:\n\n    1    cd ~/projects/project-x\n    2    git init -b main\n    3    git add .\n    4    git commit -m \"fc\"\n    5    git remote add origin ~/rps/project-x.git\n    6    git push --set-upstream origin main\n\n\nLet me discuss both these methods:\n\nMethod 1:\n\n   Everything works but the cp statement may be problematic. If\n   you have hidden files (starting with .) or if you want to\n   preserve the file permissions and owenership, the invokation\n   of the cp command is trickier.\n\n   After you copy the files all the next statements work well.\n   The main branch in the cloned repository is connected to the\n   upstream origin/main branch and \"git push\" will work.\n\n   There is one more small problem with this workflow: the\n   statement 8 is ugly.\n\n\n\nMethod 2\n\n   Everything is very clean (apparently). We don't have to think\n   to file permissions, hidden files, tricky cp invocations and\n   there is no need to clean your home folder at the end. We are\n   interested to put files under version control, so we focus only\n   the version control system.\n\n\n   The problem  with this workflow (from my point of view) is the\n   statement 6. This statement makes two things which is contrary\n   to the UNIX philosophy: programs that do one thing and do it well.\n\n       1) The command connects the local main branch to the\n          remote origin/main branch.\n\n       2) Pushes the files to the remote.\n\n   From my point of view instead of executing the statement 6 I would\n   like to execute the following two statements that I will number\n   here as 6.1 and 6.2:\n\n    6.1  # To connect the main branch to origin/main\n         #\n         git branch -u origin/main main\n\n    6.2  # To push to the remote.\n         #\n         git push origin\n\n    However, the statement 6.1 does not work. Git prints the following\n    message.\n\n    hint: If you are planning on basing your work on an upstream\n    hint: branch that already exists at the remote, you may need to\n    hint: run \"git fetch\" to retrieve it.\n    hint:\n    hint: If you are planning to push out a new local branch that\n    hint: will track its remote counterpart, you may want to use\n    hint: \"git push -u\" to set the upstream config as you push.\n    hint: Disable this message with \"git config advice.setUpstreamFailure false\"\n\n    The end solution it suggests to use with \"git push -u\" which\n    is the same as the statement on line 6 that I would like to\n    avoid.  I would add that by issuing a \"git fecth\" before 6.1\n    would not bring the remote branch origin/main in the local\n    repository.\n\n    The core of the problem is that the local branch main is not connected\n    to the origin/main branch.\n\nMy question is:\n      Is it possible when applying the method 2 to have (without pushing)\n      the local main branch connected to the remote origin/main branch as\n      in the case of method 1 which by cloning connects these branches.\n\nThank you\nCristian\n"},{"id":"509685","messageId":"027f01db5943$340b2c70$9c218550$@nexbridge.com","threadId":"62706","inReplyTo":"a69c4e2e-cbb0-c242-a34a-8997a84fefb7@libero.it","subject":"RE: connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-12-28T16:11:45Z","receivedAt":"2024-12-28T16:11:53Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 28, 2024 10:47 AM crstml@libero.it wrote:\n>I would like to put a set of files under version control and I have some issues with\n>the workflow. Let me explain:\n>\n>First I create the bare repository with the command:\n>\n>     git init --bare -b main ~/rps/project-x.git\n>\n>Then I can proceed in one of the following ways:\n>\n>\n>---- Method 1 ----\n>\n>    By first cloning the remote repository locally and next\n>    putting the files under version control. All running the\n>    following commands:\n>\n>    1    cd ~/projects;\n>    2    git clone ~/rps/project-x.git project-x\n>    3    cp ~/my-existing-project-x-files/* project-x\n>    4    cd project-x\n>    5    git add .\n>    6    git commit -m \"fc\"\n>    7    git push origin\n>    8    rm -rf ~/my-existing-project-x-files   # clean your home folder\n>\n>---- Method 2 ----\n>\n>    By putting the existing files under version control and next\n>    adding the remote. Running the following commands:\n>\n>    1    cd ~/projects/project-x\n>    2    git init -b main\n>    3    git add .\n>    4    git commit -m \"fc\"\n>    5    git remote add origin ~/rps/project-x.git\n>    6    git push --set-upstream origin main\n>\n>\n>Let me discuss both these methods:\n>\n>Method 1:\n>\n>   Everything works but the cp statement may be problematic. If\n>   you have hidden files (starting with .) or if you want to\n>   preserve the file permissions and owenership, the invokation\n>   of the cp command is trickier.\n>\n>   After you copy the files all the next statements work well.\n>   The main branch in the cloned repository is connected to the\n>   upstream origin/main branch and \"git push\" will work.\n>\n>   There is one more small problem with this workflow: the\n>   statement 8 is ugly.\n>\n>\n>\n>Method 2\n>\n>   Everything is very clean (apparently). We don't have to think\n>   to file permissions, hidden files, tricky cp invocations and\n>   there is no need to clean your home folder at the end. We are\n>   interested to put files under version control, so we focus only\n>   the version control system.\n>\n>\n>   The problem  with this workflow (from my point of view) is the\n>   statement 6. This statement makes two things which is contrary\n>   to the UNIX philosophy: programs that do one thing and do it well.\n>\n>       1) The command connects the local main branch to the\n>          remote origin/main branch.\n>\n>       2) Pushes the files to the remote.\n>\n>   From my point of view instead of executing the statement 6 I would\n>   like to execute the following two statements that I will number\n>   here as 6.1 and 6.2:\n>\n>    6.1  # To connect the main branch to origin/main\n>         #\n>         git branch -u origin/main main\n>\n>    6.2  # To push to the remote.\n>         #\n>         git push origin\n>\n>    However, the statement 6.1 does not work. Git prints the following\n>    message.\n>\n>    hint: If you are planning on basing your work on an upstream\n>    hint: branch that already exists at the remote, you may need to\n>    hint: run \"git fetch\" to retrieve it.\n>    hint:\n>    hint: If you are planning to push out a new local branch that\n>    hint: will track its remote counterpart, you may want to use\n>    hint: \"git push -u\" to set the upstream config as you push.\n>    hint: Disable this message with \"git config advice.setUpstreamFailure false\"\n>\n>    The end solution it suggests to use with \"git push -u\" which\n>    is the same as the statement on line 6 that I would like to\n>    avoid.  I would add that by issuing a \"git fecth\" before 6.1\n>    would not bring the remote branch origin/main in the local\n>    repository.\n>\n>    The core of the problem is that the local branch main is not connected\n>    to the origin/main branch.\n>\n>My question is:\n>      Is it possible when applying the method 2 to have (without pushing)\n>      the local main branch connected to the remote origin/main branch as\n>      in the case of method 1 which by cloning connects these branches.\n\nI think method 2 is failing for you because you do not have origin/main in your\nlocal repository. That requires a git fetch. Git fetch will not overwrite your\nworking area, but is needed so that tracking can occur with an existing\nremote branch.\n\nThe reason git push -u works is that the resolution of your branch tracking\ncan be worked out by git as part of the push, where the remote reference\nis known. Without that, the git branch -u does not work (no reference).\n\nSo do the git fetch as 5.9 in Method 2, then 6.1 should work, assuming origin/main\nexists in your remote. This downloads the clone history without modifying\nyour work area, so it should be fine.\n\n--Randall\n\n"},{"id":"509690","messageId":"87h66nk9uy.fsf@igel.home","threadId":"62706","inReplyTo":"a69c4e2e-cbb0-c242-a34a-8997a84fefb7@libero.it","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2024-12-28T17:15:01Z","receivedAt":"2024-12-28T17:15:10Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Dez 28 2024, crstml@libero.it wrote:\n\n> My question is:\n>      Is it possible when applying the method 2 to have (without pushing)\n>      the local main branch connected to the remote origin/main branch as\n>      in the case of method 1 which by cloning connects these branches.\n\nYou can establish the effect by setting two config entries:\n\n$ git config branch.main.remote origin\n$ git config branch.main.merge refs/heads/main\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"509692","messageId":"xmqqikr33esb.fsf@gitster.g","threadId":"62706","inReplyTo":"87h66nk9uy.fsf@igel.home","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-12-28T17:20:36Z","receivedAt":"2024-12-28T17:20:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab <schwab@linux-m68k.org> writes:\n\n> On Dez 28 2024, crstml@libero.it wrote:\n>\n>> My question is:\n>>      Is it possible when applying the method 2 to have (without pushing)\n>>      the local main branch connected to the remote origin/main branch as\n>>      in the case of method 1 which by cloning connects these branches.\n>\n> You can establish the effect by setting two config entries:\n>\n> $ git config branch.main.remote origin\n> $ git config branch.main.merge refs/heads/main\n\nPerfect ;-)  Thanks.\n"},{"id":"509695","messageId":"20241228190827.GB815586@coredump.intra.peff.net","threadId":"62706","inReplyTo":"87h66nk9uy.fsf@igel.home","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-12-28T19:08:27Z","receivedAt":"2024-12-28T19:08:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 28, 2024 at 06:15:01PM +0100, Andreas Schwab wrote:\n\n> On Dez 28 2024, crstml@libero.it wrote:\n> \n> > My question is:\n> >      Is it possible when applying the method 2 to have (without pushing)\n> >      the local main branch connected to the remote origin/main branch as\n> >      in the case of method 1 which by cloning connects these branches.\n> \n> You can establish the effect by setting two config entries:\n> \n> $ git config branch.main.remote origin\n> $ git config branch.main.merge refs/heads/main\n\nAlso:\n\n  git branch --set-upstream-to=origin/main main\n\n(sets the same config variables, but maybe a little more ergonomic).\n\n-Peff\n"},{"id":"509700","messageId":"87cyhbk35g.fsf@igel.home","threadId":"62706","inReplyTo":"20241228190827.GB815586@coredump.intra.peff.net","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2024-12-28T19:39:55Z","receivedAt":"2024-12-28T19:48:28Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Dez 28 2024, Jeff King wrote:\n\n> On Sat, Dec 28, 2024 at 06:15:01PM +0100, Andreas Schwab wrote:\n>\n>> On Dez 28 2024, crstml@libero.it wrote:\n>> \n>> > My question is:\n>> >      Is it possible when applying the method 2 to have (without pushing)\n>> >      the local main branch connected to the remote origin/main branch as\n>> >      in the case of method 1 which by cloning connects these branches.\n>> \n>> You can establish the effect by setting two config entries:\n>> \n>> $ git config branch.main.remote origin\n>> $ git config branch.main.merge refs/heads/main\n>\n> Also:\n>\n>   git branch --set-upstream-to=origin/main main\n>\n> (sets the same config variables, but maybe a little more ergonomic).\n\nThat does not work if origin/main does not exist yet.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"509706","messageId":"e6d9bd13-eddb-2cc7-f27c-13d2b64b487a@libero.it","threadId":"62706","inReplyTo":"027f01db5943$340b2c70$9c218550$@nexbridge.com","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"crstml@libero.it","sentAt":"2024-12-29T09:01:00Z","receivedAt":"2024-12-29T09:01:04Z","isPatch":false,"sender":{"key":"crstml@libero.it","avatar":null},"body":"rsbecker@nexbridge.com wrote:\n> On December 28, 2024 10:47 AM crstml@libero.it wrote:\n>> I would like to put a set of files under version control and I have some issues with\n>> the workflow. Let me explain:\n>>\n>> First I create the bare repository with the command:\n>>\n>>      git init --bare -b main ~/rps/project-x.git\n>>\n>> Then I can proceed in one of the following ways:\n>>\n>>\n>> ---- Method 1 ----\n>>\n>>     By first cloning the remote repository locally and next\n>>     putting the files under version control. All running the\n>>     following commands:\n>>\n>>     1    cd ~/projects;\n>>     2    git clone ~/rps/project-x.git project-x\n>>     3    cp ~/my-existing-project-x-files/* project-x\n>>     4    cd project-x\n>>     5    git add .\n>>     6    git commit -m \"fc\"\n>>     7    git push origin\n>>     8    rm -rf ~/my-existing-project-x-files   # clean your home folder\n>>\n>> ---- Method 2 ----\n>>\n>>     By putting the existing files under version control and next\n>>     adding the remote. Running the following commands:\n>>\n>>     1    cd ~/projects/project-x\n>>     2    git init -b main\n>>     3    git add .\n>>     4    git commit -m \"fc\"\n>>     5    git remote add origin ~/rps/project-x.git\n>>     6    git push --set-upstream origin main\n>>\n>>\n>> Let me discuss both these methods:\n>>\n>> Method 1:\n>>\n>>    Everything works but the cp statement may be problematic. If\n>>    you have hidden files (starting with .) or if you want to\n>>    preserve the file permissions and owenership, the invokation\n>>    of the cp command is trickier.\n>>\n>>    After you copy the files all the next statements work well.\n>>    The main branch in the cloned repository is connected to the\n>>    upstream origin/main branch and \"git push\" will work.\n>>\n>>    There is one more small problem with this workflow: the\n>>    statement 8 is ugly.\n>>\n>>\n>>\n>> Method 2\n>>\n>>    Everything is very clean (apparently). We don't have to think\n>>    to file permissions, hidden files, tricky cp invocations and\n>>    there is no need to clean your home folder at the end. We are\n>>    interested to put files under version control, so we focus only\n>>    the version control system.\n>>\n>>\n>>    The problem  with this workflow (from my point of view) is the\n>>    statement 6. This statement makes two things which is contrary\n>>    to the UNIX philosophy: programs that do one thing and do it well.\n>>\n>>        1) The command connects the local main branch to the\n>>           remote origin/main branch.\n>>\n>>        2) Pushes the files to the remote.\n>>\n>>    From my point of view instead of executing the statement 6 I would\n>>    like to execute the following two statements that I will number\n>>    here as 6.1 and 6.2:\n>>\n>>     6.1  # To connect the main branch to origin/main\n>>          #\n>>          git branch -u origin/main main\n>>\n>>     6.2  # To push to the remote.\n>>          #\n>>          git push origin\n>>\n>>     However, the statement 6.1 does not work. Git prints the following\n>>     message.\n>>\n>>     hint: If you are planning on basing your work on an upstream\n>>     hint: branch that already exists at the remote, you may need to\n>>     hint: run \"git fetch\" to retrieve it.\n>>     hint:\n>>     hint: If you are planning to push out a new local branch that\n>>     hint: will track its remote counterpart, you may want to use\n>>     hint: \"git push -u\" to set the upstream config as you push.\n>>     hint: Disable this message with \"git config advice.setUpstreamFailure false\"\n>>\n>>     The end solution it suggests to use with \"git push -u\" which\n>>     is the same as the statement on line 6 that I would like to\n>>     avoid.  I would add that by issuing a \"git fecth\" before 6.1\n>>     would not bring the remote branch origin/main in the local\n>>     repository.\n>>\n>>     The core of the problem is that the local branch main is not connected\n>>     to the origin/main branch.\n>>\n>> My question is:\n>>       Is it possible when applying the method 2 to have (without pushing)\n>>       the local main branch connected to the remote origin/main branch as\n>>       in the case of method 1 which by cloning connects these branches.\n> \n> I think method 2 is failing for you because you do not have origin/main in your\n> local repository. That requires a git fetch. Git fetch will not overwrite your\n> working area, but is needed so that tracking can occur with an existing\n> remote branch.\n>\n> The reason git push -u works is that the resolution of your branch tracking\n> can be worked out by git as part of the push, where the remote reference\n> is known. Without that, the git branch -u does not work (no reference).\n> \n> So do the git fetch as 5.9 in Method 2, then 6.1 should work, assuming origin/main\n> exists in your remote. This downloads the clone history without modifying\n> your work area, so it should be fine.\n> \nGood observations.\n\nI've imagined that the commit history and the configuration of the remote\nrepository is necessary to be known to the local git and I've also performed\na test in which I've executed a \"git fetch\" before 6.1 (without \"git fetch\"\nno information from the remote repository exists locally).\n\nUnfortunately it did not work and git printed out the following message:\n\nhint:\nhint: If you are planning on basing your work on an upstream\nhint: branch that already exists at the remote, you may need to\nhint: run \"git fetch\" to retrieve it.\nhint:\nhint: If you are planning to push out a new local branch that\nhint: will track its remote counterpart, you may want to use\nhint: \"git push -u\" to set the upstream config as you push.\nhint: Disable this message with \"git config advice.setUpstreamFailure false\"\n\n\n> --Randall\n> \n\n"},{"id":"509707","messageId":"5dfb85a8-2e26-92f8-e3f9-5e3fb89ca43a@libero.it","threadId":"62706","inReplyTo":"87h66nk9uy.fsf@igel.home","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"crstml@libero.it","sentAt":"2024-12-29T10:01:56Z","receivedAt":"2024-12-29T10:02:00Z","isPatch":false,"sender":{"key":"crstml@libero.it","avatar":null},"body":"Andreas Schwab wrote:\n> On Dez 28 2024, crstml@libero.it wrote:\n> \n>> My question is:\n>>       Is it possible when applying the method 2 to have (without pushing)\n>>       the local main branch connected to the remote origin/main branch as\n>>       in the case of method 1 which by cloning connects these branches.\n> \n> You can establish the effect by setting two config entries:\n> \n> $ git config branch.main.remote origin\n> $ git config branch.main.merge refs/heads/main\n> \n\nIndeed.\n\nBy making a diff between a folder containing a cloned empty repository (method 1)\nand an empty folder in which \"git init\" and \"git remote\" were run (method 2) the\nonly difference is in the .git/config file. In the cloned version the file contains\nthe following section:\n\n[branch \"main\"]\n         remote = origin\n         merge = refs/heads/main\n\nThese commands add exactly this section to the file.\n\n\"git branch -u\" does exactly the same thing when connecting a local branch to\nan existing remote branch. It adds this section. \"git push ---set-upstream\"\nalso does the same thing.\n\nIt would be nice if \"git branch -u\" would work for an empty remote repository\nand allow us to set the upstream branch.\n\nCristian\n\n\n\n\n\n"},{"id":"509708","messageId":"558a48b6-d818-a5bf-6988-e0a500c6d5fc@libero.it","threadId":"62706","inReplyTo":"87h66nk9uy.fsf@igel.home","subject":"Re: connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"crstml@libero.it","sentAt":"2024-12-29T10:03:19Z","receivedAt":"2024-12-29T10:03:21Z","isPatch":false,"sender":{"key":"crstml@libero.it","avatar":null},"body":"Andreas Schwab wrote:\n> On Dez 28 2024, crstml@libero.it wrote:\n> \n>> My question is:\n>>       Is it possible when applying the method 2 to have (without pushing)\n>>       the local main branch connected to the remote origin/main branch as\n>>       in the case of method 1 which by cloning connects these branches.\n> \n> You can establish the effect by setting two config entries:\n> \n> $ git config branch.main.remote origin\n> $ git config branch.main.merge refs/heads/main\n> \n\nExcelent. Thank you for the info.\n\nCristian\n"},{"id":"509710","messageId":"030601db59ff$8c966280$a5c32780$@nexbridge.com","threadId":"62706","inReplyTo":"5dfb85a8-2e26-92f8-e3f9-5e3fb89ca43a@libero.it","subject":"RE: connecting the local main branch to the remote origin/main without pushing","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-12-29T14:39:58Z","receivedAt":"2024-12-29T14:40:15Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 29, 2024 5:02 AM, crstml@libero.it wrote:\n>Andreas Schwab wrote:\n>> On Dez 28 2024, crstml@libero.it wrote:\n>>\n>>> My question is:\n>>>       Is it possible when applying the method 2 to have (without pushing)\n>>>       the local main branch connected to the remote origin/main branch as\n>>>       in the case of method 1 which by cloning connects these branches.\n>>\n>> You can establish the effect by setting two config entries:\n>>\n>> $ git config branch.main.remote origin $ git config branch.main.merge\n>> refs/heads/main\n>>\n>\n>Indeed.\n>\n>By making a diff between a folder containing a cloned empty repository (method 1)\n>and an empty folder in which \"git init\" and \"git remote\" were run (method 2) the\n>only difference is in the .git/config file. In the cloned version the file contains the\n>following section:\n>\n>[branch \"main\"]\n>         remote = origin\n>         merge = refs/heads/main\n>\n>These commands add exactly this section to the file.\n>\n>\"git branch -u\" does exactly the same thing when connecting a local branch to an\n>existing remote branch. It adds this section. \"git push ---set-upstream\"\n>also does the same thing.\n>\n>It would be nice if \"git branch -u\" would work for an empty remote repository and\n>allow us to set the upstream branch.\n\nIt might be a useful contribution to make git branch --force -u understand this.\n\n"}]}