5 ms·

not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some wei

not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible

sampullman 2y ago
I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.
- ujkiolp 2y ago
  >It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem
  - sampullman 2y ago
    A folder with a list of files is a tool to store versions of text. Git is somewhat more useful.
  - kortilla 2y ago
    Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.
    - nextaccountic 2y ago
      Mercurial is simpler than git. It is (or was) just too damn slow
      - Izkata 2y ago
        For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately. Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.
        capitainenemo 2y ago
        Mercurial has both "real" branches (history is kept so you can always tell what revisions were in what branch) as well as git "branch is just a pointer tag" So really you can choose whatever suits your needs. Personally the things I love about mercurial are: more consistent commandline (that's the simple part others bring up) revsets (awesome query language for revisions, there's also filesets, but I don't use that as much) absorb (I think someone added a git extension that does something similar a few months ago) fa --deleted grep --all phases ♥
    - maccard 2y ago
      Mercurial and perforce are a better solution for anything with a centralised repo IMO
    - ujkiolp 2y ago
      [dead]
- crabbone 2y ago
  You are using Git in a non-automated way, basically, as a substitute for rsync (you never edit history, you only append to it, you don't deal with a possibility of multiple remotes, you don't deal with modular projects and you don't automate anything). At least, this is what it looks like from your own description. This is, probably, what most people do with it most of the time. And the weird corners will be found when they need to automate things, or when they want to deal with modular repositories, or history rewrites. These aren't everyday tasks / not for everyone on the team, but, these things do happen, especially in smaller teams, where there's no dedicated infra person or group these can be delegated to.
  - maccard 2y ago
    If the tool is designed to support the use case of the 1% with concessions for the other 99%, the tool is badly designed. Git is designed for the case where you have multiple remotes with no central authority. Except that’s not how any project I’ve _ever_ worked on functions in reality. It makes sense for some applications, but if I say that I run Linux, there’s an assumption that I’m running something compiled from https://github.com/torvalds/linux https://github.com/torvalds/linux - I.e. there is a central space. I’ve used git and perforce in anger for a decade, in teams of 1 to 150+ (with a brief blip in the middle where I tried plasticscm which was a mistake), and I’ve been the “git guy” on teams during that time. If git’s defaults were tweaked for “one origin, probably authoritative” and it had better authentication support out of the box it would be a significantly better experience for 99% of people. Those 1% of people who are left over are going to customise their config anyway, so make them add the distributed-defaults=true flag and the rest of us can get on with our work.
  - sampullman 2y ago
    I'm not totally sure what you mean by "non-automated" here, can you clarify? I have managed repos for small teams, that's actually the majority of my experience with it. I do deal with multiple remotes quite often and haven't encountered issues. You're right about submodules, I avoid setting up projects with them, even at the expense of more manual work or complicated automation. I'm definitely not using it as a substitute for rsync - I do prefer to put rules in place to avoid editing (shared) history, for obvious reasons.

sampullman 2y ago

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.

ujkiolp 2y ago
>It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem
- sampullman 2y ago
  A folder with a list of files is a tool to store versions of text. Git is somewhat more useful.
- kortilla 2y ago
  Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.
  - nextaccountic 2y ago
    Mercurial is simpler than git. It is (or was) just too damn slow
    - Izkata 2y ago
      For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately. Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.
      - capitainenemo 2y ago
        Mercurial has both "real" branches (history is kept so you can always tell what revisions were in what branch) as well as git "branch is just a pointer tag" So really you can choose whatever suits your needs. Personally the things I love about mercurial are: more consistent commandline (that's the simple part others bring up) revsets (awesome query language for revisions, there's also filesets, but I don't use that as much) absorb (I think someone added a git extension that does something similar a few months ago) fa --deleted grep --all phases ♥
  - maccard 2y ago
    Mercurial and perforce are a better solution for anything with a centralised repo IMO
  - ujkiolp 2y ago
    [dead]
crabbone 2y ago
You are using Git in a non-automated way, basically, as a substitute for rsync (you never edit history, you only append to it, you don't deal with a possibility of multiple remotes, you don't deal with modular projects and you don't automate anything). At least, this is what it looks like from your own description. This is, probably, what most people do with it most of the time. And the weird corners will be found when they need to automate things, or when they want to deal with modular repositories, or history rewrites. These aren't everyday tasks / not for everyone on the team, but, these things do happen, especially in smaller teams, where there's no dedicated infra person or group these can be delegated to.
- maccard 2y ago
  If the tool is designed to support the use case of the 1% with concessions for the other 99%, the tool is badly designed. Git is designed for the case where you have multiple remotes with no central authority. Except that’s not how any project I’ve _ever_ worked on functions in reality. It makes sense for some applications, but if I say that I run Linux, there’s an assumption that I’m running something compiled from https://github.com/torvalds/linux https://github.com/torvalds/linux - I.e. there is a central space. I’ve used git and perforce in anger for a decade, in teams of 1 to 150+ (with a brief blip in the middle where I tried plasticscm which was a mistake), and I’ve been the “git guy” on teams during that time. If git’s defaults were tweaked for “one origin, probably authoritative” and it had better authentication support out of the box it would be a significantly better experience for 99% of people. Those 1% of people who are left over are going to customise their config anyway, so make them add the distributed-defaults=true flag and the rest of us can get on with our work.
- sampullman 2y ago
  I'm not totally sure what you mean by "non-automated" here, can you clarify? I have managed repos for small teams, that's actually the majority of my experience with it. I do deal with multiple remotes quite often and haven't encountered issues. You're right about submodules, I avoid setting up projects with them, even at the expense of more manual work or complicated automation. I'm definitely not using it as a substitute for rsync - I do prefer to put rules in place to avoid editing (shared) history, for obvious reasons.