3 ms·

That's true, but those are logical conflicts, that could arguably also be taken into account by a (much) smarter AI-powered VCS. The conflicts most people expe

by imiric 3y ago

That's true, but those are logical conflicts, that could arguably also be taken into account by a (much) smarter AI-powered VCS. The conflicts most people experience on a daily basis are with the tool being confused about changes to symbol names, function signatures, and with the context around the hunk changing, which has no relevance to the change itself. These can mostly be resolved by the tool having more awareness of the program structure, understanding the intention of the change, and knowing how to produce a valid result. Version control would be much more useful if the tools kept track of semantic changes in a project, instead of line-based differences without any awareness of the content. Existing semantic diffing tools show that this is indeed a better approach, but as pointed out[0], it's a very difficult problem to solve. [0]: https://news.ycombinator.com/item?id=37097171 https://news.ycombinator.com/item?id=37097171

kazinator 3y ago
> These can mostly be resolved by the tool having more awareness of the program structure, understanding the intention of the change, and knowing how to produce a valid result. If you have a three-way merge tool which does all these things, you can use it with Git. > Version control would be much more useful if the tools kept track of semantic changes in a project, instead of line-based differences without any awareness of the content. So the good news for you is that Git doesn't track any differences at all. Every commit stores a set of files, the "index". There is no limitation on how smart your merge tooling can be, as long as it can work with three artifacts: the ancestor code, and the two parallel derivatives of it to be merged. The idea that a version control must track detailed differences is false, and a bad requirement. Additionally, if the internal tracking representation has follow different syntaxes of umpteen languages, that's a hyperbad requirement.

by imiric 3y ago

kazinator 3y ago

> These can mostly be resolved by the tool having more awareness of the program structure, understanding the intention of the change, and knowing how to produce a valid result. If you have a three-way merge tool which does all these things, you can use it with Git. > Version control would be much more useful if the tools kept track of semantic changes in a project, instead of line-based differences without any awareness of the content. So the good news for you is that Git doesn't track any differences at all. Every commit stores a set of files, the "index". There is no limitation on how smart your merge tooling can be, as long as it can work with three artifacts: the ancestor code, and the two parallel derivatives of it to be merged. The idea that a version control must track detailed differences is false, and a bad requirement. Additionally, if the internal tracking representation has follow different syntaxes of umpteen languages, that's a hyperbad requirement.