DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for git is not the end of history

git is not the end of history

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 millions of developers on a promise that could be "hju is like git, but simpler".

Specifically:

  • hju concepts will be a lot like git, you will have commits, branches, sha1, clones, ...
  • hju will have great interoperability with git. Importing your GitHub repository into hju will be one click. Transforming you hju repository in a git repo will also be simple.
  • hju will struggle to find a business model that supports a team strong enough to build a tool concurrent to git. Probably the main hurdle right here.
  • hju will not try to have feature parity with git. git can support all the complex workflows you have not imagined yet. The more complex workflow will stay with git. Especially projects like the Linux Kernel, bazaar projects that are completely decentralized, will see no point in migrating to hju.
  • hju will instead work hard to make the life simpler for the vast majority of projects where a small number of developers work together, know each other, trust each other.
  • git will probably have more users than hju for a long while. But there are enough developers that having for example 20% of the market is completely sustainable.
  • hju on the other hand will be focused on the most common usages of version control. It will be designed for usability. It will be significantly harder to fuck up things with hju than with git.
  • hju will lower the cognitive load. When submitting a pulll request, you will feel that you are more focused on the task at hand rather than on what your control version tool expects from you.
  • hju will discourage practices like rewriting history that makes it so enjoyable to shoot yourself in the foot. It will push the idea that it's OK if the hju history inside a PR doesn't look like what should have happened, but instead like what actually happened. It will encourage people to have small PRs focused on one thing and that can be squashed (squashing will be the default).
  • hju will have a vastly better learning curve than git. At some points bootcamps and university courses will teach hju rather than git because the ratio of concepts learned over time spent is so much better. There will be great tutorials on the internet on how to learn git if you already know hju.
  • hju will just work on Windows and Android

Best case scenario: Microsoft has already a secret internal project similar to hju and will make sure GitHub can make it an implementation detail of whether you use git or hju.


Dear readers, what's the best and the lamest part in my prediction?
Since you too can predict the future, how do you see the future of version control?


Update: Two astute readers told me that hju might already exist. Facebook recently open sourced the version control tool that it has been using for 10 years:

Have a look at https://sapling-scm.com/

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.

GitHub logo facebook / sapling

A Scalable, User-Friendly Source Control System.

Sapling SCM

Sapling SCM is a cross-platform, highly scalable, Git-compatible source control system.

It aims to provide both user-friendly and powerful interfaces for users, as well as extreme scalability to deal with repositories containing many millions of files and many millions of commits.

Using Sapling

To start using Sapling, see the Getting Started page for how to clone your existing Git repositories. Checkout the Overview for a peek at the various features. Coming from Git? Checkout the Git Cheat Sheet.

Sapling also comes with an Interactive Smartlog (ISL) web UI for seeing and interacting with your repository, as well as a VS Code integrated Interactive Smartlog.

The Sapling Ecosystem

Sapling SCM is comprised of three main components:

  • The Sapling client: The client-side sl command line and web interface for users to interact with Sapling SCM.
  • Mononoke: A highly scalable distributed source control server. (Not yet supported publicly.)
  • EdenFS: A…

Top comments (45)

Collapse
 
ingosteinke profile image
Ingo Steinke

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?

Collapse
 
t0nyba11 profile image
Tony B

I agree in theory, but in practice, I think the benefits of squashing outweigh the loss of commit messages that are often meaningless noise. The trick is, as you said, small PR's that are committed regularly - with or without squash.

Collapse
 
theaccordance profile image
Joe Mainwaring

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

Completely agree with your second paragraph.

misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.

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.

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?

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.

Collapse
 
mattferrin profile image
Matthew Ferrin

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

Thread Thread
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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."

Thread Thread
 
mattferrin profile image
Matthew Ferrin

I agree with this. For work, I put one link to the wiki location in the git readme and call it good.

Collapse
 
mtrantalainen profile image
Mikko Rantalainen

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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?

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.

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.

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

GitHub logo jesseduffield / lazygit

simple terminal UI for git commands

CI Go Report Card GolangCI GoDoc GitHub Releases GitHub tag homebrew

A simple terminal UI for git commands, written in Go with the gocui library.

Gif

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…




Collapse
 
panditapan profile image
Pandita

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

I hope hju actually exists at some point, it's very sad to see people frustrated with software, code, tools, etc.

This!

Collapse
 
feynmanfan profile image
Chris B. Behrens

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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

Collapse
 
etienneburdet profile image
Etienne Burdet

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

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.

Collapse
 
etienneburdet profile image
Etienne Burdet

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.

Collapse
 
dagnelies profile image
Arnaud Dagnelies

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

Exactly. In fact Github perfectly fits the bill of "like git but simpler".

Collapse
 
bitethecode profile image
Joonhyeok Ahn (Joon)

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?

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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/...

Collapse
 
almostconverge profile image
Peter Ellis

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.

Collapse
 
abentley profile image
Aaron Bentley

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

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

Just installed it, thanks!

Collapse
 
tantaman profile image
Matt

It already exists sapling-scm.com/

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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.

Collapse
 
tantaman profile image
Matt

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.

Collapse
 
ingosteinke profile image
Ingo Steinke

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!

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

the parody aspect comes out more clearly.

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 :)

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.

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.

How can something "only work on windows and Android" these days?

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.

Collapse
 
ingosteinke profile image
Ingo Steinke

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.

Thread Thread
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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.

Thread Thread
 
ingosteinke profile image
Ingo Steinke

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.

Thread Thread
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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 :)

Collapse
 
drewknab profile image
Drew Knab

hju sounds a lot like mercurial 2: electric boogaloo

Collapse
 
liftoffstudios profile image
Liftoff Studios

Interesting Prediction!

Collapse
 
lamualfa profile image
Laode Muhammad Al Fatih

Check out a new source control from Facebook called Sapling:

github.com/facebook/sapling

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

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.

Collapse
 
derlin profile image
Lucy Linder

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).

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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.

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 --help and man git didn't give people the obvious solution they were looking for

stackoverflow.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

Collapse
 
derlin profile image
Lucy Linder

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.

Thread Thread
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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 heroku CLI which also does pretty complex things, but I don't often need to google and stackoverflow its syntax, it's pretty straightforward.

Thread Thread
 
derlin profile image
Lucy Linder

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 ;)

Thread Thread
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

I'm all for using better terminal clients like lazygit github.com/jesseduffield/lazygit

You cannot change anything in git itself, because git is 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.

Collapse
 
nicolus profile image
Nicolas Bailly

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.

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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'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.

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, ...

Hi!I'm Noah!

Hey, my name is Noah and I’m the one who set up this ad!


My job is to get you to join DEV, so if you fancy doing me a favor, I’d love for you to create an account.
Β 
If you found DEV from searching around, here are a couple of our most popular articles on DEV: