8 ms·

Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/

• archerx 4mo ago
  I use GitHub desktop app that pushes to my local Gitlab. It’s a nice and simple GUI, it might be what you’re looking for.
• cedws 4mo ago
  Git as a data structure is clever, but Git as a CLI is atrocious.
  • raverbashing 4mo ago
    Yes, the famous debate between plumbing and porcelain Still the porcelain is more like cold stainless steel
  • cmrdporcupine 4mo ago
    Obligatory: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
    • xiaoyu2006 4mo ago
      this is such a good laugh. peak comedy
    • computerdork 4mo ago
      haha! The flaunt revisions flag is hilarious! --flaunt-revision=<commit-graph> - Flaunt the revisions of extra commit IDs that are mirrorred. Is the tool taunting you?
      • cmrdporcupine 4mo ago
        afaik they're randomly generated so you're likely the first and last person to see that permutation
        • computerdork 4mo ago
          was wondering how and who created this site:)
          • cmrdporcupine 4mo ago
            It's been around for over a decade at this point. https://github.com/perotinus/git-man-page-generator https://github.com/perotinus/git-man-page-generator Earliest commits and mentions 2014. But could swear I saw it before that.
            • computerdork 4mo ago
              thanks for the history on this, funny stuff:)
  • VikingCoder 4mo ago
    I feel like, everyone near Git has decided, "Well, all abstractions leak - so we might as well stand in the rain like Andy Dufresne when he escaped from Shawshank Prison!"
  • 1718627440 4mo ago
    But that's all Git originally aspired to be. It was supposed to be the base VCS, that you eventually can build a UI layer on top.
• e40 4mo ago
  I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.
  • maccard 4mo ago
    > It's probably just something no one has thought of doing There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
    • yoyohello13 4mo ago
      Luckily it’s an open source project so you could go in and clean up the ux.
      • LtdJorge 4mo ago
        Probably unacceptable as many would have built tooling around the specific default behaviors.
        • Jaxan 4mo ago
          You can have your own version. You don’t have to push all improvements upstream.
          • swiftcoder 4mo ago
            It's not really feasible to maintain private forks of every piece of software you use (especially something like git that needs regular security patches)
        • throw_await 4mo ago
          If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.
• kristjansson 4mo ago
  Those are just the sounds that animal makes. Live with the animal long enough, you learn how the sounds correspond to its internal states, even if you don’t really know what they mean. I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
• agumonkey 4mo ago
  I actually like this underlying logs. Could have a concise / project level summary though.
• spelunker 4mo ago
  The lights are blinking, so everything must be working!
  • russdill 4mo ago
    Basically, sometimes there commands take a long time. It's nice to have feedback that something is happening even if it's just effectively a blinking light.
    • efreak 4mo ago
      Speaking from experience, it's also nice to have feedback that the blinking light actually means something is actively happening, and not just that a process has been started and hasn't finished (it may have gotten stuck or suspended). The only thing worse than a throbber that keeps going until everything is loaded regardless if anything is actively happening is a fake loading screen that lies to you about what it's doing. The only time you should use a throbber without context is when there's only a single action being processed and it's expected to take less than 5~10 seconds.
• yomismoaqui 4mo ago
  This is what happens when a kernel developer creates tools that need some kind of UX (I say this both as a shitty UX developer and Linus fan)
  • yoyohello13 4mo ago
    He makes a good tool? Honestly I don’t get the git hate on HN. I’ve been using it for years with no issue. I just read the first 3 parts of the git book and never looked back. I even setup a git server at home with the basic tools.
    • jon-wood 4mo ago
      This is definitely a bit snarky but you read any of the documentation at all, and therefore know more than a large percentage of git users about what it’s actually doing. Most people seem to treat git like some sort of mysterious orb which if you speak the right incantations will perform magic for you.
      • yoyohello13 4mo ago
        Reading the docs is kind of a superpower for devs. With AI I think most technology is going to be treated like praying to the machine spirit.
      • 1718627440 4mo ago
        If you don't read the documentation you can't complain if a machine stays a mystery for you. Normally you don't get to use a machine without proving you actually now what you are doing.
  • altmanaltman 4mo ago
    Linus really has very little to do with git's development. He has stated that himself multiple times, and it's the factual truth. "This is what happens when a kernel developer creates tools..." is funny but not factual.
• yoyohello13 4mo ago
  [flagged]
  • wldcordeiro 4mo ago
    What a completely rude comment that tells me everything I ever need about you and whether I'd want to interact with you. They're not asking for the literal answer. They're asking a question about why that is important to surface at all.
    • yoyohello13 4mo ago
      Sorry, you're right. It's been a frustrating morning and I shouldn't have taken it out on you.
• js2 4mo ago
  Objects are your files. Underlying git is a content-addressable filesystem. The objects are referenced by trees. A tree is just a directory. The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references): https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs. https://git-scm.com/docs/git-pack-objects https://git-scm.com/docs/git-pack-objects https://github.com/git/git/blob/master/Documentation/technical/pack-heuristics.adoc https://github.com/git/git/blob/master/Documentation/technic... When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space. https://github.com/git/git/blob/master/Documentation/technical/send-pack-pipeline.adoc https://github.com/git/git/blob/master/Documentation/technic... Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it! But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above. (Caveat: I'm working from memory and surely got some detail at least slightly wrong.)
  • genocidicbunny 4mo ago
    Now explain this to an artist with very little programming experience beyond what they picked up from their coworkers. I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them. I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.
    • js2 4mo ago
• redsocksfan45 4mo ago
  [dead]
• mherkender 4mo ago
  I'd rather see some gobbledegook than extended pauses or idealized (read: fake) information. Those are specific tasks it is doing when you run that command, there's a simplicity to it. Not saying Lore's approach is bad, but sometimes "worse is better".
• dosshell 4mo ago
  Every place I worked at has a git introduction where all new employees learn about how git works internally. Takes 1h, and all junior devs stops memories random commands and actually start to understand. I highly recommend to you to poking around in the .git directory. The git support for new employees drops basically to zero.
• gritzko 4mo ago
  Every Beagle command: gritzko@spot ~/beagle $ be get 19:07 get ?#0ac49e6a 16:58 post ?0ac49e6a#POST-018 put:/post: banner on stdout 19:07 new beagle/test/be-post-put-banner.sh 19:07 upd dog/INDEX.md ...more stuff... 19:07 del test/post/01-bare-msg/01.put.err.txt 19:07 del test/post/01-bare-msg/02.post.err.txt 19:07 get abc?4222dfab
• danudey 4mo ago
  You don't care about any of this information, but that's fine; unless something is going wrong, you can ignore any information that isn't interesting to you. Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant. In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on. Case in point, this is the output I get when I try to clone the Linux kernel: Cloning into 'linux'... remote: Enumerating objects: 11623749, done. remote: Counting objects: 100% (396/396), done. remote: Compressing objects: 100% (189/189), done. Receiving objects: 1% (181683/11623749), 90.11 MiB | 19.17 MiB/s Generally not useful information most of the time, but if I didn't have it I would be staring at a blank terminal for an hour wondering what was happening. Also, I assume you're not but in case anyone is interested in the answers to these questions: > What the hell is "delta compression"? The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next. For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB. > Why do I care how many threads it's using? Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'. > What is an 'object' and what does it mean when it's 'local'? Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object. Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has. > What does 'pack-reused' mean? To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.
• y1n0 4mo ago
  I’ve started using JJ vcs, mainly because some people were saying it was great and I didn’t really get it. I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.
  • squirrellous 4mo ago
    The last time I tried JJ it plainly refused to work with git LFS, which is kind of what OOP here is about (large files). Has that improved?
  • lkjdsklf 4mo ago
    Jj is weird. In general it’s a better ui and model than git, but there’s a few common operations that are just dumb. It also recreates a lot of the stupidity of mercurial (which makes sense) The fact that everyone needs the same stupid “tug” alias because jj wants to use “bookmarks” instead of just named branches is just classic silly shit. We’ve had named branches for 40 years. Everyone who has vcs experience knows what it is. We don’t need bookmarks. Just stop. Everyone who used mercurial used plugins to turn them into basically branches and same thing with jj.
    • y1n0 4mo ago
      That's built in now, for what it's worth.
      • BatmanAoD 4mo ago
        You mean `jj advance bookmarks`? It still seems like a pain to not just have it happen automatically on `commit`. (I use the "experimental" auto-advance-bookmarks feature, but it's got a lot of papercuts.)
    • BatmanAoD 4mo ago
      I honestly get the sense that several, or possibly most, jj maintainers truly are not familiar with the "typical" way devs use git. They really do not seem to consider branches with many commits to be a common use-case.
• bartvk 4mo ago
  I bet most people don’t use the commandline client.
• justinhj 4mo ago
  I see Git as a tool aimed at experts that spend time to learn the tool. Asking non technical people to use it is a mistake. You can build guard railed apps on top of it for them, but probably it's the wrong tool.
• dansmith1919 4mo ago
  This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.
  • yjftsjthsd-h 4mo ago
    You don't have to do add as a separate step unless you're adding it to the repo for the first time. You can (and I do) just `git commit file1 dir2` or whatever. I don't conceptually think commit+push should be combined; committing a version is separate from pushing it to a remote.
    • abustamam 4mo ago
      TIL! Thanks
      • wtetzner 4mo ago
        You can also just do `git commit -a` to commit all modified files.
  • abustamam 4mo ago
    When I was getting started with programming I often forgot to do one of those steps and often ended up losing my work because I was working from a library computer or something. When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.
    • dansmith1919 4mo ago
      Thanks, that’s exactly what I meant! It only makes sense now because we know exactly how it works, it makes no sense to a first-time user. I feel like other commenters are being obtuse on purpose and avoid the point? Or did I just not word it correctly
      • 4mo ago
• minraws 4mo ago
  If you can't understand atleast 70% of those lines of Git, you really should be using a git web app or something. Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works. Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.
• qwery 4mo ago
  I think your criticism of git's output is fine -- fair enough. What I will say to that directly is that everyone's different and expecting a UI to match every user perfectly is unreasonable. I don't think it's fair to call output that's more verbose than you'd like "user-unfriendly" without qualifying who the user/s is/are. The thing missing from most of the responses to this is: you can only get this information once. It's effectively impossible to have any of this information repeated -- you can't run it a second time with `--verbose`. I don't mind things telling me what's going on, and git's push output is perhaps verbose, but not by a margin that causes me trouble. Maybe that comes with always running less than ideal hardware and having second rate internet connections. I want to know why a command took longer to run than I expected.
• arendtio 4mo ago
  Actually, it isn't that complicated. If you have a basic understanding of how git works (a little beyond just clone, commit, and push), this can be quite helpful when working with a slow connection or large repositories.