Git 2.33 released with new optional merge process likely to become the default: It's 'over 9,000' times faster Git 2.33 has been released, including a new optional merge process called merge-ort, which the team hopes will become the default in the next version. Git releases are relatively frequent. Git 2.31 was released in March and Git 2.32 in June. According to the release announcement, version 2.33 "does not have many end-user …
"The mental model for Git is needlessly complex,"
Absolutely, and for 99% of projects Git is massively overkill. However, in many ways rather than keeping up to scratch in all of them, it has been nice to just simplify and stick to Git for everything. I found it a bit of a struggle working with mainly SVN, some CVS and bits of Perforce chucked in for good measure.
A mono-culture is never good but... at least Git is pretty decent this time. Imagine if the mono-culture was Microsoft TFS! :/
Brrr, speak not evil in these four walls, for those creations of the Terrible Trivium, Visual Source Safe, Mercurial and Rational are still at large in the world, wasting time, leeching productivity and blighting lives.
["If you only do the easy and useless jobs, you'll never have to worry about the important ones which are so difficult. You simply won't have the time, for there is always something to do to keep you from what you should really be doing." ~The Terrible Trivium]
A tool should make your productivity go up without requiring you to like it.
GIT was designed with the Linux kernel development in mind and it does the job well also for other open source projects, but it's far from being universally good, TFS has a much higher chance.
I've used (and I'm using) both and the only 'real' advantage of git is the branching flexibility, but it comes at a price; in brand new projects or when the developers want to contribute you will find plenty of people praising git/github or the social coding platform of the day, but on big legacy projects that requires substantial refactoring with many devs, (often with sub-standard skills) git is a needless headache and a time-vampire.
TFS is stupid-simple: get latest, save your files (and they are on the disk, no magic!), check-in when you are done. Get latest as often as you want, no biggie, is actually helpful to find conflicts earlier with whatever code is being messed up by your colleagues.
With GIT, besides having to copy the whole ***ing history first and the byzantine command line (which now is not as needed as before since GUIs are getting usable also for users that do not need to make a statement) you still have to commit often to avoid the occasional total-loss-of-changes (TM) and the push-pull mumbo jumbo to get the latest changes is the icing on the cake.
And by the way, you can use TFS from command line since teh very beginning. Nobody does because it's error prone, a waste of time and nothing to be proud of. For some reasons in recent years being forced to use command line is 'cool'. I wonder if the same millennials that feel more manly by using command line would love to have a terminal also on their pocket computers, or perhaps on the multifunctional touch screens becoming more and more common (yuck) in cars:
$tesla> climate-control --ac on --fan-speed 3 --recirc off --temp 25
Is this a real world example of the "write one to throw away" idea? That is, *now* they know enough to write it for correctness and speed, now that they have encountered all the tricky corner cases and observed the behaviour of competing algorithms.
Nice of them, though, to make sure the prior not-so-good versions were quite good enough for use. Unusual for the real world from my experience!
One of the major thinking errors people make when switching from CVS, SVN, Hg, etc. to Git is that they assume that it is a file-based revision control system. Instead Git is essentially a filesystem. Or, as put in the Git documentation:
"Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot."
(Source: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F)
In this regard it's probably easiest to think of Git akin to ZFS and other snapshot-based filesystems. Within that mindset it's a lot easier to grok why Git is so painful to use where a file-based VCS would make so much more sense.
I don't find that a particularly helpful mental model. I change files, I commit changes to files, and sometimes I tag a point in time. If the internal system is "like" a filesystem snapshot, well and good but I'm not thinking about filesystem snapshots.
As for pain, just use the Emacs Magit interface and move on.
"remembering what command with which option does what I need to do"
and in most cases a quick "git status" will tell you the most obvious next steps...
(yeah, the [expletives deleted] merge options and options to the strategies and... are a mess, I concur)
Taking snapshots of a filesystem is a good mental model for Subversion – it is probably the mental model almost everyone uses when working with it. So I do not know where you got the ‘thinking error’ idea.
CVS versions single files. SVN versions entire directories (trees). Git… makes simple things look complicated.
To me git is far too complex and this proves the point even further to me. Sure it’s good for the large open source projects like the Linux kernel, which it was designed for, but for majority of corporates do not need anything like this. “Git is great, git is so good” and it took over. Branching and merging is an edge case that can be easily circumvented by talking to your colleagues. I’ve worked in IT for many years and the number of times branching and merging was needed I can count on one hand. The only thing worse than git is the abortion that is Clearcase, I would run a mile from it.
A mega merge that now runs 9,000 times fast is such a ridiculous edge case. So what!!!!!!? They made a complex product even more complex and more likely to be buggy.
Speeding up that strange mega-merge is likely not the main benefit. If you sped up things by almost five orders of magnitude it is because you reduced the complexity in the program. So they made a complex product simpler and easier to maintain.
I'm not even doing really big projects, but I really appreciate the ability to work on different aspects of different problems at the same time, without breaking either of them, and being able to roll back to a known good state. And having colleagues doing the same. Merging just makes combining stuff a bit easier, though there can (and will) still be some manual work left over. Just because the syntax and structure is correct does not mean the thing works as the multiple authors (or multiple yourselves at mutiple points in time) intended. Do I absolutely need merging in the projects I'm involved in? It is nice having it to spot changes that contradict each other, which will happen even if you are on your own. It could be done by carefully comparing files and changes against each other. If there only was a tool that did it for you... (like, you know, git).
Yeah, all of this can be done with file system snapshots (though how do you remember what you did change between them, and which date / time to check out) is a problem. Others use an ever increasing number of revision-tags on files and directories (MyProject, MyProject_old, MyProjectNew, MyProject-Final, MyProject_new-Features, MyProject-Might-be_Broken_but_sure-contains-a_nice-idea). Good grief!
I use git because I have less chance to f' up completely, and it behaves nicer than subversion (which I used before).
> Branching and merging is an edge case that can be easily circumvented by talking to your colleagues.
If you work on a codebase of any size, even on your own then branching solves many problems that can't be solved by talking to anyone. In the simplest case, how do you fix a bug in the current version while developing the next version if you don't use branches?
With git branching is a cheap operation and used correctly merging is usually trivial.
...while no doubt brilliant with sqlite, is completely and utterly wrong about rebase.
why he and his ilk continue to confuse "rebase in your private repo before pushing it up for the world to see" with "rebase a published tree and confuse the heck out of the other developers" I could never understand.
It's like saying there should not be a backspace key on the keyboard.
Pick a UI to abstract away the complexity. The vast majority of people don't need the complex features and the simple features can be accessed through a UI, either standalone and built into a IDE. I'm suspicious of monoculture but git really is the best source control I've ever used.
Yes. And it is a RPITA when I have to go back to that project.
One of these days (real soon now(rm)) I'kll get to complete the changes needed (large XML files don't work with merges) to transition to git, and make everyone's life easier.
git's model is complex, but it is a tool for developers who work with complex tools all the time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
