Split all at once so far not succeeded, individual branches offer some help, by allowing git -mv to indicate to git that a big file was renamed/reduced to a small file.
Then later all individual branches can be merged to produce a build. The problem with this is if changed are done to the new build, and later to old build, changes from new build get lost or have to be re-applied to individual branches again. What I would need here is a way to tell git that a big file should be copied/applied multiple times to individual parts/files ? So for example: Apply BigFile to LittleFile1 LittleFile2 LittleFile3 There seem to be some git plumbing commands. Maybe there is some plumbing command that can help with this. Bye for now, Skybuck. On Tuesday, November 23, 2021 at 1:30:48 AM UTC+1 skybuck2000 wrote: > GIT: Split file into multiple files, then detect changes in updated > original file and apply to multiple files. > > File Original contains: > > ObjectA > > Some funtions for Object A > > some more functions for Object A > > ObjectB > > Some functions for Object B > > some more functions for Object B > > ObjectC > > Some functions for Object C > > some more functions for Object C > > > This should be split up into three files: > > ObjectA > > ObjectB > > ObjectC > > > Such that File ObjectA contains: > > ObjectA > > Some funtions for Object A > > some more functions for Object A > > > Such that File ObjectB contains: > > ObjectB > > Some funtions for Object B > > some more functions for Object B > > > Such that File ObjectC contains: > > ObjectC > > Some funtions for Object C > > some more functions for Object C > > > Later file Original is updated: > > ObjectA > > Some funtions for Object A > > some more functions for Object A > > even more functions for Object A > > ObjectB > > Some functions for Object B > > some more functions for Object B > > even more functions for Object B > > ObjectC > > Some functions for Object C > > some more functions for Object C > > even more functions for Object C > > > Is it somehow possible to use git to automate the updating of File > ObjectA, File ObjectB File ObjectC so that all three files contain the new > line such that: > > > Such that File ObjectA contains: > > ObjectA > > Some funtions for Object A > > some more functions for Object A > > even more functions for Object A > > > Such that File ObjectB contains: > > ObjectB > > Some funtions for Object B > > some more functions for Object B > > even more functions for Object B > > > Such that File ObjectC contains: > > ObjectC > > Some funtions for Object C > > some more functions for Object C > > even more functions for Object C > > > This is a scenerio where the original file is updated by a different user. > > It would be very nice if a feature git had this detection capability for > two reasons: > > 1. > > Big teams/projects that might not want to freeze such a big fle. > 2. > > No-cooperating teams/repository that don't want to split the file. > > > Now that I understand git a little bit better, very maybe this will work: > > What could be tried for the split dilemma, is the following idea: > > > 1. The original document.txt is splitted in a "split commit" such that > objecta.txt objectb.txt and objectc.txt exist. > > 2. This "split commit" can be isolated on top of original document.txt or > anywhere basically. > > 3. Then when original document.txt is updated, try and reapply the "split > commit", by basically re-basing it on top of the updated document.txt > > So in git terms the idea is as follows: > > BranchOriginalDocument commit 1 > document.txt > BranchSplittedDocument commit 2 > objecta.txt > objectb.txt > objectc.txt > (could even be placed on their own sub branch if necessary because one > branch might not be enough) > BranchUpdatedDocument commit 3 > document.txt > > now after after commit 3 is done, commit 2 could be rebased onto commit 3 > in the hopes that git will recgonize the split operation and maybe > repeat it on top of document.txt with updated contents. > > the git command for this would like something like: > > git rebase --onto BranchUpdatedDocument BranchOriginalDocument > BranchSplittedDocument > > tomorrow I will give this a try to see how far I get with this. > > If it fails one more try would be to create additional branches or so, I > saw somebody mention in the past that that might work. > not sure if they should be based on each other, but maybe... or seperate > branches could be tried as well, all based on branch splitted document. > > BranchSplittedDocument > BranchA > BranchB > BranchC > BranchUpdatedDocument > > (I am not sure if I have tried this before, maybe, but I understand git > rebase a little bit better now, and git in general ! ;)) > > Any suggestions are welcome ! > > Bye, > 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/c56d6982-d04b-4ac5-83ea-60bce864311en%40googlegroups.com.
