On 07/10/2021 10:04, Magnus Therning wrote: > > skybuck2000 <skybuck2...@hotmail.com> writes: > >> Here is a "real-world" example: >> >> The original repository is this one: >> https://github.com/PascalCoin/PascalCoin >> >> My restructured repository is this one: >> https://github.com/SkybuckFlying/PascalCoinRestructured > > I only took a quick glance at the two repositories, but it seems you > are in a situation where > > 1. You have a branch with major changes > (https://github.com/SkybuckFlying/PascalCoinRestructured/commit/b6eb90bbb95c40494838a61b0e52c3dc62ab508b > has >10k lines that are changed across 84 files!), and > 2. your branch has lived for a long time (3 years), and > 3. your branch is 3 years behind the upstream master branch. > > I can't help but feel a little sorry for you. > > Maybe that https://github.com/mhagger/git-imerge can help you out of > the predicament you've put yourself in. > > /M > A thought experiment about possible procedure and process...
The git diff used for creating patches that represent the changes will extract hunk headers which are meant to represent logical segments of the code. If the files were 'split' at these logical segment headers (that split then promotes each filename to be a directory name, and each segment becomes a file e.g. named with its line range `fileL73-95`), and this split was done for both sides of the merge, then it maybe a reasonable candidate for the new merge -sORT capability which should be a lot better at detecting the file renames and code movements. I guess that the file-with-line-range naming wouldn't work because then everything looks like a rename, but file-with-segment-name should be a lot more stable. Even better would be the compiler's parser for the code that would just split out the major 'functional' segments that the code syntax already defines. It all sounds like those interview questions where you have to tie the pliers to the string and start it swinging so that you can catch it while reaching something else... -- Philip -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/ecb860f2-2c4a-6f70-92d6-d7e214b8f760%40iee.email.
