For all those who think that Git is easy, it's not.
It takes a student about 20-30 hours to really understand all usual Git commands. I'm not talking about something bizarre like ls-remote, but really understand merge, rebase, bisect. Not just syntax, but all the consequences. For instance, why rebasing something already pushed to public often leads to false merge conflicts, how does stash really work, etc.
Also, bisect is definitely not common, and the vast majority of my colleagues wouldn’t know it exists; I’d place it into the look-it-up-if-needed category.
But you get rid of those ugly merges back and forth and unviewable histories.. Not sure why not more people care, I guess it is a little OCD I do that for my stuff.. however the 20-50+ user projects where everyone, often multiple times merges develop or even other branches in.. really unusable history right away, lets not talk about any point later. Git has derailed to a mere backup system where you can jump back, but understanding changes later becomes impossible :(
What people also rarely know: A linear history is without lies, but one can sneak additional changes into a merge commit that was in neither branch quite easy - I hate that!
Most people don't care about most stuff, it's pretty normal.
But here specifically: Most developers don't read code, nor documentation, and essentially no one reads commit messages. VCS is a WOLM - write-only linear memory - to most developers. That's probably also why most people don't care to write any kind of reasonable commit message - the software requires them to input something, so something is input - and also do not care about unreadable (and also unusable) VCS histories. They're never looking at it, it's only written. Hence it's meaningless for them if it is extremely difficult to trace changes or hard to bisect, they don't even attempt such things. There's a reason the history browsers in all the online tools and IDEs effin suck, it's because on average nobody uses history.
I know, I know, this gets across very elitistically, but it's just how most people do their jobs. They get bugged to do a thing, so they sort of do the thing in order to not be bugged any more about it. I'm pretty sure that caring for these things is some kind of OCD like you say, i.e. a mental disorder.
I’ve had experiences where I’m trying to rebase a branch and it keeps flagging my most recent changes in the rebase when the intention is that I want all previous changes applied then as a final step show me a conflict if applicable, don’t show me one when it’s not the “final” step.
Admittedly maybe I’m doing it wrong.
I also don’t like how rebasing “main” onto my branch actually seemingly takes my branch and rebases it onto “main”? Maybe that’s a fault in my IDE not entirely sure
Not quite. That would mean that my old base is REPLACED by something else, right?
Instead rebase means take some other branch then put all the changes in the current branch on top of it, keeping everything in the current branch but just adding them on top of something else, right?
It grokked with me when in my IDE (WebStorm) I saw the menu-option allowing me to choose another branch and perform "Check Out and Rebase on top of the current branch". So you don't just "rebase a branch", you combine two branches. And when you combine two things here the order matters, and it is easy to confuse the order.
Similarly if you merge two branches, which one overrides? The left or the right operand? It is easy to get confused. Maybe I am. It is not my fault.
Every rebase really is at least three branches: what you're merging into, where you started, and where you are now. And God help you if somebody rewrote history on any of those.
The fact that all of these have terrible names makes it so much worse.
This makes bisecting a lot easier too.
IMO merge is almost never what you actually want, unless you've been working separately for a long period of time (and generally you should not being doing that because it leads to surprising conflicts / regressions at merge time).
But yeah, after that initial push, it's just merges from there on out.
When you merge 17 changes from foo-feature into master, master has only a single commit. You cannot bisect master to determine which of the 17 broke master.
The 17 commits are there, but only in their original form, based on some old commit. Those 17 original commits are not equal to the single merged commit. The single merge could have a bad merge.
If there is going to be a bad merge, it's better to have a bad merge in one of 17 commits being individually rebased, than to have a bad merge in a single merge bomb that conflates 17 commits.
Your little branch of the original 17 commits should be purely a private object; it does not belong in the upstream. It's just a historic accident that your work was originally based on some three-week old random commit that happened to be latest at the time when you started. There is no need for that to be published. Your job is to make sure your code is based on the latest commit and promote it to the branch, as a sequence of individual changes (which all build and pass unit tests, etc).
I've literally not typed "git merge" since 2010, and around that time I learned how not to have Git perpetrate unwanted merges on me by learning never to type "git pull". "git pull" can be configured to be "git pull --rebase", but you will forget. I trained myself to do "git fetch", then "git rebase".
In all my last three jobs, the review tool Gerrit was used. Gerrit is based on cherry picking, which is rebase. Commits are submitted in their original form (not necessarily rebased to the target branch, but indicating which branch they are for). When approved, they are submitted and that means cherry pick. Maybe Gerrit can merge; I've never seen it used that way. Gerit has rebase right in the UI. You can take a commit and rebase it to its logical parent (latest patch set of an apparent parent with which it had been submitted together), or to the current head of the branch.
Innocent typo but for anyone else reading, it’s “rerere”.
No, you have two commits. Git commits are snapshots, not diffs. Git's data model is simple. The fact that people do not bother trying to understand it is the root of the problem.
Let's suppose the next thing I do is add something to the bottom of my 5 branches. I dont switch to the branch, I stay on bl-dev and add a commit to bl-dev. Then I type "git rebase --update-refs -i HEAD~7" and move the commit up in the stack to the correct location and again all 6 branches update.
"git rebase --update-refs -i" also gains the ability to change which commit any branch points to.
I don't actually type "--update-refs", it's a gitconfig.
You start with a "main" rail of coats. Each coat is given a number, indicating what order it is in.
You start adding coats to a new, empty, rail, using the next number. When you are done collecting coats on this new rail, you want to move your coats onto the original rail.
In the time it has taken you to collect the coats onto your rail, someone else has already added coats from their new rail to the end of the "main" rail, and they used the same base number that you have - which means you cannot just add the coats from your rail onto the main rail, else the numbering would be broken - we call this a conflict. (NB: There is a magic guardian of the rails that means this just cannot happen, which is a plot device that is just to make this metaphor work so don't question it, it's just a metaphor.)
To resolve the conflict you have the following "rebase" options:
- Slide all of the coats on the main rail up to make room for yours, and update all of the numbers on your coats, using the new number from the last coat as the base number for your rail's sequence. This ensures that everything on the main rail is "before" your rail. This is the equivalent of a rebase. After this, you can then put your coats on the end of the main rail without conflict.
- Then there is the option to take a copy of the main rail onto the front of your rail, and organising the coats one-by-one (much like in the above), placing your coat(s) in between some of the new coats on the main rail, then forcibly replacing the main rail with your updated rail. This last one is just as drastic in reality as it sounds in this metaphor. We call this the "interactive rebase" and it is rewriting history for anyone who has used the main rail before.
- Finally we have a merge which means adding one big magic coat at the end that takes the coats from both rails and combines them in a singularity, with the new base number being Hawking's radiation or something, I dunno. The metaphor is no good for merges.
(Truth be told: the entire metaphor started in my head some years ago with just the visualisation of that distinct coat rail sweep noise to squish the garments on the rail to onside to fit what our main protagonist is holding onto the rail, the rest I just back-filled over time)
Many new users of git don't have the luxury of learning how to use local-only git with no remote.
Now rebase is a farm implement: a mechanized cherry picker. Cherry picking should be taught first, and then rebase explained in terms of being a multi-cherry-pick operation.
Before teaching cherry picking, you have to teach that Git is based on snapshots and not deltas. Git cherry-pick is part of tooling that is inside Git, but external to its snapshot-based storage model. When you cherry pick some commit into your current branch, the tool finds the common ancestor between your branch and that commit. It then does a three-way diff using the files in the cherry-picked snasphot, your own branch snapshot and the common ancestor-snapshot. The three-way diff operations produce a merged version that becomes a new commit: another snapshot.
If I ran a class on Git, we would spend part of a lecture doing manual merges with the diff3 utility: I would have the students take some ancestor file and make a "my" and "yours" with different changes, and merge these with diff3. We would go through conflict markers and all that.
Old time hackers who used other version control systems before Git knew all this stuff already. The first time I encountered conflicts, I already knew how to resolve them. Just a few git concepts were new like having to add resolved files to the index.
Imagine you know nothing about version control. Words like "unified diff" ring no bell. You've never seen conflict markers. You've never applied a patch or produced one.
Agree.
> I’d place it into the look-it-up-if-needed category.
Disagree. Bisect is so useful in so many different scenarios that learning about it and the basics of how to use it is a great way to get people into git. Obviously not right at the beginning of their learning curve but as soon as the basics have been covered satisfactorily.
Knowing how to use git bisect is what elevates a programmer to the next level. Just understanding how it works gives you a new way to reason about bug finding and fixing (or feature development using old and new), and then actually using it can make you a bug fixing master.
This was not my impression when I first learned about it. I thought I'd be using it all the time.
Just understating how git bisect works is the real superpower. The tool is a nice add on, but often you're right, is easier to bisect by hand by going to a known working commit and then doing a smart bisect based on the code you think might be offending.
But at least knowing the concept of bisection is a huge game changer.
Really feels like a stretch to credit git, of all things, with that fundamental understanding. It's like saying you need to operate a nuclear power plant to understand the benefits of locking doors.
But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade of any serious work with software? I'm assuming that this doesn't mean literally 20 hours of instruction.
The problem is also, if you don't use it daily git knowledge decays fast.
There is a piece of advise that was making the rounds (unironically) at the research institute where I worked before: "Before you do anything with git, first make a local backup copy."
But it could demonstrably be better and easier and we are stuck in a local minimum of a good enough solution because of the network effects.
git stash is the equivalent to saving your work somewhere else and getting a fresh copy.
But even then, what's the benefit of using a strange git command, which means I have to track another bit of state only visible to git, which can easily be misused (by applying the stash to the wrong commit), and anyway doesn't save the actual working directory I care about (untracked files), over simply making a file system copy?
You can start saving your work somewhere else, getting a fresh copy, and then try that git thing again when you know how git stash works. What you're proposing is like not learning how an incremental compiler works and suggesting to wipe, clean, restore local backup, try to compile the thing again to fix compile errors every time you have a compile error instead of learning how an incremental compiler works.
There’s several alternatives where you can be as effective if not more in a fraction of the time. The one that I preferred was mercurial, but unfortunately since GitHub was so successful we are all forced to learn git.
Gitless looks, feels and smells like Mercurial (hg), which is simpler and more effective.
It only took everyone 18yrs to realize it (sarcasm).
Yet most people just want to use VSCode and don't want to invest 20+ hours learning emacs or vim
But you know what? I moved to VS Code a few years ago and my productivity only increased. Everything is more intuitive and discoverable. Everything just works with no tweaking. All the convoluted macros and text manips I painstakingly crafted and memorized in vim are achievable in a few clicks in Code.
Spending 20+ hours learning emacs or vim is quite literally a waste, it's time we all admit it.
(I still think one should learn the basic cursor keys and how to save/quit in vi because sooner or later you'll have to edit something on a remote server with only vi. But learning emacs is still completely useless, though.)
For me, with my ability to learn at the rate that I do, Emacs provides the best solutions for Git (Magit), email (mu4e), calendar (Org), to-do lists (Org), note taking (Org) and more.
And I don't use software like mu4e because I already use Emacs; I use it because I have installed and evaluated dozens of email clients over the years and concluded that mu4e is the best for me given my requirements.
For people who aren't as particular about the software they use, Emacs may very well be "quite literally a waste".
Given the poster mentioned using Vim for 30 years, I assume he is blindly lumping in Emacs because I've never had to maintain macros or text manipulations -- smartparens and the built-in text yanking features have been sufficient for refactoring code and structural editing.
Most of the things I do with Emacs, people will claim are doable with tmux and a dozen assorted shell utilities, which IMO is just false since you don't get any user interface or convenience close to e.g. Magit, TRAMP, notmuch, eww, and so on.
For instance, one of the supposed benefits of Vim is that you can SSH into some box without your editor of choice installed and still edit files. Why settle for such an experience when TRAMP lets you stick with your current editor, with all of its configuration and plugins, to modify files remotely?
Likewise, notmuch is very good at organizing threads across several mailing lists, whereas Thunderbird has needed me to Google dozens of questions, click lots of buttons to set up filters, and still end up with nothing better than a flat list of e-mails in my inbox.
Since my post is getting long, I'll lastly mention eww is great for browsing things like Javadoc, Codox, the Common Lisp HyperSpec, and other statically-generated HTML documentation.
The most time investment I've needed into Emacs was essentially
sudo port install emacs-app
I've tried time and time again to try using VS Code so that I can help some friends get into programming languages like Clojure, but I always find myself spending 30 minutes searching how to do things I take for granted in Emacs, like automatically indenting code as you type rather than manually hitting "Format Document" or creating a save hook running that function.
Because I can totally see not using the editor, but the keybindings, even the basic ones every emulation plugin manages to do well, are such a big win it's hard for me to believe I'd ever give those up.
Also, at least from my perspective, VSCode and Neovim are eye-to-eye, in the sense that both get most of their magic from interfacing with Language Servers, which both do very well. Though even the more approachable Neovim still seems to have a fetish for configuration/a hatred against sane defaults.
There's nothing out there as configurable and portable as Emacs.
Easier, sure.
Don't get me wrong, I'm all for tinkering with stuff and customizing to oblivion, it's fun and cool, but realistically how much better of a JS engineer are you going to be if you've customized the hell out of Emacs? Maybe a bit more, I'll concede that, but fundamentally I don't think it's going to be categorical.
* Vim key bindings for text edits
* CLI commands for Git
* Emacs modes such as Magit and org-mode
* VSCode for tight Typescript integration, nice block structure visualisation etc.
I hope some editor will combine this all. (I think Emacs will be best placed to achieve this with its extension ecosystem that already includes Magit, org-mode, evil-mode etc.)
I spent a lot more than 20h learning emacs. It was my main editor for years.
I use VS Code now. It serves me very well.
Yeah same, are people saying 20h commitment is a lot now ? Not sure if I've gotten old, or if things are easier to learn now - but a 20h commitment seems like very lite.
(2) There are more tools to learn. That 20 hours/minutes is being multiplied by an ever growing number.
I should say, if the choice was mine, I'd probably still choose git. It's powerful, it's something I can already make really good use, and I feel comfortable easing new people into it. Regardless, the point is that I don't have that choice as an individual who's part of a team or an organisation.
On the other hand, I can choose my code editor without interfering with my fellow engineers's own choices. Here I chose the one I could learn in 20 minutes and get better the more I used it.
It took me very little time to get productive with VS Code, and then a few more days to get used to most shortcuts I use. Everything else is accessible via the command palette and more shortcuts can be learned as their functions become used more frequently. Until that, the palette is an excellent interface. It also serves as a discovery mechanism for features.
With emacs I had to learn a lot before I started getting productive. I got very good at it. Multiple cursors, window jockeying, buffer wrangling, the works. Any functionality that fell in disuse for some time, I'd risk forgetting their shortcuts. If I did, the only way to use it would be to somehow remember the shortcuts, probably by interrupting work and googling, or by trying to navigate its archaic menu systems.
With vim it's not very different. I still use it more or less daily but mostly for single file editing over SSH, since even if I need to do more complex editing on a remote server, I can use my local VS Code.
I don't think people have to use VS Code. I work daily with other engineers who use it, but also any of the Intellij editors, vim, emacs, you name it. We can all live in harmony and collaborate just fine. Not so much if each would chose their own VCS.
To expand upon this, for version control there are pieces of GUI software that can allow you to handle the typical workflows without touching the CLI. Packages like Git Cola, GitKraken and functionality that's bundled with most IDEs as well.
In addition there are also platforms like GitHub, GitLab and Gitea which will let you easily get changes merged across branches with either a single commit or different strategies, all with the press of a button.
I don't think that there is a reason for everyone to do a deep dive into Git, aside from their own curiosity, or when using complex workflows.
win win.
That's enough to track changes to your own projects, see the benefit of tracking what you've changed, and build the habit of commiting frequently. IME, adding anything more about remotes and branches is overwhelming to the point they don't bother with git because they aren't going to distinguish the fundamentals from those more complex features.
Obviously branches and remotes are vital in real development, you just can't expect them to learn it all from the start.
Many of the commands don't make sense, and many of them are dumb implementations, which wouldn't be done that way in a clean redesign of git, even if it were based on the same storage model and concepts.
Some of the commands are essentially tooling that is external to the Git storage model and emulates delta-based version control on top of the native snapshot model. The commands lead to fundamental misunderstandings such as that commits are changes.
Well that's actually "create a branch and then checkout that new branch". And you can use "git switch -c" if you feel the "checkout" verb is confusing.
The command to just create a branch is "git branch". Git branch won't touch the HEAD pointer, that's what switch does.
And if "git branch -c" were the command for "create branch and switch", it would be criticised in the exact same way: creating a branch and switching to it would be a different subcommand to that used for switching existing branches. Except now the branch command can also do "switchy" things to your HEAD pointer, but only sometimes (and the fact that checkout also only sometimes changed the HEAD is why switch was introduced).
"Branch <branch> does not exist; create it? [y/n]"
To be fair, I've long used "checkout -b" and I don't think new branches need this, but it might be helpful in special situations like rebase/merge conflicts. I appreciate this sort of interactive CLI in other tools (apt, vite, etc.), versus having to look up the manual for the right options/switches. It's a different approach that might be more annoying to some power users, but is more friendly to most other users.
(This is also where GUIs are helpful, since they display most of the useful commands and options for you. Plus they can do things like see line history by commit and list your stashes for super-easy switching; GitLens/GitLess in VSCode do these.)
https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
In the same way that you don't need to understand the inner workings of Google Docs, Git should be something you don't even have to learn. Sadly we're not there.
I typically use it as a barometer for how in depth the candidate tries to understand underlying mechanisms of tools they use.
I don't think I'd work successfully with people who don't care.
Another way of thinking about interviewing is this: you say you don’t want to work with people who don’t care about this problem you care about. That’s fine, I guess. But if you changed your viewpoint to “I want to work with candidates who care about interesting things” then you might find you ask more about what they care about and less about what you care about.
Sometimes I'll tell a rebase person that if they don't like merge commits they can use git log --no-merges and you won't see merges. The majority of people I come across who prefer rebase for "clean history" reasons don't know this.
If you truly understand the difference between rebase and merge you'll come to the conclusion that it doesn't matter what you use.
I'd file this question under "trivia the interviewer believes correlates with performance".
Like, asking what a for loop does wouldn't give you any real positive signal, but if they can't answer it's a strong negative signal.
You might as well judge people on how well they know xkcd comics or VIM keystrokes.
Git is basically just blobs, trees, commits, and refs [0]. Four simple concepts. Yes the interface is confusing and I don't know it either, but things are easy enough to look up.
[0]: I love "fast intro to git internals": https://docs.google.com/document/u/0/d/1X5SnleaX4qpLCc4QMAMW...
It’s probably best to consider that something like git is _not_ inherently interesting and is more likely (subjectively) boring and tedious to humans who are comfortable with simple saving and undoing of files.
Git is the only software where the need for learning its internals is recommended
It is a sign of huge failure of API design
However, the core data model is simple (it is a content addressable store, where each commit contains pointers, forming a directed graph; the pointers are unforgeable, so the graph is acyclic).
There are many sources of interacting states, some internal to git, some not:
the local tree of commits
remote trees of commits
a possible origin relationship between the two
branch labels on each local and remote with possible relationships between them
the HEAD label
stash
index/staging area
the actual working directory
.gitignore
Describing Git’s behaviour in terms of other version control systems’ semantics (e.g. Subversion or Mercurial) is not necessarily easy, but that’s not what’s being claimed.
> Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.
> Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area.
https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-...
But unless you have to work with other people in places like github, etc, it beats having to bother with git - especially for games that have a ton of binary files (which, unlike what some people will tell you, you want to have both version controlled and in the same repository).
Hell, if you really want a DVCS go with something like Fossil, it is still much easier than git, simpler to setup (just a single binary) and has more features (wiki, bug tracker, forum, etc) that you will find useful anyway.
Though personally the best experience i had with VCS is with Perforce, at least in gamedev: check out the latest version, merge any local changes, make modifications in a changelist, shelve the changelist in case i want to stop working on something and work on something else, use the shelve to send a WiP version to a coworker to merge with his changes (or see if things work as expected) or for code review, etc.
Sadly Perforce seems to be bound in a company that tries to sqeeze it for all its worth, adding a bunch of stuff of questionable usefulness, etc. It'd be nice if there was an open source alternative to it that allowed for the same or very similar workflows, all the issues i had with P4 over the years (e.g. merges between streams) were due to how P4 seems to be implemented, not due to anything inherent in the workflows themselves. There is no reason for an alternative to copy all the bugs.
Yes, Subversion is initially easier to learn and use than git. It's not easier to set up as it's client-server while git is fully local. Also Subversion is an incongruous mess.
It seems that you are comparing apples to oranges. Building your own SVN server from the ground up can indeed require some effort. Doing the same for Git demands more or less the same level of effort on your part. So, I believe you are comparing building an SVN server from the ground up to something like installing Gitea or GitLab, or using Git locally.
Again, you don’t have to install an SVN server. Just run `svnadmin create REPONAME` and use the `svn` client to import your data into the repository.
> You don't have to set up a database for Git, either, and it works entirely locally.
What database? Subversion doesn't need any special database to work. Just the repository and its working copy. Both can be local and can be created with two commands.
If you want to go old school there is RCS or SCCS. GNU provides source code (for SCCS there called CSSC). Though *CS are per file not per logical commit.
IIRC Perforce actually used RCS under the covers for storing the deltas.
If your repo ends up in a weird state, learn how to fix it. It should not be terribly complicated, especially if there is no rebasing happening.
Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes.
Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will).
Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.
And plenty of times functions are self contained enough that you can change the function body without changing other code as well.
Stop thinking in terms of branches, and start thinking only in terms of commits. Pretty much every git operation makes so much more sense when you consider your repo just as a tree of commits (technically a DAG), rather that trying to reason about what it does to the branches. Branches are really just pointers to commits which can change over time, and most git commands don't really care about them.
This sounds like obscurantism.
What bad thing happens if students just assume that rebasing something already pushed to public will cause merge conflicts, and just never do that?