I hereby am foolish enough to predict that in 5 years for now, we will see a new tool for version control, let's call it hju, that will attract mil...
For further actions, you may consider blocking this person and/or reporting abuse
squashing should never be the default in my opinion. we can squash, edit, pick and edit locally, but to me it is one of the misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.
Another misfeature of current version control is rather a shortcoming of the default diff algorithms, producing too many "changes" and "conflicts" like when two different additions have been made to the same file, or when indentation changed so that editing two lines produces pseudo-change noise of any nested lines. This might also be the main reason making it so painful and dangerous to rebase in complex projects.
Good idea for hju: forcing developers to make small pull requests (following the principle of trunk based development) but how exactly would we force fellow developers to do so?
Completely agree with your second paragraph.
That's just my opinion but I think long descriptions should go in the issue trackers, pull requests discussion, company wikis. Easier to update. Easier find after the fact. But not in the git descriptions. For documentation, being immutable is an anti-feature.
Git didn't have an issue tracker, because the Linux developers already did those things by email, so for them the long detailed descriptions in the git messages made total sense.
Not forcing but nudging.
Nudging by making squashing the default.
You can only squash pull requests that are focused on one thing.
That's a useful friction here.
I think you could have a websocket write conflicts into a separate adjacent file dynamically. Then it’s a little like Google docs if everybody detects and aligns changes immediately.
If 2 people can’t immediately align their local changes, it surfaces a disagreement or lack of understanding. It might be a disagreement about something petty though. Everything comes with a trade off.
@jmfayard @ingosteinke
Your comment reminded me that git (and hju) is by default the wrong choice for documentation.
We overuse it because we know git, but frankly pause and reflect the next time you want to do that.
Basically Wikipedia is the proven method for collaborating on documentation.
Git is the newer kid that does it worse and add tons of overhead.
You can have counter examples like a static blog where you are the only one and commit on main and need to use a CI. Ok then that's fine.
But in general documentation is a completely different use case than software.
Think about those 420 awesome-something github repositories that could have been one wiki instead.
You don't need a global history of commits that span multiple files.
You need multiple histories, one per file, that are mostly independant
(just make sure to support renaming).
Most importantly, for documentation you want to remove the gatekeepers that nitpick your pr.
The inventor of the wiki correctly stated that it was inefficient because "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
I agree with this. For work, I put one link to the wiki location in the git readme and call it good.
I fully agree. I have found that all supporters of squash commits either create so low quality patches that keeping commits separate just adds noise or they want to use some tools that cannot handle anything more complex but a single commit (e.g. Gerrit?).
I find that never using squash but rebasing feature branches is much much better in long run. Yes, I might combine some patches in the process to create easier to understand history but never squash everything without thinking.
And i always find it funny when software developers complain that the concepts used in Git are too hard to learn. How on earth do you think you can write correct programs if you cannot even wrap your mind around as simple as Git?
Some old git commands do have poorly named flags and some commands like checkout and reset have way too many modes, but those cannot be fixed without breaking backwards compatibility.
Maybe we should have easy-git (eg?) that is just an alternative command line interface to git, where the intent is easy to use instead of backwards compatibility. Of course, that would prevent scripting those commands because your scripts would fail when its interface is "improved" in the future.
That's pretty simple really, i'm more likely to write correct programs if I have less cognitive load to spend on my version control tool. And to other things unrelated to the task at hand.
What happens is that some people have spent huge amount of times polishing their git skills, and written thousands of commits in git, doing hundreds of rebases, practiced the best practices, ... so they are like long-time users of emacs. For them everything make sense, feels productive and there is no point in using something else.
Personally I'm more interested in the beginner's mind than in the expert's mind. With sufficient training, everything seems OK.
Agree, you can't touch /usr/bin/git itself because it's like the low-level library that everone relies on.
I'm using lazygit when I'm in the terminal, does the job really well
simple terminal UI for git commands
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here.💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…
Funny, I never though of challenging git… and yet now you say it.
Conceptually, I really like the idea of git with stricter flow—a bit like React enforces one way data flow over bindings. Like default protected main branch that only merge with PR, no cherry pick between branches, no "cross-path branches" etc. Start your feature/bugfix, work there and then push to main and that's it. Today we have so many ways to deploy branches that it could make sense.
A last opinion, that might not be the most popular: I think a "branch/feature/bug etc." should always rebase itself vs. main, not merge. It would be easier to understand. Your modifitations are always after the "main" branch until merged. And hju should make that easy 😛 How? I have no idea.
Thanks a lot.
is your last paragraph something different than nudging people to squash their pull requests? That's already what we do on GitHub.
Well, when squash-merging your PR, you have resolved conflicts in the first place. For new and old dev alike it's often it's often done by merging main at the end. Along the way I learned the many benefits of benefit of rebasing often. But right now it implies force pushing, continue/skipping etc. While merging leads to situations where all of a sudden you have tens of other people commit in the middle of yours.
I think a system where your branch always live "at the tip of main" (conceptually, wether it is really a background rebase, or just a final merge, I have no idea!) rather than where you started, would really decrease the final merge cognitive load. Squashing helps indeed, but I think it's not the whole story.
I respectfully disagree. There is a vast scrapyard of interfaces to make Git easier to work with - the truth is that the easy things in Git are easy, and the hard things are hard because they represent a sophisticated set of decisions that cannot be simplified and remain meaningful.
Git is as good as it is going to get as long as we're version controlling the broad class of ANY text file. To make a big step forward, you either have to restrict to a smaller class of problems or the broad class of problems has to collapse into that smaller set on its own, which will eventually happen.
I don't disagree but I also note that there is a resistance against using the tools that make git easier to work with. People will insist you must learn the CLI. I respectfully disagree and think like Arnaud Dagnelies in the comments that git was successful because Github made it much simpler
You know, I wouldn't mind a more "simpler" git. In my current project people who have no idea about software development are forced to use git because the projects are in .Net (and made by mech engineers!).
They constantly say they hate the .Net projects because it's hard and I totally get it! When you're busy trying to get an industrial machine running, seeing a null reference exception has to be the equivalent of a middle finger. Then comes Git, with it's weird terms like branches, head, merge and rebase. If I was in their position I would be like I DON'T GET IT AND MY BOSS WANTS THE MACHINE TO RUN ASAAAAP ugly crying
So, a much more simple or simplified Git would probably help them a lot in this case (I don't recommend replicating this case though).
I hope hju actually exists at some point, it's very sad to see people frustrated with software, code, tools, etc.
This!
I think GitHub alone is the reason of git's success. And Linus too when it started. This combo made a fast growing community that had a huge networking effect. Otherwise, I think the now long forgotten Mercurial would have won the race, it was basically a similar tool, just easier.
Exactly. In fact Github perfectly fits the bill of "like git but simpler".
Interesting prediction. I don’t like to shift tools for insignificant value a new tool bring. Git especially handled most of problems vcs had previously and became universal. Unlike Git, I’m ready to jump if someone make a better tool to replace Jira.
What things do you think Git sucks?
git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right.
It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust each other, where learnability, usability, and just not getting in the way are important factors.
The SQLite people have a concurrent to git called fossil. You don't have to switch. But I found their description of why they started and maintain the project incredibly interesting and stole many ideas from it
fossil-scm.org/home/doc/trunk/www/...
My dream is an SCM that is language-aware. In fact the SCM doesn't even have to know about this, only the diff engine.
So when for example dev A reorders some functions in a file and dev B modifies a line in one of the functions, the diff/merge process can work out automatically what happened instead of throwing it back as a conflict.
It's 2023, there are ASTs in my fridge display and developers are still diffing everything line by line, how did we even end up here.
I've been writing a git wrapper called oaf that has many of the properties you're discussing. As a past Bazaar developer, I'm trying to bring the UI advantages bzr had to the Git format.
github.com/abentley/oaf
Just installed it, thanks!
It already exists sapling-scm.com/
I wasn't aware of Sapling before you and another commenter mentionned it.
Do you have experience with it?
I wonder if it's taylored to Facebook needs or to the avergae IT projet.
Edit: Facebook use it internally since 10 years. Super interesting. Will follow what happens with it.
Yeah. I used it for 8 years while there and just started again now that it’s open source.
It makes it trivial to maintain a linear history and takes all the fear out of rebasing. Amending commits that have had changes requested during code review is painless (via absorb) as an example.
most operations are simple and easy to remember rather than all the git craziness of heads, caches, soft resets, hard resets, reflogs, etc.
Interesting Prediction!
only after reading again more carefully, the parody aspect comes out more clearly. So if this is supposed to be like yarn vs. npm, I predict: hju will gain a lot of user adoption in a certain scene only, all the improvements will be ported back to git, but people will still argue about which one is better even after both will be hardly discernable.
How can something "only work on windows and Android" these days? And which Android version? Probably we will need Kotlin and gradle runtimes matching peer dependency versions exactly, so hju will soon be much worse than git in many respects, but people will still defend its benefits and engage in hate and flame wars on twitter about it!
It's not a parody, apart from the inevitable joke that you can't predict the future.
Unless you are working at Microsoft on a git replacement that will be made available as an option on GitHub.
Which I'm not :)
I'm on the JVM and our two build systems are Maven and Gradle.
Put 10 programmers in a room and you will never have an agreement on which one is the best.
But there are meaningfully different.
That's the ideal case where we have two similar tools but that address the needs of quite different contextes.
I think you read too quickly here. I was saying that git was designed for posix systems and is a bit of an alien on Windows and Android.
I don't think that there are many Android apps using git? I tried to, via the NDK and libgit, it was really not nice.
I did not really do any serious native app development so far, so I can't tell. As a web developer, I would always go for a web app / PWA if possible.
Either way you can't rely on the git executable to be installed on your smartphone.
Asking for the user to install the git executable
well I have tried to do git myself with termux multiple times and failed every time.
That's why Android apps propose you to sync with Dropbox or Google Drive but almost never with git.
So you mean for versioning user content? Good idea, never even came up with that. I used to have git and a terminal on my smartphone, but I never really used it for development purpose as the screen is too small for actual development, but a git client might be useful, but probably something more lightweight than git actually.
My use case is that I use obsidian.md/ as a markdown-based offline wiki.
Obsidian is basically VS code for words - instead of code.
There is an obsidian-git plugin that is very handy to sync things obsidian.md/plugins?id=obsidian-git
Obsidian works on Android, and obsidian-git would if I managed to install git.
But so far I didn't :)
hju sounds a lot like mercurial 2: electric boogaloo
Check out a new source control from Facebook called Sapling:
github.com/facebook/sapling
Holy shit, I had no idea
And it does look a bit like what I had in mind
sapling-scm.com/docs/introduction/...
Also being made by Facebook, this solves the hurdle of struggling to find a business model.
Am I the only one not seeing the difficulty of git? I don't remember having struggled to learn it, and I love the versatility of the tool.
I agree a stricter vcs may help in professional settings (though you already have that through branch protection and the like, why also having it in git?) , but in general I love the power to do anything (squash, merge, amend, edit, undo, etc).
Like with every software, you can evaluate that by doing usability testing in the wild. Take someone who has done less than 1.000 commits, give them tasks to do without telling them how and watch how they struggle with git.
That should be eye opening.
Another way to do the same thing is to look at stakoverflow answers for git and be amazed how super simple tasks with git get millions of views because
git --helpandman gitdidn't give people the obvious solution they were looking forstackoverflow.com/questions/tagged...
Here for example a huge amount of traffic for... finding out what's the current branch?
Same on DEV.to (and everywhere on the internet), git topics get you an amazing amount of traffic
dev.to/t/git/top/infinity
As a content creator, I have to admit that git is the best topic ever. There is such a huge need to translate git speak to human speak
I am not sure you can use those statistics as a good indactor. Git is used by pretty much everyone in the dev community, and is around for a long time. This could easily explain the scores on stackoverflow.
Dev.to is mostly for beginners and web devs. The analysis in my recent article dev.to/derlin/devto-is-for-webdevs... would also perfectly explain why git is popular on this platform.
Not saying you are wrong, just that those two arguments are not enough to convince me.
I would say the popularity of stackoverflow questions is more ore less
popularity / usability. Git's popularity is super high which is obviously explains half the explanation.I'm also convinced that if git was more usable people would need to google & stackoverflow things much less often. For example I use the
herokuCLI which also does pretty complex things, but I don't often need to google and stackoverflow its syntax, it's pretty straightforward.Okay that's a good point :)
But in this case, I would be for improving the doc and cli of git rather than replacing this a simpler, more limited tool. I would also stress that git has an amazing online doc, which users often bypass completely.
That being said, I loved the thought experiment, and agree there is room for improvement. Let's see what happens in the future ;)
I'm all for using better terminal clients like lazygit github.com/jesseduffield/lazygit
You cannot change anything in
gititself, becausegitis not only a git client, it is also a library used by many many scripts and apps. If you remove a command-line flag that almost no-one uses, there is an app that will break somewhere.git's documentation isn't amazing, it has a chicken & egg problem. To know which part of the documentation you need to read, for example
man git-reflog, you need to know most of the answer already ("that's the kind of issue I can solve with git-reflog"). That's why git's documentation is the whole internet instead.Do you even lose the commit messages if you can just reopen the merged PR after reverting a squashed commit?
I'm very pro-squash as it keeps the main trunk clean and avoids situations where people revert only portions of their PR, instead we revert the entire squash and they reopen their feature development branch.
I'm not entirely sure we need a new VCS to achieve most of this. A lot of it can be done through guidelines and a good UI (which could be either a GUI or a CLI) on top of git. For me git is pretty easy and simple : I use it through Jetbrain's IDE 90% of the time and I chose to completely ignore rebasing and encourage my team not to use it : our commit history doesn't look clean and so what ? At least it shows what actually happened.
For the same reason I'm divided regarding S
Squashing on PRs : On the one hand it does make it things cleaner and prevent commit messages that are hard to understand out of context, but on the other hand you lose the justification for a specific change. Sometimes I don't care that you changed a variable name 2 years ago to make it more consistent, I just want to know what feature that part of the code relates to... And sometimes I do want to know why that variable name was changed.
I think what I'd really like is a way to keep all the commit, but bundle them together with a message that explains the whole feature. I mean that's what PRs are for, but as far as I know you can't really see the PR from git once it's been merged since they're handled by your repository and not in git itself... So I guess that's the thing I'd like to see added in a got successor : a way to keep both individual commits and merged PRs.
JetBrains git integration is amazing, I have an article planned on this.
Squashing on GitHub works exactly like you say. If you look at the main branch, it's only one commit, but if you need the details, you click on the link to the PR and you can see what happened step by step.
I agree, the issue is that there is a strong culture in the git community that goes against that, that discourage people to use git clients, that pushes "best practices" that reflect what they think is the one true way to use git, ...
intresting