3 ms·

Version control feels like it does require some complexity though. I think we all like to imagine that all it does is stores changes per file, wrapped in commit

Version control feels like it does require some complexity though. I think we all like to imagine that all it does is stores changes per file, wrapped in commits. But when you add requirements like merging other people’s work with yours, movable “tags” to mark named versions, and the sort of cut/splice/move around operations you will always need because you accidentally did something you shouldn’t have… I think you end up rebuilding most of Git’s plumbing.

p-e-w 4y ago
Video codecs are also complex (actually, they are almost unimaginably complex). But I've never seen a smart TV telling the user something about "lapped transforms" or "chroma subsampling". I'm a user of Git. Why do I have to learn about implementation complexities in order to fix problems that arise from normal version control operations? I can't think of any other software that forces me to do this. Even compilers (at least those for mainstream programming languages) don't require me to understand their AST representation or other details of how they work internally.
- taeric 4y ago
  Televisions absolutely do this for power users. Or give them terrible image quality for regular users.
- graypegg 4y ago
  WildBit had a really cool project a while ago called Conveyor. [0] It’s a shame it never took off. It was built on git, but hid the complexity of branching + other git things behind “tasks”. You’d start a task, and silently push that branch out to everyone. It’d silently merge things in the background and handle a lot of the chores you have to do with git rebasing and such to keep branches mergeable. It failed miserably with us because it perpetually created impossible to solve git issues. Someone accidentally removes a gitignore file and commits a config file with a password? Your SOL. It will keep coming back because it will exist on at least one other person’s device which will get force pushed back to the repo. The weird plumbing exists because version control is hard, and prone to humans throwing wrenches into its nominally perfect system. The real reason you don’t remember every magic git incantation is because you normally only need a specific one, once a year. But it has to be there! [0] https://web.archive.org/web/20190226201600/https://conveyor.com/ https://web.archive.org/web/20190226201600/https://conveyor....
- theamk 4y ago
  TVs are consuming devices. If you are only wishing to consume git, you need to know "git clone" and "git checkout", and that's it, no need for internals. Or manybe not even that, you need to know where "download" link on Github interface is. If you are encoding video, you often need to know about chroma subsampling, and colorspaces, and fractional framerate and all the other absurd technical details. It is actually much worse than git. You can avoid those technical details if you use high-level software, only stay on happy path, and avoid any complex operations. You'll take longer and produce worse quality output than if you had fully mastered the software -- but often this is OK. This is true both for video encoding and for git.
  - wruza 4y ago
    I have a gsync display and a cool graphics card. But to achieve the smoothest experience I had to search through reddit, read what are literally research papers and do the following: turn on gsync in a driver (obvious), turn off in-game vsync, turn on in-driver vsync (it does something!), set RTSS frame limiter to display’s MRR-3, and set up a schedule that frees “standby list” that also cause stutters. The reason is, many games don’t know about gsync and in-game “vsync on” messes with their input lag. But if a framerate hits MRR with gsync on, the driver falls back to vsync to prevent tearing, and so stutter. So frame limiter is required (idk how it works). I may misremember some details, but I’ve tested various settings, tried to deviate from the suggested path and realized that these articles were right about everything they say. How does this story relate to git? Nvidia could do this research itself and hide the complexity behind a simple switch. If a user turns on gsync, then make in-game vsync a noop or advise them to turn it off, do the shit that in-driver “vsync on” does, frame limit itself to MRR-3 and empty standby lists periodically while the game is running. Pretty sure git could do a similar thing for its users. And yes, most “consumer grade” players experience their adaptive sync technology to maybe about 30%. It’s still an improvement compared to vsync, ofc.
- buck4roo 4y ago
  When it comes to tools you use every day, everyone should be critical. Does this tool decrease my workload? or do I need to expend extra work just to operate it? I'm a user of mercurial. I've learned enough git to know it's an inferior tool. git's CLI complexity (and mental model) is patent overkill for 99.9% of all users. Mercurial gets out of my way. I'm able to clone and push git repos with it just fine (thanks hg-git!) This is because both (git,hg) are tools that manipulate the same simple data structure: the DAG. hg CLI's verbs match my mental model from decades of use of other VCS's. I'm able to perform my daily tasks with simplicity (including n-way merge/cherry-pick tasks that git "expert" colleagues often struggle with). My 2¢. I've used local (SCCS, RCS), client-server (CVS, subversion, perforce) and distributed (bazaar, git, hg)
- danaris 4y ago
  Git is a fundamentally different kind of tool than a video codec, and I don't think comparing them is particularly helpful. I agree that Git could be a bit more internally consistent, and have a few more convenience shortcuts for very basic usage. But I can also see a strong argument that, as part of the Linux ecosystem, that's a perfectly good opportunity for someone who wants to build a wrapper around Git (and I believe many have). It seems to me that unless you really only want to use Git in the most basic way possible (add all your changes every commit, never roll anything back, single branch, no stashes), understanding something of Git's internal model is less like understanding how the compiler's internals work, and more like understanding the fact that a C program needs to be compiled into object code and potentially linked into an executable before it can be run.

p-e-w 4y ago

Video codecs are also complex (actually, they are almost unimaginably complex). But I've never seen a smart TV telling the user something about "lapped transforms" or "chroma subsampling". I'm a user of Git. Why do I have to learn about implementation complexities in order to fix problems that arise from normal version control operations? I can't think of any other software that forces me to do this. Even compilers (at least those for mainstream programming languages) don't require me to understand their AST representation or other details of how they work internally.

taeric 4y ago
Televisions absolutely do this for power users. Or give them terrible image quality for regular users.
graypegg 4y ago
WildBit had a really cool project a while ago called Conveyor. [0] It’s a shame it never took off. It was built on git, but hid the complexity of branching + other git things behind “tasks”. You’d start a task, and silently push that branch out to everyone. It’d silently merge things in the background and handle a lot of the chores you have to do with git rebasing and such to keep branches mergeable. It failed miserably with us because it perpetually created impossible to solve git issues. Someone accidentally removes a gitignore file and commits a config file with a password? Your SOL. It will keep coming back because it will exist on at least one other person’s device which will get force pushed back to the repo. The weird plumbing exists because version control is hard, and prone to humans throwing wrenches into its nominally perfect system. The real reason you don’t remember every magic git incantation is because you normally only need a specific one, once a year. But it has to be there! [0] https://web.archive.org/web/20190226201600/https://conveyor.com/ https://web.archive.org/web/20190226201600/https://conveyor....
theamk 4y ago
TVs are consuming devices. If you are only wishing to consume git, you need to know "git clone" and "git checkout", and that's it, no need for internals. Or manybe not even that, you need to know where "download" link on Github interface is. If you are encoding video, you often need to know about chroma subsampling, and colorspaces, and fractional framerate and all the other absurd technical details. It is actually much worse than git. You can avoid those technical details if you use high-level software, only stay on happy path, and avoid any complex operations. You'll take longer and produce worse quality output than if you had fully mastered the software -- but often this is OK. This is true both for video encoding and for git.
- wruza 4y ago
  I have a gsync display and a cool graphics card. But to achieve the smoothest experience I had to search through reddit, read what are literally research papers and do the following: turn on gsync in a driver (obvious), turn off in-game vsync, turn on in-driver vsync (it does something!), set RTSS frame limiter to display’s MRR-3, and set up a schedule that frees “standby list” that also cause stutters. The reason is, many games don’t know about gsync and in-game “vsync on” messes with their input lag. But if a framerate hits MRR with gsync on, the driver falls back to vsync to prevent tearing, and so stutter. So frame limiter is required (idk how it works). I may misremember some details, but I’ve tested various settings, tried to deviate from the suggested path and realized that these articles were right about everything they say. How does this story relate to git? Nvidia could do this research itself and hide the complexity behind a simple switch. If a user turns on gsync, then make in-game vsync a noop or advise them to turn it off, do the shit that in-driver “vsync on” does, frame limit itself to MRR-3 and empty standby lists periodically while the game is running. Pretty sure git could do a similar thing for its users. And yes, most “consumer grade” players experience their adaptive sync technology to maybe about 30%. It’s still an improvement compared to vsync, ofc.
buck4roo 4y ago
When it comes to tools you use every day, everyone should be critical. Does this tool decrease my workload? or do I need to expend extra work just to operate it? I'm a user of mercurial. I've learned enough git to know it's an inferior tool. git's CLI complexity (and mental model) is patent overkill for 99.9% of all users. Mercurial gets out of my way. I'm able to clone and push git repos with it just fine (thanks hg-git!) This is because both (git,hg) are tools that manipulate the same simple data structure: the DAG. hg CLI's verbs match my mental model from decades of use of other VCS's. I'm able to perform my daily tasks with simplicity (including n-way merge/cherry-pick tasks that git "expert" colleagues often struggle with). My 2¢. I've used local (SCCS, RCS), client-server (CVS, subversion, perforce) and distributed (bazaar, git, hg)
danaris 4y ago
Git is a fundamentally different kind of tool than a video codec, and I don't think comparing them is particularly helpful. I agree that Git could be a bit more internally consistent, and have a few more convenience shortcuts for very basic usage. But I can also see a strong argument that, as part of the Linux ecosystem, that's a perfectly good opportunity for someone who wants to build a wrapper around Git (and I believe many have). It seems to me that unless you really only want to use Git in the most basic way possible (add all your changes every commit, never roll anything back, single branch, no stashes), understanding something of Git's internal model is less like understanding how the compiler's internals work, and more like understanding the fact that a C program needs to be compiled into object code and potentially linked into an executable before it can be run.