• flying_sheep@lemmy.ml
      link
      fedilink
      arrow-up
      45
      arrow-down
      2
      ·
      6 months ago

      No, don’t do that. That modifies the commit hashes, so tags no longer work.

      git clone --filter=blob:none is where it’s at.

      • masterspace@lemmy.ca
        link
        fedilink
        English
        arrow-up
        25
        arrow-down
        7
        ·
        edit-2
        6 months ago

        I don’t understand how we’re all using git and it’s not just some backend utility that we all use a sane wrapper for instead.

        Everytime you want to do anything with git it’s a weird series or arcane nonsense commands and then someone cuts in saying “oh yeah but that will destroy x y and z, you have to use this other arcane nonsense command that also sounds nothing like you’re trying to do” and you sit there having no idea why either of them even kind of accomplish what you want.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          21
          ·
          6 months ago

          It’s because git is a complex tool to solve complex problems. If you’re one hacker working alone, RCS will do an acceptable job. As soon as you add a second hacker, things change and RCS will quickly show its limitations. FOSS version control went through CVS and SVN before finally arriving at git, and there are good reasons we made each of those transitions. For that matter, CVS and SVN had plenty of arcane stuff to fix weird scenarios, too, and in my subjective experience, git doesn’t pile on appreciably more.

          You think deleting an empty directory should be easy? CVS laughs at your effort, puny developer.

          • masterspace@lemmy.ca
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            2
            ·
            edit-2
            6 months ago

            It’s because git is a complex tool to solve complex problems. If you’re one hacker working alone, RCS will do an acceptable job. As soon as you add a second hacker, things change and RCS will quickly show its limitations. FOSS version control went through CVS and SVN before finally arriving at git, and there are good reasons we made each of those transitions. For that matter, CVS and SVN had plenty of arcane stuff to fix weird scenarios, too, and in my subjective experience, git doesn’t pile on appreciably more.

            Yes it is a complex tool that can solve complex problems, but me as a typical developer, I am not doing anything complex with it, and the CLI surface area that’s exposed to me is by and large nonsense and does not meet me where I’m at or with the commands or naming I would expect.

            I mean NPM is also a complex tool, but the CLI surface area of NPM is “npm install”.

            • zalgotext@sh.itjust.works
              link
              fedilink
              arrow-up
              7
              arrow-down
              1
              ·
              6 months ago

              I am not doing anything complex with it

              So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

              the CLI surface area that’s exposed to me is by and large nonsense and does not meet me where I’m at

              What an interesting way to say “git has steep learning curve”. Which is true, git takes time to learn and even more to master. You can get there solely by reading the man pages and online docs though, which isn’t something a lot of other complex tools can say (looking at you kubernetes).

              Also I don’t know if a package manager really compares in complexity to git, which is not just a version control tool, it’s also a thin interface for manipulating a directed acyclic graph.

              • masterspace@lemmy.ca
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                6 months ago

                So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

                You mean: git add -A, git commit -m "xxx", git push or git push -u origin --set-upstream, etc. etc. etc. I get that there’s probably a reason for it’s complexity, but it doesn’t change the fact that it doesn’t just have a steep learning curve, it’s flat out remarkably user unfriendly sometimes.

                • zalgotext@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  4
                  ·
                  6 months ago

                  git add with no arguments outputs a message telling you to specify a path.

                  git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

                  git push with no arguments will literally print the git push --set-upstream command you need to run if your branch has no upstream.

                  Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

                  • masterspace@lemmy.ca
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    edit-2
                    6 months ago

                    git add with no arguments outputs a message telling you to specify a path.

                    Yes, but a more sensible default would be -A since that is how most developers use it most of the time.

                    git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

                    Git commit with no arguments drops you into vim, less a text editor and more a cruel joke of figuring out how to exit it.

                    Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

                    Git has a steep learning curve not because it’s necessary but because it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

                    It is great software and obviously better than most other version control systems, but it still has asinine defaults and it’s cli surface is over complicated. When I worked at a MAANG company and had to learn their proprietary version control system my first thought was “this is dumb, why wouldn’t you just use git like everyone else”, then I went back to Git and realized how much easier and more sensible their system was.

        • zalgotext@sh.itjust.works
          link
          fedilink
          arrow-up
          9
          ·
          6 months ago

          There are tons of wrappers for git, but they all kinda suck. They either don’t let you do something the cli does, so you have to resort to the arcane magicks every now and then anyways. Or they just obfuscate things to the point where you have no idea what it’s doing, making it impossible to know how to fix things if (when) it fucks things up.

        • Phoenixz@lemmy.ca
          link
          fedilink
          arrow-up
          6
          ·
          6 months ago

          Git is complicated, but then again, it’s a tool with a lot of options. Could it be nicer and less abstract in its use? Sure!

          However, if you compare what goes does, and how it does, to it’s competitors, then git is quite amazing. 5-10 years ago it was all svn, the dark times. Simpler tool and an actual headache to use.

        • flying_sheep@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          I think in this case, “depth” was am inferior solution to achieve fast cloning, that they could quickly implement. Sparse checkout (“filter”) is the good solution that only came out recently-ish

        • Socsa@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          6 months ago

          You are not entirely wrong, but just as some advice I would refrain from displaying fear of the command line in interviews.

          • masterspace@lemmy.ca
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            6 months ago

            Lol if an employer can’t have an intelligent discussion about user friendly interface design I’m happy to not work for them.

            Every interview I’ve ever been in there’s been some moment where I say ‘yeah I don’t remember that specific command, but conceptually you need to do this and that, if you want I can look up the command’ and they always say something along the lines of ‘oh no, yeah, that makes conceptual sense don’t worry about it, this isn’t a memory test’.

            • Socsa@sh.itjust.works
              link
              fedilink
              arrow-up
              3
              arrow-down
              2
              ·
              6 months ago

              For a lot of experienced people, command line tools are user friendly interface design.

              • masterspace@lemmy.ca
                link
                fedilink
                English
                arrow-up
                3
                ·
                edit-2
                6 months ago

                Command line tools can be, git’s interface is not. There would not be million memes about exiting vim if it was.

                • brisk@aussie.zone
                  link
                  fedilink
                  arrow-up
                  2
                  arrow-down
                  2
                  ·
                  6 months ago

                  These things are not related. Git uses the system default editor, which is exactly what a cli program dropping you into an editor should use. If that’s Vim and you don’t like that, you need to configure your system or take it up with your distro maintainers.

                  • masterspace@lemmy.ca
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    6 months ago

                    No, it should prompt you to enter your one sentence description in the CLI itself, and kick you out to an editor only if you provide a flag saying you like writing paragraph long commit descriptions.

      • kevincox@lemmy.ml
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        6 months ago

        What are you smoking? Shallow clones don’t modify commit hashes.

        The only thing that you lose is history, but that usually isn’t a big deal.

        --filter=blob:none probably also won’t help too much here since the problem with node_modules is more about millions of individual files rather than large files (although both can be annoying).

        • flying_sheep@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          From github’s blog:

          git clone --depth=1 <url> creates a shallow clone. These clones truncate the commit history to reduce the clone size. This creates some unexpected behavior issues, limiting which Git commands are possible. These clones also put undue stress on later fetches, so they are strongly discouraged for developer use. They are helpful for some build environments where the repository will be deleted after a single build.

          Maybe the hashes aren’t different, but the important part is that comparisons beyond the fetched depth don’t work: git can’t know if a shallowly cloned repo has a common ancestor with some given commit outside the range, e.g. a tag.

          Blobless clones don’t have that limitation. Git will download a hash+path for each file, but it won’t download the contents, so it still takes much less space and time.

          If you want to skip all file data without any limitations, you can do git clone --filter=tree:0 which doesn’t even download the metadata

          • kevincox@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            6 months ago

            Yes, if you ask about a tag on a commit that you don’t have git won’t know about it. You would need to download that history. You also can’t in general say “commit A doesn’t contain commit B” as you don’t know all of the parents.

            You are completely right that --depth=1 will omit some data. That is sort of the point but it does have some downsides. Filters also omit some data but often the data will be fetched on demand which can be useful. (But will also cause other issues like blame taking ridiculous amounts of time.)

            Neither option is wrong, they just have different tradeoffs.