3 ms·

Are basic git concepts like bare repos "obscure tribal knowledge" these days? What do you think ".git" directory is?

by seba_dos1 1y ago

max_ 1y ago
Having to make a repo bare to not have issues with branches is definitely obscure.
- deleted 1y ago
  [deleted]
- jdboyd 1y ago
  It wasn't obscure before GitHub. Still, I like the online browser, and pr workflow.
  - zenmac 1y ago
    Yeah this is the best arguments for GitHub type of web git GUI. Not knowing bare repo seems just like a devs not reading docs. And I'm sorry in this day and age devs needs to keep up and just type git like curl http://...../install.sh type of thing. However would NEVER trust Github since the MS acquisition. codeberg and https://forgejo.org https://forgejo.org are perfectly sound FOSS alternative to GitHub and GigLabs nowdays.
- deleted 1y ago
  [deleted]
- seba_dos1 1y ago
  It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens when pushing to local repos. You don't have to make a repo bare to avoid this issue, but it's certainly the easiest way to avoid it altogether when you don't need a workdir on the server side.
  - Dylan16807 1y ago
    It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.
    - seba_dos1 1y ago
      It's obvious that something non-obvious would have to happen with the workdir behind the user's back. Imagine that you are working with your workdir while someone else pushes something to your repo. Bailing out is the only sane option (unless something else has been explicitly requested by the user).
      - Dylan16807 1y ago
        Nothing has to happen to the workdir if you fix HEAD.
        seba_dos1 1y ago
        ...except of all the things that rely on the HEAD pointing to another ref now changing their behavior. gbp will by default bail off if HEAD is not on a branch, "git commit" won't update the ref you thought it will cause you're now suddenly on "detached HEAD" etc.
        Dylan16807 1y ago
        I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method. Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in general.
        seba_dos1 1y ago
have_faith 1y ago
The vast majority of developers working with git daily don’t know what a bare repo is, or that it exists at all. It’s not obscure knowledge as such, it’s just never come up for them as something they need.
- seba_dos1 1y ago
  The vast majority [0] of developers working with git daily have no mental model of git repos and just do a mental equivalent of copy'n'pasting commands and it's enough to let them do their work (until something breaks at least), so it doesn't seem like a particularly good indicator of whether something is obscure or not. There are many obscure things hiding in git, bare repos aren't one of those :) [0] Source: pulled out of my arse.
general1465 1y ago
Now try to add a submodule X (which is a bare repository) to your repository Y Good job, now you can't add it nor remove it, without manually removing it in .git folder.

Are basic git concepts like bare repos "obscure tribal knowledge" these days? What do you think ".git" directory is?

max_ 1y ago

Having to make a repo bare to not have issues with branches is definitely obscure.

deleted 1y ago
[deleted]
jdboyd 1y ago
It wasn't obscure before GitHub. Still, I like the online browser, and pr workflow.
- zenmac 1y ago
  Yeah this is the best arguments for GitHub type of web git GUI. Not knowing bare repo seems just like a devs not reading docs. And I'm sorry in this day and age devs needs to keep up and just type git like curl http://...../install.sh type of thing. However would NEVER trust Github since the MS acquisition. codeberg and https://forgejo.org https://forgejo.org are perfectly sound FOSS alternative to GitHub and GigLabs nowdays.
deleted 1y ago
[deleted]
seba_dos1 1y ago
It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens when pushing to local repos. You don't have to make a repo bare to avoid this issue, but it's certainly the easiest way to avoid it altogether when you don't need a workdir on the server side.
- Dylan16807 1y ago
  It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.
  - seba_dos1 1y ago
    It's obvious that something non-obvious would have to happen with the workdir behind the user's back. Imagine that you are working with your workdir while someone else pushes something to your repo. Bailing out is the only sane option (unless something else has been explicitly requested by the user).
    - Dylan16807 1y ago
      Nothing has to happen to the workdir if you fix HEAD.
      - seba_dos1 1y ago
        ...except of all the things that rely on the HEAD pointing to another ref now changing their behavior. gbp will by default bail off if HEAD is not on a branch, "git commit" won't update the ref you thought it will cause you're now suddenly on "detached HEAD" etc.
        Dylan16807 1y ago
        I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method. Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in general.
        seba_dos1 1y ago

have_faith 1y ago

The vast majority of developers working with git daily don’t know what a bare repo is, or that it exists at all. It’s not obscure knowledge as such, it’s just never come up for them as something they need.

seba_dos1 1y ago
The vast majority [0] of developers working with git daily have no mental model of git repos and just do a mental equivalent of copy'n'pasting commands and it's enough to let them do their work (until something breaks at least), so it doesn't seem like a particularly good indicator of whether something is obscure or not. There are many obscure things hiding in git, bare repos aren't one of those :) [0] Source: pulled out of my arse.

general1465 1y ago

Now try to add a submodule X (which is a bare repository) to your repository Y Good job, now you can't add it nor remove it, without manually removing it in .git folder.