6 ms·

And don't forget that each git clone can have multiple remotes. So your working copy can be simultaneously linked to any or all of GitHub, usb, local network,

by wdfx 3y ago

And don't forget that each git clone can have multiple remotes. So your working copy can be simultaneously linked to any or all of GitHub, usb, local network, nas, etc.

cbm-vic-20 3y ago
Most users believe the 'd' in "git" (or "github") stands for "distributed".
- wdfx 3y ago
  The real problem is that even though being distributed is cool and can help to ensure that your work exists in more than one place either for reasons of collaboration or backup, humans still like to cling to the idea of having a "single source of truth". So, if Alice collaborates by pull/pushing with Bob, and Bob works by patches over email with Charlie, and David exchanges with Charlie and Alice - then what is the "true" state of the repository exactly? The easy way out is that everyone pulls/pushes with github and we use that as "truth".
  - Double_a_92 3y ago
    Yeah either there is a central "source of truth" or all distributed copies have to always be kept in sync somehow. I don't understand all those people that romanticize "distributed" things but then just stop thinking about the practical implications of that...
    - wdfx 3y ago
      > or all distributed copies have to always be kept in sync somehow This isn't actually true. The collaborators simply have to ... collaborate. It depends on what the goal is with the data being kept in git. Git doesn't tell you how to collaborate. It could be that the group elects one person (e.g. Alice) to do releases, so, it stands that only that code which reaches Alice will ever get released. If that doesn't happen, you haven't collaborated correctly. It could be that any one of the group could release, in that case you collaborate to get your commits to any of those people. It could be that there are no releases ever made, and the group loosely exchanges their branches to build whatever interests them.
    - deleted 3y ago
      [deleted]
- baz00 3y ago
  Most of the people I work with can barely tell the difference between git and github.
- e12e 3y ago
  Looks like the "d" in "git" was upside down from the start...
globular-toast 3y ago
How do people even use GitHub without knowing this? You have to add your fork as a separate remote.
- wdfx 3y ago
  Can you not also push back to your fork and GH guides you to make a PR from your fork/branch to the upstream? IIRC, you don't have to deal with the upstream locally?
  - kevincox 3y ago
    Yes. You only need to add the upstream repo if you want to fetch the newest changes. So it is something that you will probably only run into on your second PR. I wouldn't be surprised if the vast majority of GitHub users never send a second PR to a third-party projects. Probably the majority of users only contribute to their own (or their company's own) repos. Then a small number send at least one pull request to another user's repo. Fewer still would send more than one in a way that requires pulling new changes from upstream.

by wdfx 3y ago

And don't forget that each git clone can have multiple remotes. So your working copy can be simultaneously linked to any or all of GitHub, usb, local network, nas, etc.

cbm-vic-20 3y ago

Most users believe the 'd' in "git" (or "github") stands for "distributed".

wdfx 3y ago
The real problem is that even though being distributed is cool and can help to ensure that your work exists in more than one place either for reasons of collaboration or backup, humans still like to cling to the idea of having a "single source of truth". So, if Alice collaborates by pull/pushing with Bob, and Bob works by patches over email with Charlie, and David exchanges with Charlie and Alice - then what is the "true" state of the repository exactly? The easy way out is that everyone pulls/pushes with github and we use that as "truth".
- Double_a_92 3y ago
  Yeah either there is a central "source of truth" or all distributed copies have to always be kept in sync somehow. I don't understand all those people that romanticize "distributed" things but then just stop thinking about the practical implications of that...
  - wdfx 3y ago
    > or all distributed copies have to always be kept in sync somehow This isn't actually true. The collaborators simply have to ... collaborate. It depends on what the goal is with the data being kept in git. Git doesn't tell you how to collaborate. It could be that the group elects one person (e.g. Alice) to do releases, so, it stands that only that code which reaches Alice will ever get released. If that doesn't happen, you haven't collaborated correctly. It could be that any one of the group could release, in that case you collaborate to get your commits to any of those people. It could be that there are no releases ever made, and the group loosely exchanges their branches to build whatever interests them.
  - deleted 3y ago
    [deleted]
baz00 3y ago
Most of the people I work with can barely tell the difference between git and github.
e12e 3y ago
Looks like the "d" in "git" was upside down from the start...

globular-toast 3y ago

How do people even use GitHub without knowing this? You have to add your fork as a separate remote.

wdfx 3y ago
Can you not also push back to your fork and GH guides you to make a PR from your fork/branch to the upstream? IIRC, you don't have to deal with the upstream locally?
- kevincox 3y ago
  Yes. You only need to add the upstream repo if you want to fetch the newest changes. So it is something that you will probably only run into on your second PR. I wouldn't be surprised if the vast majority of GitHub users never send a second PR to a third-party projects. Probably the majority of users only contribute to their own (or their company's own) repos. Then a small number send at least one pull request to another user's repo. Fewer still would send more than one in a way that requires pulling new changes from upstream.