On Sunday, September 12, 2021 at 11:20:51 AM UTC+2 philip...@iee.email wrote:
> Have you looked at the various --pickaxe and other file-following options > that can be set to different levels of similarity for the tracking of such > splitting and changing. > No. > Sometimes the real problem is that the 'local' feature branch policies > (i.e. your corporate way of doing things) can be in conflict with the > underlying Git (Linux/Linus) philosophies of small changes, short lived > branches, no mega-merges, etc. such that the apparent conflict resolutions > (or failure to detect code movement) is easy for the dev to use git (with > those extra parameters) to simply resolve the conflicts... > > I guess Git hopes that the dev provides the `deep learning [caffeine > fuelled?] neural brain`.. ;-) while it provides some aggressive tools to > follow those splits. > > Also look out for the discussions on the Git mailing list for the > forthcoming ORT merge strategy (i.e. the `-sort` option ;-) > > https://blog.palantir.com/optimizing-gits-merge-machinery-part-v-46ff3710633e > > https://lore.kernel.org/git/CABPp-BGR3dfJE7TZ+jkjDdWyeXYowmJhtoFaQ8_Abn=zro...@mail.gmail.com/ > > <https://lore.kernel.org/git/CABPp-BGR3dfJE7TZ+jkjDdWyeXYowmJhtoFaQ8_Abn=zroh...@mail.gmail.com/> > > (as a starter) > > If you have some shareable examples then the author of ORT would be > interested in those tricky cases. > In the past I tried this: https://www.reddit.com/r/git/comments/kjcdyz/git_split_file_into_multiple_files_then_detect/ With some splitting techniques from somebody at microsoft. These splitting techniques provided not to be sufficient. Perhaps the example is to simple. Perhaps code recognition and deep learning is too difficult and too CPU expensive. One possible idea that comes to mind inspired by your post is to allow a developer to manual specify "code segments" in the original file and where changes inside those code segments should go to which file. So for example a file could be "marked-up" as follows: [begin of split into file1.c] some code [end of split into file1.c] [begin of split into file2.c] [end of split into file2.c] [begin of split into file3.c] [end of split into file3.c] These mark ups could be put into a copy of the original fork file stored on the child fork file. Then git ignores these markups... but does understand better where parts of the original fork file should go into the child fork file. That should make it possible for git to improve it's splitting capabilities. This feature request allows more freedom for child forks to work they way the want to work. Later vice versa could be done as well if changes want to be send back to the original fork file. If you believe something like this can be done with --pickaxe or other git options give some examples or some links to further documentation. So far I have not yet found any good information about this. I am looking for something that can handle large files and multiple lines of splitting code... not just a single line. Bye for now, Skybuck. -- 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/bcf9ea8f-6f7e-4f5d-b934-67898bd73c0cn%40googlegroups.com.
