{"id":10380,"date":"2022-09-23T13:51:17","date_gmt":"2022-09-23T08:21:17","guid":{"rendered":"https:\/\/jassweb.com\/solved\/solved-file-grained-vs-line-grained-version-control-systems\/"},"modified":"2022-09-23T13:51:17","modified_gmt":"2022-09-23T08:21:17","slug":"solved-file-grained-vs-line-grained-version-control-systems","status":"publish","type":"post","link":"https:\/\/jassweb.com\/solved\/solved-file-grained-vs-line-grained-version-control-systems\/","title":{"rendered":"[Solved] file grained vs line grained version control systems"},"content":{"rendered":"

[ad_1]
\n<\/p>\n

\n
\n
<\/div>\n
\n
\n

Your questions is too broad\/generic but I’ll try to give a shot anyways.<\/p>\n

Most merge strategies in modern Version Control Systems, can’t deal with the following:<\/p>\n

Suppose you have files A<\/code> B<\/code> C<\/code> in commit 001<\/code> in a repository.
\nDeveloper Dev1<\/code> branch of commit 001<\/code> and changes one line in file A<\/code>, commits as 001a<\/code>.
\nDeveloper Dev2<\/code> branch of commit 001<\/code> and changes the same line in file A<\/code> and commits as 001b<\/code>.<\/p>\n

If someone wants to merge commits 001a<\/code> and 001b<\/code>, the merge system wouldn’t be able to tell which is the correct change for the line, maybe the correct change for the project would be using the content in commit 001a<\/code> or maybe the one in commit 001b<\/code>, or maybe even mix of both changes in the line (that someone would have to create).<\/p>\n

That’s usually how you get a conflict that need manual intervention, because two developers are working in the same file and line and wrote different changes.<\/p>\n

In the rest of the cases the result is obvious:<\/p>\n