4 ms·

Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantl

Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.

throwawayadvsec 3y ago
well merging two wildly different of files is going to be complicated using any tool, git is not the issue there, there isn't a million ways to handle this
- dmoy 3y ago
  Right it's a use type thing. If everyone develops from master branch and makes small incremental changes, no problem even if it's git. If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either. If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
- nirimda 3y ago
  There's three ways. One is the git way, which is to let people do whatever and then ask them to handle it afterwards. The next best is used by some other annoying system I used early in my career, which is to require people to check out a file before they can get write permission on it, and only allow one person to have write permission at once, so that there's no real risk of merges. And the worst of all is to just let whoever comes later overwrite whatever was there before.
jdmichal 3y ago
I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.
- HWR_14 3y ago
  Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
  - jdmichal 3y ago
    Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge. I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
    - HWR_14 3y ago
      Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial). A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it. But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
prettyStandard 3y ago
I love rebasing. As for dealing with merge conflicts, it's called - keep up to date with the branch your tracking - merge frequently - get on a call when you do have merge conflicts - avoid having multiple people working in the same files simultaneously if possible The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.
- yjftsjthsd-h 3y ago
  > As for dealing with merge conflicts, it's called That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
jcranmer 3y ago
Mercurial's phases and changeset evolution make specifically rebasing far less painful. git rebase -i is downright antediluvian in comparison.
prepend 3y ago
Merges are hard and I’ve never seen a system that removes the difficulty. I actually think git is the best because it’s easier to branch and update than many others (a pull takes a second to refresh vs quite a while for large repos with svn). I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
adastra22 3y ago
The solution is darcs’ patch-theory model of development, currently being pushed forward by pijul.
- gavinhoward 3y ago
  I am making a VCS to compete against Git and Pijul. The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt. But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
  - adastra22 3y ago
    Please share when it is ready!
    - gavinhoward 3y ago
      Absolutely! I am planning to make a "Show HN" my official announcement, but only after it is self-hosting and has enough features to replace my Gitea instance.

Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.

throwawayadvsec 3y ago

well merging two wildly different of files is going to be complicated using any tool, git is not the issue there, there isn't a million ways to handle this

dmoy 3y ago
Right it's a use type thing. If everyone develops from master branch and makes small incremental changes, no problem even if it's git. If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either. If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
nirimda 3y ago
There's three ways. One is the git way, which is to let people do whatever and then ask them to handle it afterwards. The next best is used by some other annoying system I used early in my career, which is to require people to check out a file before they can get write permission on it, and only allow one person to have write permission at once, so that there's no real risk of merges. And the worst of all is to just let whoever comes later overwrite whatever was there before.

jdmichal 3y ago

I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.

HWR_14 3y ago
Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
- jdmichal 3y ago
  Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge. I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
  - HWR_14 3y ago
    Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial). A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it. But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.

prettyStandard 3y ago

I love rebasing. As for dealing with merge conflicts, it's called - keep up to date with the branch your tracking - merge frequently - get on a call when you do have merge conflicts - avoid having multiple people working in the same files simultaneously if possible The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.

yjftsjthsd-h 3y ago
> As for dealing with merge conflicts, it's called That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"

jcranmer 3y ago

Mercurial's phases and changeset evolution make specifically rebasing far less painful. git rebase -i is downright antediluvian in comparison.

prepend 3y ago

Merges are hard and I’ve never seen a system that removes the difficulty. I actually think git is the best because it’s easier to branch and update than many others (a pull takes a second to refresh vs quite a while for large repos with svn). I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.

adastra22 3y ago

The solution is darcs’ patch-theory model of development, currently being pushed forward by pijul.

gavinhoward 3y ago
I am making a VCS to compete against Git and Pijul. The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt. But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
- adastra22 3y ago
  Please share when it is ready!
  - gavinhoward 3y ago
    Absolutely! I am planning to make a "Show HN" my official announcement, but only after it is self-hosting and has enough features to replace my Gitea instance.