git/list[1] front-page[2] threads[3] people[4] search[5] about
 

connecting the local main branch to the remote origin/main without pushing

From
Ccrstml@libero.it <crstml@libero.it>
Date
Dec 28, 2024, 15:47 UTC
Message-ID
<a69c4e2e-cbb0-c242-a34a-8997a84fefb7@libero.it>
Hello all

I would like to put a set of files under version control and I have some issues with the workflow. Let me explain:

First I create the bare repository with the command:
     git init --bare -b main ~/rps/project-x.git
Then I can proceed in one of the following ways:
---- Method 1 ----
    By first cloning the remote repository locally and next
    putting the files under version control. All running the
    following commands:
    1    cd ~/projects;
    2    git clone ~/rps/project-x.git project-x
    3    cp ~/my-existing-project-x-files/* project-x
    4    cd project-x
    5    git add .
    6    git commit -m "fc"
    7    git push origin
    8    rm -rf ~/my-existing-project-x-files   # clean your home folder
---- Method 2 ----
    By putting the existing files under version control and next
    adding the remote. Running the following commands:
    1    cd ~/projects/project-x
    2    git init -b main
    3    git add .
    4    git commit -m "fc"
    5    git remote add origin ~/rps/project-x.git
    6    git push --set-upstream origin main
Let me discuss both these methods:
Method 1:
   Everything works but the cp statement may be problematic. If
   you have hidden files (starting with .) or if you want to
   preserve the file permissions and owenership, the invokation
   of the cp command is trickier.
   After you copy the files all the next statements work well.
   The main branch in the cloned repository is connected to the
   upstream origin/main branch and "git push" will work.
   There is one more small problem with this workflow: the
   statement 8 is ugly.
Method 2
   Everything is very clean (apparently). We don't have to think
   to file permissions, hidden files, tricky cp invocations and
   there is no need to clean your home folder at the end. We are
   interested to put files under version control, so we focus only
   the version control system.
   The problem  with this workflow (from my point of view) is the
   statement 6. This statement makes two things which is contrary
   to the UNIX philosophy: programs that do one thing and do it well.
       1) The command connects the local main branch to the
          remote origin/main branch.
       2) Pushes the files to the remote.
   From my point of view instead of executing the statement 6 I would
   like to execute the following two statements that I will number
   here as 6.1 and 6.2:
    6.1  # To connect the main branch to origin/main
         #
         git branch -u origin/main main
    6.2  # To push to the remote.
         #
         git push origin
    However, the statement 6.1 does not work. Git prints the following
    message.
    hint: If you are planning on basing your work on an upstream
    hint: branch that already exists at the remote, you may need to
    hint: run "git fetch" to retrieve it.
    hint:
    hint: If you are planning to push out a new local branch that
    hint: will track its remote counterpart, you may want to use
    hint: "git push -u" to set the upstream config as you push.
    hint: Disable this message with "git config advice.setUpstreamFailure false"
    The end solution it suggests to use with "git push -u" which
    is the same as the statement on line 6 that I would like to
    avoid.  I would add that by issuing a "git fecth" before 6.1
    would not bring the remote branch origin/main in the local
    repository.
    The core of the problem is that the local branch main is not connected
    to the origin/main branch.
My question is:
      Is it possible when applying the method 2 to have (without pushing)
      the local main branch connected to the remote origin/main branch as
      in the case of method 1 which by cloning connects these branches.

Thank you Cristian

Next: rsbecker@nexbridge.com
Message 1 of 10 in “connecting the local main branch to the remote origin/main without pushing”
  1. crstml@libero.itDec 28, 2024
  2. rsbecker@nexbridge.comDec 28, 2024
  3. crstml@libero.itDec 29, 2024
  4. Andreas SchwabDec 28, 2024
  5. Junio C HamanoDec 28, 2024
  6. Jeff KingDec 28, 2024
  7. Andreas SchwabDec 28, 2024
  8. crstml@libero.itDec 29, 2024
  9. rsbecker@nexbridge.comDec 29, 2024
  10. crstml@libero.itDec 29, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.