8 ms·

I wish we had a version control system that can be used without worrying, or even knowing, about its technicalities and implementation details. Working with Gi

by p-e-w 4y ago

I wish we had a version control system that can be used without worrying, or even knowing, about its technicalities and implementation details. Working with Git for version control is as if your photo management tool required you to learn about inodes and b-tree superblocks in order to save a JPEG file. I just want to keep source code history, and allow multiple people to collaborate on the same project. I don't want to know anything about "refs" or whatever else is happening behind the scenes, yet it appears Git can't be used unless you are (at least occasionally) willing to look at the plumbing layer.

cratermoon 4y ago
If there's a UI, or even a CLI, that properly matches the conceptual model of development with git, I'm not aware of it. I'm sure there's a much clearer user-centric model of work struggling to get out from underneath the implementation details. Over the years of working with git I've gradually learned bits of the plumbing underneath the porcelain, but reluctantly.
graypegg 4y ago
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.
rjbwork 4y ago
We do, at least to my mind. It's called Mercurial. It's great, extremely close to git, but is much easier to use IMO. It's really a damn shame that git won - primarily, I think, due to the cachet of its author.
- dilyevsky 4y ago
  The way I remember it git one for two reasons: 1. hg was (maybe still is?) much slower 2. “No technology can ever be too arcane or complicated for the black t-shirt crowd” (fake Linus’s words not mine)
  - gregjor 4y ago
    I think you’re quoting me. Thanks! https://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git https://typicalprogrammer.com/linus-torvalds-goes-off-on-lin...
- bigDinosaur 4y ago
  Either way, is Git actually that hard to use? You can learn about 10 commands and develop any software just with those. I have no illusions about it's gnarly aspects but also just don't find it particularly difficult. Contrast a programming language that might have footguns in just printing strings.
  - photonbeam 4y ago
    Git is a pain to provide support for if you’re an internal tools team, lots of users with incorrect mental models
- shanev 4y ago
  Close. It won because of Github. Git was gaining over SVN slowly but it was Github that really propelled it into widespread use.
Agentlien 4y ago
Why do you feel you need to know these details? I used git actively without issues for years before I took the time to learn how it works under the hood. While understanding the details was fun and helpful, I can't say it really changed much about how I use the tool.
bad_username 4y ago
Linus built an incredibly elegant and simple underlying model for git. For what it successfully does - distributed version control - it is remarkably simple and easy to grasp if you want to. However, this model was not mapped well to the high level concepts that the typical user of a VCS operates in. This is the biggest issue of git: it's hard to make sense of it by its UI if you do not understand how it works under the hood. I struggled until I read the pro git book. I wouldn't go as far as to compare this to knowing about filesystem data structures for saving a jpeg file. It's more like using an old school file dialog where you just see the bare file system and you need to know your way around your drive.
- josephg 4y ago
  Git's other (compounding) problem is how the CLI is an inconsistent mess. Why do you create a branch via the "git checkout" command? Why do you delete tags using "git tag -d" but delete stashes using "git stash drop"? If you want to blow away local uncommitted changes, you can use "git reset", "git reset --hard" or "git checkout (file)" - which (I think) all do totally different things. Git's data model may be elegant, but its hard to appreciate it through the tangled mess of git command line options.
  - Nadya 4y ago
    I use Git daily and literally couldn't tell you how to use it because I've aliased every single command it has. I basically have a wrapper over it and to teach anyone how to use Git I have to peel my layer away and check what I have things aliased to. It feels like terrible ad hoc user design built over an otherwise extremely elegant and clean data model.
    - freetonik 4y ago
      Would you mind sharing your aliases? Curious to see a different mental model.
  - amadvance 4y ago
    They tried to fix that mess, like with the recent git switch/restore. But it looks like it was too late.
taeric 4y ago
You've clearly never tried to save raw image files from a mid level camera. :) heaven help you if you try a newer camera than your os. I will make no major defense of git, but I am intrigued at the level of difficulty reported about it, compared to the obviously higher level of use that it gets.
- ansgri 4y ago
  What kind of cameras and difficulties are you talking about? It’s almost always just a DCIM folder on the sd card. Videos, OTOH, are stored rather arcanely, at least on my Sony, with separate directory structure for each format.
  - taeric 4y ago
    Newer cameras have had raw formats that were not supported right away. Cr3 being the one that bit me recently. I think most software has caught up. But it did catch me off guard that my machine needed updating to support this. I also think flatpak had some trouble with it. Can't remember details.
    - ansgri 4y ago
      Ah, you're talking about actually using them, not just saving :)
      - taeric 4y ago
        Little of both. Took me a few tries to get them recognized as pictures. Rather frustrating experience, all told.
seba_dos1 4y ago
"refs" are not behind-the-scenes things, they're the things you want to operate on. It wouldn't be like having to learn JPEG superblocks, it's more like learning what a pixel is. You need to understand Git's data model, not its plumbing. No VCS will be useful for anything that isn't trivial if you don't understand its data model.
- Gunax 4y ago
  I disagree. We shouldn't have to know how a branch or commit is stored. Whether git interally makes a new ref, copies everything to a new directory, or does some hashing magic doesn't matter to the user. I agree that we end up needing to know about refs because of git's user interface, but I consider that a flaw or limitation.
  - seba_dos1 4y ago
    It's not about "how a branch is stored". We're not talking about objects, packs, blobs or any other stuff I never actually had to learn about while using git. We're talking about refs - the primary way for users to reference commits and other things in git. Just about every command you use takes refs as arguments. It's essential to even just imagine the state of the repository in your head. It's what the first tutorial you read about git should explain to you.
aaronbrethorst 4y ago
There's something funny to me about the idea that the user-level Git commands are called the "porcelain," as if they were a toilet. https://stackoverflow.com/a/6976506 https://stackoverflow.com/a/6976506 unrelated: I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. Wrap that blog content with a <div style='max-width: 65ch'>
- thiht 4y ago
  > I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. There's a noticeable portion of tech people who seem to believe that unused screen space is somehow wasted. No margins + no line breaks is the gold standard to them. I don't get it, it's unreadable to me.
  - phist_mcgee 4y ago
    Dan Luu is famous for this. I can barely read the page it's so harsh. eg. https://danluu.com/futurist-predictions/ https://danluu.com/futurist-predictions/
- drdec 4y ago
  You don't have to run your browser maximized you know
  - aaronbrethorst 4y ago
    Please tell me about how you will replace me with a very small shell script next.
  - phist_mcgee 4y ago
    Telling someone to change their workflow because a website refuses to deal with larger screen sizes is silly.
    - 4y ago
thunderbong 4y ago
That's why we use fossil [0]. It just gets out of the way. It has its own server, wiki, ticket system and now, even chat! The main complaint I see here is that it doesn't have rebase, and my point is the goal of the code is for the product to work, not to have a beautiful commit graph. I've used CVS, SVN, Git. But nothing comes close to the usability that fossil provides. [0]: https://www.fossil-scm.org/ https://www.fossil-scm.org/
- vbezhenar 4y ago
  Beatiful commit graph allows to actually understand commit history. I dread opening history with merges. It's always incomprehensible mess for me.
somat 4y ago
I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is. fossil init repo; make a new fossil repository fossil open repo; open a fossil repository somewhere fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction. fossil commit There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"
- KRAKRISMOTT 4y ago
  The bad thing is that fossil allows the upstream to make destructive changes to client's copy of code. That's a big no no.
  - owyn 4y ago
    Until you need it. :)
  - somat 4y ago
    So does git, in fact, without a better explanation of what exactly you mean, I would say upstream making changes to the the clients code is the core useful property of a version control system.
- osigurdson 4y ago
  git init . git add file git commit -am "my message" Pretty simple really. You don't need to think about staging if you don't want to.
  - dataflow 4y ago
kaba0 4y ago
People mention previous gen version control systems in sibling comments, but git quite clearly “won” against them. A more useful outlook would be looking for what the next gen VSC might be, which would be Pijul and alia (where diffs/patches are applicable in any order, so merges will be trivial, no more merge strategies), and if they do get production ready they might really provide a better UX/more intuitive mental model for the programmer.
ozim 4y ago
My view on it is that unfortunately there is no way to do that. Some things are going to be hard and that is it, you cannot make it easier. We see that in never ending stream of frameworks or "new/better/easier" ways which in the end become bloated in the same ways as most other stuff because problems don't go away if you don't know about them. In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.
- comfypotato 4y ago
  I always feel that complaints like the one you’re replying to aren’t thought through. The simple follow up is: how would you do it better? There’s no better way. You only need to look at the complicated part of git for very complicated things. If you think about it, commits and branches are incredibly simple relative to what’s actually happening (when it comes to working with them, that is). Listening to old folks talk about pre-git version control gives me appreciation for just how good it is.
  - OkayPhysicist 4y ago
    There are a few fixes I would make, but only a handful would be significant to everyday usage, none would involve fundamentally changing the underlying data model. The biggest would probably be to make all commits required to be made onto branches and either embed the data of what branch created a commit into the commit itself, or have a separate data store of branch-to-commit info, which would allow for "branches as a series of commits" to be a first class citizen besides "branches as references to a commit". Maybe add git notes-esque support for editable metadata on the branch, where you could put information that currently would be stored in some pull request management system.
    - comfypotato 4y ago
      The data regarding what branch a commit was made is available. It’s all available if you dig deep enough. What you’re talking about sounds like the work of a git visualization tool made for fixing problems. I do love a repo viz where I can see the tree of branches for helping me understand where something went wrong. The surface level stuff people use day to day is as simple as it needs to be.
xorcist 4y ago
All abstractions leak. You cannot work your jpeg photo collection but opening, editing, saving, editing, saving, editing, saving and then blame your tools when your jpegs are blocky and ugly. First you have to know some basics about lossy compressing and destructive editing. Then, you can understand what steps you really want to take. It's the same with version control systems. With git, first you have to understand what a commit and a branch is. Then, you can work.
OkayPhysicist 4y ago
It's version control for software developers, who simultaneously need all the power it provides, and ought to have the educational background to understand directed acyclic graphs. Complaining that git is too complicated because it requires basic knowledge of DAGs is like complaining that your word processor is too complicated because it assumes a proficiency in written language.

by p-e-w 4y ago

cratermoon 4y ago

If there's a UI, or even a CLI, that properly matches the conceptual model of development with git, I'm not aware of it. I'm sure there's a much clearer user-centric model of work struggling to get out from underneath the implementation details. Over the years of working with git I've gradually learned bits of the plumbing underneath the porcelain, but reluctantly.

graypegg 4y ago

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.

rjbwork 4y ago

We do, at least to my mind. It's called Mercurial. It's great, extremely close to git, but is much easier to use IMO. It's really a damn shame that git won - primarily, I think, due to the cachet of its author.

dilyevsky 4y ago
The way I remember it git one for two reasons: 1. hg was (maybe still is?) much slower 2. “No technology can ever be too arcane or complicated for the black t-shirt crowd” (fake Linus’s words not mine)
- gregjor 4y ago
  I think you’re quoting me. Thanks! https://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git https://typicalprogrammer.com/linus-torvalds-goes-off-on-lin...
bigDinosaur 4y ago
Either way, is Git actually that hard to use? You can learn about 10 commands and develop any software just with those. I have no illusions about it's gnarly aspects but also just don't find it particularly difficult. Contrast a programming language that might have footguns in just printing strings.
- photonbeam 4y ago
  Git is a pain to provide support for if you’re an internal tools team, lots of users with incorrect mental models
shanev 4y ago
Close. It won because of Github. Git was gaining over SVN slowly but it was Github that really propelled it into widespread use.

Agentlien 4y ago

Why do you feel you need to know these details? I used git actively without issues for years before I took the time to learn how it works under the hood. While understanding the details was fun and helpful, I can't say it really changed much about how I use the tool.

bad_username 4y ago

Linus built an incredibly elegant and simple underlying model for git. For what it successfully does - distributed version control - it is remarkably simple and easy to grasp if you want to. However, this model was not mapped well to the high level concepts that the typical user of a VCS operates in. This is the biggest issue of git: it's hard to make sense of it by its UI if you do not understand how it works under the hood. I struggled until I read the pro git book. I wouldn't go as far as to compare this to knowing about filesystem data structures for saving a jpeg file. It's more like using an old school file dialog where you just see the bare file system and you need to know your way around your drive.

josephg 4y ago
Git's other (compounding) problem is how the CLI is an inconsistent mess. Why do you create a branch via the "git checkout" command? Why do you delete tags using "git tag -d" but delete stashes using "git stash drop"? If you want to blow away local uncommitted changes, you can use "git reset", "git reset --hard" or "git checkout (file)" - which (I think) all do totally different things. Git's data model may be elegant, but its hard to appreciate it through the tangled mess of git command line options.
- Nadya 4y ago
  I use Git daily and literally couldn't tell you how to use it because I've aliased every single command it has. I basically have a wrapper over it and to teach anyone how to use Git I have to peel my layer away and check what I have things aliased to. It feels like terrible ad hoc user design built over an otherwise extremely elegant and clean data model.
  - freetonik 4y ago
    Would you mind sharing your aliases? Curious to see a different mental model.
- amadvance 4y ago
  They tried to fix that mess, like with the recent git switch/restore. But it looks like it was too late.

taeric 4y ago

You've clearly never tried to save raw image files from a mid level camera. :) heaven help you if you try a newer camera than your os. I will make no major defense of git, but I am intrigued at the level of difficulty reported about it, compared to the obviously higher level of use that it gets.

ansgri 4y ago
What kind of cameras and difficulties are you talking about? It’s almost always just a DCIM folder on the sd card. Videos, OTOH, are stored rather arcanely, at least on my Sony, with separate directory structure for each format.
- taeric 4y ago
  Newer cameras have had raw formats that were not supported right away. Cr3 being the one that bit me recently. I think most software has caught up. But it did catch me off guard that my machine needed updating to support this. I also think flatpak had some trouble with it. Can't remember details.
  - ansgri 4y ago
    Ah, you're talking about actually using them, not just saving :)
    - taeric 4y ago
      Little of both. Took me a few tries to get them recognized as pictures. Rather frustrating experience, all told.

seba_dos1 4y ago

"refs" are not behind-the-scenes things, they're the things you want to operate on. It wouldn't be like having to learn JPEG superblocks, it's more like learning what a pixel is. You need to understand Git's data model, not its plumbing. No VCS will be useful for anything that isn't trivial if you don't understand its data model.

Gunax 4y ago
I disagree. We shouldn't have to know how a branch or commit is stored. Whether git interally makes a new ref, copies everything to a new directory, or does some hashing magic doesn't matter to the user. I agree that we end up needing to know about refs because of git's user interface, but I consider that a flaw or limitation.
- seba_dos1 4y ago
  It's not about "how a branch is stored". We're not talking about objects, packs, blobs or any other stuff I never actually had to learn about while using git. We're talking about refs - the primary way for users to reference commits and other things in git. Just about every command you use takes refs as arguments. It's essential to even just imagine the state of the repository in your head. It's what the first tutorial you read about git should explain to you.

aaronbrethorst 4y ago

There's something funny to me about the idea that the user-level Git commands are called the "porcelain," as if they were a toilet. https://stackoverflow.com/a/6976506 https://stackoverflow.com/a/6976506 unrelated: I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. Wrap that blog content with a <div style='max-width: 65ch'>

thiht 4y ago
> I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. There's a noticeable portion of tech people who seem to believe that unused screen space is somehow wasted. No margins + no line breaks is the gold standard to them. I don't get it, it's unreadable to me.
- phist_mcgee 4y ago
  Dan Luu is famous for this. I can barely read the page it's so harsh. eg. https://danluu.com/futurist-predictions/ https://danluu.com/futurist-predictions/
drdec 4y ago
You don't have to run your browser maximized you know
- aaronbrethorst 4y ago
  Please tell me about how you will replace me with a very small shell script next.
- phist_mcgee 4y ago
  Telling someone to change their workflow because a website refuses to deal with larger screen sizes is silly.
  - 4y ago

thunderbong 4y ago

That's why we use fossil [0]. It just gets out of the way. It has its own server, wiki, ticket system and now, even chat! The main complaint I see here is that it doesn't have rebase, and my point is the goal of the code is for the product to work, not to have a beautiful commit graph. I've used CVS, SVN, Git. But nothing comes close to the usability that fossil provides. [0]: https://www.fossil-scm.org/ https://www.fossil-scm.org/

vbezhenar 4y ago
Beatiful commit graph allows to actually understand commit history. I dread opening history with merges. It's always incomprehensible mess for me.

somat 4y ago

I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is. fossil init repo; make a new fossil repository fossil open repo; open a fossil repository somewhere fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction. fossil commit There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"

KRAKRISMOTT 4y ago
The bad thing is that fossil allows the upstream to make destructive changes to client's copy of code. That's a big no no.
- owyn 4y ago
  Until you need it. :)
- somat 4y ago
  So does git, in fact, without a better explanation of what exactly you mean, I would say upstream making changes to the the clients code is the core useful property of a version control system.
osigurdson 4y ago
git init . git add file git commit -am "my message" Pretty simple really. You don't need to think about staging if you don't want to.
- dataflow 4y ago

kaba0 4y ago

People mention previous gen version control systems in sibling comments, but git quite clearly “won” against them. A more useful outlook would be looking for what the next gen VSC might be, which would be Pijul and alia (where diffs/patches are applicable in any order, so merges will be trivial, no more merge strategies), and if they do get production ready they might really provide a better UX/more intuitive mental model for the programmer.

ozim 4y ago

My view on it is that unfortunately there is no way to do that. Some things are going to be hard and that is it, you cannot make it easier. We see that in never ending stream of frameworks or "new/better/easier" ways which in the end become bloated in the same ways as most other stuff because problems don't go away if you don't know about them. In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.

comfypotato 4y ago
I always feel that complaints like the one you’re replying to aren’t thought through. The simple follow up is: how would you do it better? There’s no better way. You only need to look at the complicated part of git for very complicated things. If you think about it, commits and branches are incredibly simple relative to what’s actually happening (when it comes to working with them, that is). Listening to old folks talk about pre-git version control gives me appreciation for just how good it is.
- OkayPhysicist 4y ago
  There are a few fixes I would make, but only a handful would be significant to everyday usage, none would involve fundamentally changing the underlying data model. The biggest would probably be to make all commits required to be made onto branches and either embed the data of what branch created a commit into the commit itself, or have a separate data store of branch-to-commit info, which would allow for "branches as a series of commits" to be a first class citizen besides "branches as references to a commit". Maybe add git notes-esque support for editable metadata on the branch, where you could put information that currently would be stored in some pull request management system.
  - comfypotato 4y ago
    The data regarding what branch a commit was made is available. It’s all available if you dig deep enough. What you’re talking about sounds like the work of a git visualization tool made for fixing problems. I do love a repo viz where I can see the tree of branches for helping me understand where something went wrong. The surface level stuff people use day to day is as simple as it needs to be.

xorcist 4y ago

All abstractions leak. You cannot work your jpeg photo collection but opening, editing, saving, editing, saving, editing, saving and then blame your tools when your jpegs are blocky and ugly. First you have to know some basics about lossy compressing and destructive editing. Then, you can understand what steps you really want to take. It's the same with version control systems. With git, first you have to understand what a commit and a branch is. Then, you can work.

OkayPhysicist 4y ago

It's version control for software developers, who simultaneously need all the power it provides, and ought to have the educational background to understand directed acyclic graphs. Complaining that git is too complicated because it requires basic knowledge of DAGs is like complaining that your word processor is too complicated because it assumes a proficiency in written language.