Every time I use Git, I see how bad the UX is and marvel at how it ever became popular.
Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can't figure out the arcane arts. I am one of those people, at times. Because it's faster to do so than read heaps of manpages for a situation I may never hit again.
Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.
>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.
I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.
Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.
To try and steelman this line - the CNCF (a major force behind k8s) has indeed been a game-changer for OSS. It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.
IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.
The introduction was indeed pretty cheesy. I read it and thought ‘I bet there will be a load of comments about the introduction instead of the article’ and then I read the rest of the article. Thankfully other comments did discuss the real content of the post.
This reads like a buzzword soup to me as well. All of the "ideas" presented are existing systems that author wants them in the source control software. Not sure why?
Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!
Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.
What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?
The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases.
The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files.
Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs).
There are strange warts (e.g. adding with --patch doesn't include files not in the index; displaying the content a given stash entry requires typing the whole - unnecessarily complex - entry name), which I don't doubt make sense technically, but from a user perspective, they're odd.
There's probably a lot of stuff that one can find, depending on how wide their usage is. For example, I actually didn't realize how convenient patched (--patch) unstaging would be, since I typically perform a reset, then add (--patch) again.
I've personally never got past the feeeling that, not frequently but still with some frequence, git operations have a byzantine UX.
edit: find the merge commit of a given commit is something also very missed; it requires a non-trivial alias.
Anything can become "fine" with enough practice and muscle memory. I'm a fairly advanced git user and manage to use it mostly painlessly even for relatively advanced tasks but I still think it's pretty crap overall. Not as crap as it was 15 years ago mind you, but not great.
I was a big proponent of Mercurial for a long time because I thought (and still think) that the UI and defaults were vastly superior for most projects which don't have the needs and workflow of the Linux kernel. I gave up a few years ago when it became clear that git was VHS to Hg's Betamax.
A decade of near daily use of it, as the 'git guy' on most teams I'm in, and I'm still spending time searching how to do specific things. To use a UX term, there's very few affordances telling me what I should expect, guiding my intuition.
Imagine a VCS where it was obvious and easy to figure out how to do anything that is possible. Along with all the power that git brings today.
My main complaint is it's leaking abstractions. You basically need a PhD in git's internal data structures to use git. Well not the 5% of git you typically need in your day-to-day, but the other 95%, which you need when the 5% you do need somehow goes wrong, through one of the many foot-guns git offers.
A concrete example: Accidentally pushing a merge you didn't want to push and now you're stuck staring git-revert(1) which has the sentence below, scratching your head like "uh, what's a parent number?"
-m parent-number, --mainline parent-number
Usually you cannot revert a merge because you do
not know which side of the merge should be
considered the mainline. This option specifies
the parent number (starting from 1) of the
mainline and allows revert to reverse the change
relative to the specified parent.
But you still can't find information about what a "parent number" is. It turns out, the parent number is the order they show up in within 'git show HASH'. Combining that clue with Linus Torvalds email above may let you undo the merge, if you can make sense of his Feynman diagrams. Maybe.
For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?
Same here. I am totally fine with git as it is. If I weren't I maybe would just try one of the hundreds git plugins / clients to see if it better fits my needs.
I'm seeing a number of points in the post that aren't so much about Git, but online collaboration software / websites or dependency / package management, too; I don't think git should fix those.
Actually I think you might be misunderstanding what people think is bad. Nobody dislikes the model of Git. It's great. That's partly why it's so popular.
It's the CLI and terminology that are the issue. Some things are very badly named (e.g. the "index"; anyone sane would call that the "draft") and the CLI is a complete mess. Remind me how you list submodules? Or delete a remote branch?
I do hear reasonable complaints here and there, such as the overuse of "checkout", but the majority of complaints I hear from new users fall into one of two categories. The first is complaining that git doesn't enforce a server/client model. The second is that git doesn't enforce a linear history. Both of these seem incredibly odd to me, as they are complaints about git accurately representing the development process.
For as little time I end up needing to use the actual UI i really don't see the issue. This isn't the first time someone has complained about it either.
Reminds me of the slightly facetious anecdote that UI/UX has actually already been perfected so the complaints and problems you hear are just UI/UX people making work for themselves.
Interactive rebases are what I use as well. They're such a terribly broken way to use Git. You can't even start an interactive rebase (to go back and update earlier commits in the stack) in the middle of another one.
> I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.
Perhaps it's what you want something easier than, but I have `uncommit` aliased to `reset HEAD^`, and use it often as `git uncommit -p` (then amend, then the 'uncommitted' changes are unstaged ready to go in a different commit if they were wanted just elsewhere, or removed if not).
I think a git CLI is an elegant and orthogonal and maps pretty much semantically to basic commit graph operations. It clicked when I started to think in terms of graph transformations and what graph state I want at the end.
> I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.
IMHO this one of the cases when GUI is better. I use `tig`.
Got another here with what seems to be a unique anecdote: In the early 2010s, with only svn knowledge, I tried out both git and mercurial. I don't remember the details from back then, so I couldn't explain why, but I do remember thinking mercurial was confusing and git was easy to understand.
The model's basically a directed acyclic graph (not a tree), with each edge being the diff between the two nodes it connects. I think the UX could be improved if it built on the language of graphs to make that model more apparent - node, edge, etc.
(I also believe the same thing about SQL and sets).
I agree with you. Adding new well-thought commands while keeping the old more arcane syntax would be enough for me (like git switch, git restore, git create-branch instead of git checkout -b, etc.).
This way new users will find it better to learn and people familiar with it don't need to change it.
My favorite thing about git ux is the clarity. People often criticize saying I don't understand what to do and how. I do not agree. I think it is quite fun to use when you are aware that there is a history that you manage at the top, no matter what you are working on.
My complaint is that the names of commands in Git are not intuitive. Otherwise, I think the UX lf Git is near perfect because it's possible to write things like Git graphical wrappers.
I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even see blob diffs. which is quite opinionated on when it collapses a file in the PR, and how it determines what changed in a file). I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email, but there's a lot more boilerplate+blob data that goes into git today and git needs to evolve to support this.
I feel that once tools like Difftastic [1] and similar get more mainstream, and ideally more firmly entrenched within git itself, it will make code reviewing much smoother process rather than having to depend on Github or any other proprietary service.
I've been using fossil (https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are -
1. Single file executable. No dependencies to "install". Just the executable and you're good.
2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc.
3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me.
4. Integrated issue tracker stored in the same repo. Complete with cross references to commits.
5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as "published" and later look at the whole history of all previous commits tagged as "published".
Other niceties -
1. Integrated wiki - I've occasionally used it, but usually prefer to write documentation in separate files.
2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning.
3. Can export and import to/from git.
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it.
Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).
> Atomicity accross projects
Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.
> Package management
Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
> Semantic diff
This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
> Merge queue data structure
The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.
> Fan-out pull requests
Github is not Git.
> git should be fully decoupled from the pull request and merge workflow
Oh dear. Where is Drew Devault...
> lfs
The first good point they've made
> fossil
Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.
> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work.
The only major problem I see with Git is that it's just a pain if you're working in a gigantic monorepo.
Outside of this, I think it's achieved it's ultimate form and tradeoffs for what it was originally intended to do - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn't need to 'change' architecturally or philosophically to accommodate other things.
Separate version control software can be designed for solving a specific problem - but I don't think Git should need to evolve beyond the problems it's designed to take on.
The project management features don’t have to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red/green results at integration time.
A project should encapsulate the code, how we got there, what we changed, and why we changed it.
The code is your HEAD, available as a working copy. How we got there is the stack of diffs that, when applied to an empty repository, accumulate to being the current HEAD. What we changed is more nuanced that just the diffs: It’s the commit messages explaining the diffs and adding context. If the diff changes an algorithm from n^2 to n then what we changed is the runtime complexity of x, which is good for reasons y and z.
Why we changed it is the bit that’s missing. Was this work originally from a bug report? Did real-life-n stay small for our first six months and has all of a sudden become much bigger? Who was involved in deciding this was the right thing to do, what did they say, and what other approaches did we think about? Which cat meme was deemed appropriate for the final approval of the change?
Right now, that stuff is all linked to from git but it’s not really a part of the workflow unless you remain inside GitHub’s or GitLab’s ecosystems. Seeing that in the underlying tool would be really cool.
Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we'll have the scaling sorted too.
Commits are automatically "branches" off trunk. You typically do 1:1, commit:PR. As you make new changes to the same PR, you `hg amend` instead of another commit. Those commits get merged into trunk.
My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots.
That's why I am exited for tools like Pijul that attempt to actually track changes.
The post just loses credibility after this statement. Yes, Kubernetes is important, but "operating system" is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.
Yes, and it matches the definition of an "operating system".
Originally, an "operating system" is a system that takes the role of an operator. In the early days, operators were people who loaded programs, feed them data, fetched the results, etc... for the users. Matching the modern definition of an interface between the user and hardware.
Kubernetes allocate servers (hardware) to containers just like a typical OS allocate CPU and memory to processes. And it stands between the user (here, the sysadmin) and the hardware (the servers). "Operating system of the cloud" is, I think, a good description of Kubernetes.
I like the patch-based approach of Pijul and Darcs: rearranging patches seems less fragile than rebasing snapshots.
I'd like to see git's content-based more integrated into projects like IPFS (and for IPFS to get their resource-usage down, so it can be run as a background task on my laptop!)
As for package management, Git and Nix work really well together: e.g. we can use `builtins.fetchGit` to fetch particular commits; and we can `import` Nix definitions from those git commits; and those definitions can fetch other repos, etc. so we get a Merkle tree of the exact code used by all of our dependencies. I also like to write commit IDs as default function arguments, which makes it easy to override any of these dependencies to use another commit.
> Previously, I was a software engineer working on open-source Kubernetes at Google, building and maintaining Kubernetes developer tools such as minikube and skaffold
My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control.
You better get it right, or otherwise you get to nuke the whole repository.
[+] [-] silisili|3 years ago|reply
Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can't figure out the arcane arts. I am one of those people, at times. Because it's faster to do so than read heaps of manpages for a situation I may never hit again.
Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.
[+] [-] mpermar|3 years ago|reply
I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.
Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.
[+] [-] superb-owl|3 years ago|reply
IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.
[+] [-] dan-robertson|3 years ago|reply
[+] [-] msoad|3 years ago|reply
Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!
[+] [-] skratlo|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Semiapies|3 years ago|reply
[+] [-] nailer|3 years ago|reply
It references the effort and money wasted by people that wanted to build cloud providers despite not being in the business of being a cloud provider.
[+] [-] pdmccormick|3 years ago|reply
What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?
[+] [-] pizza234|3 years ago|reply
The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files.
Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs).
There are strange warts (e.g. adding with --patch doesn't include files not in the index; displaying the content a given stash entry requires typing the whole - unnecessarily complex - entry name), which I don't doubt make sense technically, but from a user perspective, they're odd.
There's probably a lot of stuff that one can find, depending on how wide their usage is. For example, I actually didn't realize how convenient patched (--patch) unstaging would be, since I typically perform a reset, then add (--patch) again.
I've personally never got past the feeeling that, not frequently but still with some frequence, git operations have a byzantine UX.
edit: find the merge commit of a given commit is something also very missed; it requires a non-trivial alias.
[+] [-] simias|3 years ago|reply
I was a big proponent of Mercurial for a long time because I thought (and still think) that the UI and defaults were vastly superior for most projects which don't have the needs and workflow of the Linux kernel. I gave up a few years ago when it became clear that git was VHS to Hg's Betamax.
[+] [-] mabbo|3 years ago|reply
A decade of near daily use of it, as the 'git guy' on most teams I'm in, and I'm still spending time searching how to do specific things. To use a UX term, there's very few affordances telling me what I should expect, guiding my intuition.
Imagine a VCS where it was obvious and easy to figure out how to do anything that is possible. Along with all the power that git brings today.
[+] [-] marginalia_nu|3 years ago|reply
A concrete example: Accidentally pushing a merge you didn't want to push and now you're stuck staring git-revert(1) which has the sentence below, scratching your head like "uh, what's a parent number?"
Maybe you google a bit, and find this: https://www.christianengvall.se/undo-pushed-merge-git/ ... which explains a bit, but is still confusing as all hell. The rabbit hole continues to this: https://opensource.apple.com/source/Git/Git-26/src/git-htmld... which is also... not really clear.But you still can't find information about what a "parent number" is. It turns out, the parent number is the order they show up in within 'git show HASH'. Combining that clue with Linus Torvalds email above may let you undo the merge, if you can make sense of his Feynman diagrams. Maybe.
[+] [-] krageon|3 years ago|reply
No, I think most people that use it are fine with it. But those are usually not the ones you hear :)
[+] [-] R0flcopt3r|3 years ago|reply
[+] [-] herbst|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
[+] [-] IshKebab|3 years ago|reply
Actually I think you might be misunderstanding what people think is bad. Nobody dislikes the model of Git. It's great. That's partly why it's so popular.
It's the CLI and terminology that are the issue. Some things are very badly named (e.g. the "index"; anyone sane would call that the "draft") and the CLI is a complete mess. Remind me how you list submodules? Or delete a remote branch?
[+] [-] MereInterest|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] prettyStandard|3 years ago|reply
1. Make a new commit to revert what you to come last
2. Make a new commit to revert what you want to come first
3. Make a new commit to restore/revert line 2 above
4. Make a new commit to restore/revert line 1 above
5. Squash original into lines 1 & 2 above
Alternatively you can use interactive rebase, 1. set edit on the commit you want to split
2. When the rebase stops, `git reset --soft HEAD~1` (I think)
3. `git add` and commit as necessary then follow up with git rebase --continue
[+] [-] bilekas|3 years ago|reply
Reminds me of the slightly facetious anecdote that UI/UX has actually already been perfected so the complaints and problems you hear are just UI/UX people making work for themselves.
[+] [-] howinteresting|3 years ago|reply
[+] [-] tasuki|3 years ago|reply
[+] [-] OJFord|3 years ago|reply
Perhaps it's what you want something easier than, but I have `uncommit` aliased to `reset HEAD^`, and use it often as `git uncommit -p` (then amend, then the 'uncommitted' changes are unstaged ready to go in a different commit if they were wanted just elsewhere, or removed if not).
[+] [-] bvrmn|3 years ago|reply
> I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.
IMHO this one of the cases when GUI is better. I use `tig`.
[+] [-] Izkata|3 years ago|reply
[+] [-] flir|3 years ago|reply
(I also believe the same thing about SQL and sets).
[+] [-] mejutoco|3 years ago|reply
This way new users will find it better to learn and people familiar with it don't need to change it.
[+] [-] newbieuser|3 years ago|reply
[+] [-] JoeyBananas|3 years ago|reply
[+] [-] madmax108|3 years ago|reply
I feel that once tools like Difftastic [1] and similar get more mainstream, and ideally more firmly entrenched within git itself, it will make code reviewing much smoother process rather than having to depend on Github or any other proprietary service.
[1] https://github.com/Wilfred/difftastic
[+] [-] sriku|3 years ago|reply
1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me. 4. Integrated issue tracker stored in the same repo. Complete with cross references to commits. 5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as "published" and later look at the whole history of all previous commits tagged as "published".
Other niceties -
1. Integrated wiki - I've occasionally used it, but usually prefer to write documentation in separate files. 2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning. 3. Can export and import to/from git.
[+] [-] tedk-42|3 years ago|reply
If you think you can do it better then go ahead and try build the product and then pitch it.
[+] [-] alenmilk|3 years ago|reply
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
[+] [-] lucideer|3 years ago|reply
Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).
> Atomicity accross projects
Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.
> Package management
Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
> Semantic diff
This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
> Merge queue data structure
The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.
> Fan-out pull requests
Github is not Git.
> git should be fully decoupled from the pull request and merge workflow
Oh dear. Where is Drew Devault...
> lfs
The first good point they've made
> fossil
Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.
[+] [-] leeoniya|3 years ago|reply
in case anyone missed it: https://github.com/Wilfred/difftastic
[+] [-] knighthack|3 years ago|reply
Outside of this, I think it's achieved it's ultimate form and tradeoffs for what it was originally intended to do - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn't need to 'change' architecturally or philosophically to accommodate other things.
Separate version control software can be designed for solving a specific problem - but I don't think Git should need to evolve beyond the problems it's designed to take on.
[+] [-] gorgoiler|3 years ago|reply
A project should encapsulate the code, how we got there, what we changed, and why we changed it.
The code is your HEAD, available as a working copy. How we got there is the stack of diffs that, when applied to an empty repository, accumulate to being the current HEAD. What we changed is more nuanced that just the diffs: It’s the commit messages explaining the diffs and adding context. If the diff changes an algorithm from n^2 to n then what we changed is the runtime complexity of x, which is good for reasons y and z.
Why we changed it is the bit that’s missing. Was this work originally from a bug report? Did real-life-n stay small for our first six months and has all of a sudden become much bigger? Who was involved in deciding this was the right thing to do, what did they say, and what other approaches did we think about? Which cat meme was deemed appropriate for the final approval of the change?
Right now, that stuff is all linked to from git but it’s not really a part of the workflow unless you remain inside GitHub’s or GitLab’s ecosystems. Seeing that in the underlying tool would be really cool.
[+] [-] coxley|3 years ago|reply
Commits are automatically "branches" off trunk. You typically do 1:1, commit:PR. As you make new changes to the same PR, you `hg amend` instead of another commit. Those commits get merged into trunk.
[+] [-] ribit|3 years ago|reply
That's why I am exited for tools like Pijul that attempt to actually track changes.
[+] [-] i_have_an_idea|3 years ago|reply
The post just loses credibility after this statement. Yes, Kubernetes is important, but "operating system" is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.
[+] [-] GuB-42|3 years ago|reply
Originally, an "operating system" is a system that takes the role of an operator. In the early days, operators were people who loaded programs, feed them data, fetched the results, etc... for the users. Matching the modern definition of an interface between the user and hardware.
Kubernetes allocate servers (hardware) to containers just like a typical OS allocate CPU and memory to processes. And it stands between the user (here, the sysadmin) and the hardware (the servers). "Operating system of the cloud" is, I think, a good description of Kubernetes.
[+] [-] stellalo|3 years ago|reply
What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious
[+] [-] chriswarbo|3 years ago|reply
I'd like to see git's content-based more integrated into projects like IPFS (and for IPFS to get their resource-usage down, so it can be run as a background task on my laptop!)
As for package management, Git and Nix work really well together: e.g. we can use `builtins.fetchGit` to fetch particular commits; and we can `import` Nix definitions from those git commits; and those definitions can fetch other repos, etc. so we get a Merkle tree of the exact code used by all of our dependencies. I also like to write commit IDs as default function arguments, which makes it easy to override any of these dependencies to use another commit.
[+] [-] pgt|3 years ago|reply
[+] [-] Xenoamorphous|3 years ago|reply
Never seen it described like that.
> Previously, I was a software engineer working on open-source Kubernetes at Google, building and maintaining Kubernetes developer tools such as minikube and skaffold
Ah!
[+] [-] torginus|3 years ago|reply
You better get it right, or otherwise you get to nuke the whole repository.
[+] [-] zambal|3 years ago|reply
The article could have been interesting if the author actually expanded on what these pain points are. I'm genuinely curious about those.