Hacker News Reader

Comment by jiggawatts | Hacker News Reader

It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys".

Git was intended for distributed development amongst literally tens of thousands if not hundreds of thousands of programmers.

Centralised SCMs worked just fine for typical dev teams of 2-15 people.

I've rarely seen a team that actually utilises even 10% of Git's features. Conversely, when they accidentally trip over the inherent complexity of a distributed SCM they always cause a giant mess and end up "fixing" it in bad ways.

https://xkcd.com/1597/

View on HN

Eh, Git works, which is all it has to do. The reason you see typical small dev teams use Git is because they're familiar enough with it from dealing with FOSS. And when you are doing FOSS, there's almost no contest – Git destroys the competition for n-person teams when n → ∞.

Besides, it's not even all that complex, there's just an abundance of bad information talking about "diffs" and "branches containing commits" and confusion over the word 'tracking', when most of that is either a convenient representation or an internal implementation detail that doesn't matter at all to the user.

Also, compose key flex.

> Also, compose key flex.

Care to elaborate?

Likely referring to the compose[1] key in X11.

[1] https://wiki.debian.org/XCompose

Thx, but my request was more like "how do Compose and git relate?"

They don't, OP was simply proud of typing "n → ∞".

> confusion over the word 'tracking'

OMG. This was one of my stumbling blocks in learning git. None of the explanations were helpful to me.

The other area that is a tremendous source of confusion is rebasing being described as "re-writing" history. There is no re-writing of anything in git during a re-base. There is some moving of labels (branches), which you might call "re-labeling" but all the commits that were there before a rebase are still there after in the git repository as well as a bunch of new commits.

If the only branch you have is master/trunk then maybe.

But as soon as you have multiple maintenance/feature branches I find git superior to SVN by orders of magnitude even for solo development.

Merge that usually just works, can be easily aborted, rebase, cherry-pick ...

Also having a local copy results in much nicer history, especially when combined with rebase.

The fact that all git operations are local (will except push, pull, fetch) and thus mistakes do not enter the (remote) repo so often, that’s really a great advantage.

But what is the problem regarding merges?

Few centralized source control systems ever adopted the "three-way merge" which is the big thing that makes git merges seem relatively magic in comparison. It was an evolutionary pressure thing: not implementing it in a centralized system was a local maxima, when centralized it is easy enough to constrain merges to easier to reason with "two-way merges", and implementing "three-way merges" was a lot of work for little gain (it didn't sell enough of the centralized tools you never heard of or no longer remember that did invest into it). Meanwhile when assuming merges are distributed and entirely offline-first decentralized source control systems had to invest into the "three-way merge" problem and at this point git has invested more than just about any other source control system this side of "academia" (and source control systems you don't hear much about these days like darcs/pijul).

git makes merges much easier through a lot of hard work on its part because it has to in order to survive. A lot of centralized systems were really bad at merges but we put up with it because it mostly worked and it was "good enough".

Svn does do three-way merges, see the section "External diff" in the svn book.

One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits.

Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present.

In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.

git plumbing I believe can represent such merge DAGs (though possibly not with guaranteed semantics and in the category of "not well enough defined if you attempt it") but I don't think there's ever been a porcelain command in existence that can build/execute such merges. It's long been a complaint I have that cherry-pick is too rebase oriented. As someone who prefers "rebase never" approaches to git it irritates me that there isn't a non-rebase cherry-pick.

Probably going even further off topic, in general I find it irritating with git that there's so much vocal "the DAG is aesthetically displeasing when used as a DAG" support that it seems tough for git to realize the power of its own DAG and/or better encode things that should be encoded in the DAG such as partial merges (versus today just throwing away partial merge information in rebases and cherry-picks) just because it "looks ugly" when actually used as such. Aesthetics should be the last concern over beneficial behavior? Aesthetics can be bolted on with cleaner user interfaces but lost data is always lost data?

The very concept of the DAG makes it impossible to represent this situation. Am I overlooking something?

On branch B, we have this chain: [x]-->[y]-->[z]

And because x is a parent of y, if we record y as merged, then we also record x as merged. But the change wasn't in fact merged.

In order for the DAG to represent this correctly, we need a commit y' that doesn't have x as a parent. Then y' can be merged.

I don't believe that git tracks such relationships between commits y and y'.

The DAG is labelled. Most labels are boringly "parent: commithash". In the raw plumbing you can build other labels, a "cherry-picks: commithash" or a "replaces: commithash" or all sorts of things. git log won't follow such edges today, but it doesn't need to, and a lot of the folks that don't like the DAG aesthetically might prefer that anyway, but the assumptions that "parent: commithash" are the "only" edges in the DAG aren't baked in as much as people assume. For instance, think about git notes, they can have some pretty exotic edges. Again, not many people use that power today and most of the git "porcelain" has no idea what to do with it, but the DAG as a raw data-structure absolutely supports it.

Very interesting. Thank you so much for teaching me. I guess it would be possible to create a git plugin that tracks such picked cherries and that provides changed merge and rebase commands. (The plugin would use the existing plumbing to provide new porcelain.)

My current team relies on manual tracking: if there is a bug that needs to be fixed on a release branch and on the main branch, then the developer is responsible for adding commits to both branches. (Whether that is by making the commit on one branch and cherry-picking it to another, or by just making the change twice, is up to each developer.). I'm glad that everyone is so detail-oriented; normally we don't forget. But better support for cherry-picking would be quite useful imho.

> (and source control systems you don't hear much about these days like darcs/pijul)

A bit unfair, Darcs is indeed less fashionable nowadays because of performance issues on very large instances (which few projects actually have), Pijul solves these problems but is still alpha. In other words, this lineage of version control is between two different tools.

3-way merges suffer from two problems:

- They are not "associative", as mathematicians say, which means that if a remote branch has two commits A, followed by B, merging A then B might give you a different result from merging just B. Stockholm syndrome has convinced many programmers that this isn't a problem, but it actually prevents the very sane reviewing process of reading individual proposed changes along a branch. In other words, this is one of the main reasons Git users have to follow "flows".

- Conflicts! 3-way merge treats conflicts as a failure to merge, and tools based on 3-way merge (Git, SVN, Mercurial, Fossil, CVS…) stop everything when a conflict happens. Now, remember that these tools are based on snapshots, and snapshots can never have conflicts. Therefore, conflict resolutions are forgotten, the only thing remembered is that "Commit [insert SHA1-hash] (Revision number [insert integer] in SVN) comes after these two parents". This is so wrong that Git even has a command to "pseudo-fix" it, called `git rerere`. Again, if this doesn't sound like a problem to you, this could be because Stockholm syndrome taught you that the tool gets upset if you merge from the same remote branch twice, or if you fork a branch that isn't called "master" and isn't on GitHub. In other words, because you're actually using a centralised version control tool ;-)

It's been maybe 10 years since I last used SVN so I don't remember exactly, but it was related to moving commits between trunk and maintenance/feature branches and back. I managed to mess up whole repository few times. It might have been my own ignorance though, I was a fresh junior at the time.

On the other hand with git I had less issues related to merging, after playing for couple of hour it just all made more sense.

Git has become so ubiquitous that I'd find it weird if a recent project was using anything else.

Even if most devs don't know even 10% of it (I'm in this category and I don't care), same goes with my car: It can drive very fast but I limit its speed to something I can control.

The analogy is a bit weak but in general I see no problem not using something to it's full potential.

> It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys".

People are still saying this? I remember hearing this around 2007 when I started to use git. It's completely wrong. How would I, as a single developer alone, even use CVS or SVN? Have my own server running locally? I tried that and it sucked. Maybe there's some other tool I could use instead, well now I have to learn two tools. Git is popular because it works at all scales.

I worked with SVN briefly as it was out of fashion by the time I entered the workforce, but one thing I remembered about SVN was that there was a lack of standardisation between the clients.

I created the project using tortoiseSVN and any time a team member tried to add to it using a different client than tortoiseSVN it'd corrupt the entire repository!

That doesn't sound right. Actual corruption of the repository can happen, but not by simply using another client than your team members.

May be you mean something more alike commiting non-standard line endings? That can easily happen in git too, e.g. when the .gitattributes is different between worktrees.

May have been the case, it was about a decade ago now!

Somehow tortoiseSVN solved those issues, perhaps they had some smarts to normalise the line endings?

In any event, I've never had a git repo become corrupted in such a way after many years of continuous usage, but SVN seemed to fall over in a light breeze.

One point to add to the XKCD - driving an automatic transmission car is "steering wheel, gas pedal, break".

Most people don't even realize that there are micro explosions there around 2k times per minute let alone rest of the magic that happens in a modern car.

No one reads car manual and probably no one uses most of options in their cars. But still it is such a useful tool that many cannot live without one just like nowadays devs cannot live without GIT.

So I think it is perfectly fine to use only couple commands and don't even think about distributed graph and then adjust/learn when you need to understand more.

Reply on news.ycombinator.com