Announcement

Collapse
No announcement yet.

Git 2.45 Released With Initial SHA1/SHA256 Interoperability & Reftable Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by uid313 View Post
    Yes, I do know what a version control software is and what it is used for. I have used Microsoft's Team Foundation Version Control (TFVC) on Azure DevOps. TFVC is a bit different from Git thought because TFVC is a VCS while Git is a DVCS so Git is distributed. TFVS is much easier than Git.
    Distributed simply means you have a local copy of the repo and then you upload/download from the "online" one as you wish. What's harder about local vs online? I don't get it. You know how uploading or downloading with browser works right? Local files vs remote files? Download a copy of a website's html locally?

    git terminology:
    push: upload
    pull/fetch/clone: download
    remote: "online" repo

    Other operations like checkout are done on your local copy of the repo.

    Tip: use firewall and block internet access for git, see what works and what doesn't. You'll be surprised how much stuff works. It's all done locally.

    You should actually be relieved for this, because if you mess up your local repo, it's totally fine, nobody will see it. There's nothing to be embarrassed about, and no apology to string up (assuming you wrecked the online repo in some other VCS).

    You can then just redownload fresh copy with git clone or whatever.
    Last edited by Weasel; 01 May 2024, 12:59 PM.

    Comment


    • #12
      Originally posted by Weasel View Post
      Distributed simply means you have a local copy of the repo and then you upload/download from the "online" one as you wish. What's harder about local vs online? I don't get it. You know how uploading or downloading with browser works right? Local files vs remote files? Download a copy of a website's html locally?

      git terminology:
      push: upload
      pull/fetch/clone: download
      remote: "online" repo

      Other operations like checkout are done on your local copy of the repo.

      Tip: use firewall and block internet access for git, see what works and what doesn't. You'll be surprised how much stuff works. It's all done locally.

      You should actually be relieved for this, because if you mess up your local repo, it's totally fine, nobody will see it. There's nothing to be embarrassed about, and no apology to string up (assuming you wrecked the online repo in some other VCS).

      You can then just redownload fresh copy with git clone or whatever.
      Distributed is different because in TFVS you just "Get Latest" to get everything from the server to your local workspace but with Git you must do do a fetch and a pull to get it to your local repository and then into your local branch so it is two operations instead of one. In TFVS you just do "Check-in" in one operation but in Git you first have to commit then push so it is two operations.

      So yeah a distributed VCS is a bit a different and a bit more complicated, but I do get how a distributed VCS is different from a VCS and I do grasp the concept of a distributed VCS. I get how Git works offline.

      But TFVS is easier than Git because you don't have to specify any merging strategy and it can auto-resolve merge conflicts for you.

      Comment


      • #13
        Originally posted by uid313 View Post

        Distributed is different because in TFVS you just "Get Latest" to get everything from the server to your local workspace but with Git you must do do a fetch and a pull to get it to your local repository and then into your local branch so it is two operations instead of one. In TFVS you just do "Check-in" in one operation but in Git you first have to commit then push so it is two operations.

        So yeah a distributed VCS is a bit a different and a bit more complicated, but I do get how a distributed VCS is different from a VCS and I do grasp the concept of a distributed VCS. I get how Git works offline.

        But TFVS is easier than Git because you don't have to specify any merging strategy and it can auto-resolve merge conflicts for you.
        You don't need fetch and pull. Pull is fetch + merge. Commit and push are separate because your local copy of the repo is a FULL copy, you don't need a remote. And you can push multiple commits at once.

        Git supports having multiple remotes, which is why there are separate commands for "update my understanding of a remote" (fetch) and "give me their changes" (merge, which works works with both local branches and remote ones, specified as remote/branch).

        Git has a default merge strategy, you shouldn't need to specify one. And it auto merges changes, unless it hits a situation where that can't happen. Like if both sides have changed the same line.

        Comment


        • #14
          Originally posted by Jaxad0127 View Post

          You don't need fetch and pull. Pull is fetch + merge. Commit and push are separate because your local copy of the repo is a FULL copy, you don't need a remote. And you can push multiple commits at once.

          Git supports having multiple remotes, which is why there are separate commands for "update my understanding of a remote" (fetch) and "give me their changes" (merge, which works works with both local branches and remote ones, specified as remote/branch).

          Git has a default merge strategy, you shouldn't need to specify one. And it auto merges changes, unless it hits a situation where that can't happen. Like if both sides have changed the same line.
          My experience is that I get merge conflicts all and told I have to stash my changes before I can pull even if I changed line 5 and remote has changed line 100.

          Comment

          Working...
          X