4 ms·

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 m

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.

hibbelig 5y ago
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?
- WorldMaker 5y ago
  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".
  - hibbelig 5y ago
    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.
    - WorldMaker 5y ago
      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?
      - hibbelig 5y ago
        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'.
        WorldMaker 5y ago
        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.
  - pmeunier 5y ago
    > (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.
- pmeunier 5y ago
  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 ;-)
- frant-hartm 5y ago
  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.

hibbelig 5y ago

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?

WorldMaker 5y ago
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".
- hibbelig 5y ago
  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.
  - WorldMaker 5y ago
    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?
    - hibbelig 5y ago
      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'.
      - WorldMaker 5y ago
        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.
- pmeunier 5y ago
  > (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.
pmeunier 5y ago
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 ;-)
frant-hartm 5y ago
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.