merge conflict resolution - git automatically rename merged files -

i want create repository combination of 2 existing repositories.

the 2 repo's largely uncoupled there few meta files show in both repos, .gitignore, .gitattributes , readme.md.

the following reproduce situation.

mkdir repoa cd repoa git init  touch .gitignore touch readme.md mkdir adir touch adir/afile git add -a git commit -m"repoa"  mkdir repob cd repob git init  touch .gitignore touch readme.md mkdir bdir touch bdir/bfile git add -a git commit -m"repob"  mkdir repoab cd repoab git init git remote add repoa /path/to/repoa git remote add repob /path/to/repob git pull repoa master git pull repob master 

at point receive conflict message.

is there way, between git init repoab , git pull's can tell repoab automatically rename readme.md repoa readmerepoa.md , readme.md repob readmerepob.md.

further complexity arises .gitignore files. .gitignore file in repoab should combination of repoa/.gitignore repob/.gitignore rules repoab. perfect scenario here use same rename strategy readme.md files, repoa/.gitignore becomes repoab/.gitignorerepoa, similar repob. if there way include files in repoab/.gitignore.

i asked question yesterday possibility of .gitignore folders, containing multiple .gitignore files believe solve situation didn't garner attention.

another beast altogether .gitattribute's files, looking union of 3 files (repoa/.gitattributes + repob/.gitattributes + repoab/.gitattributes). .gitattributes folder may useful here well.

so issue have several of these simple conflict resolutions. it's no big deal merge files once. i'm going end same conflicts every single time pull either repo. i'm not sure if end problems because committing repoab/.gitignore put repoab's version of .gitignore ahead of repoa , repob.

---

update: example of think sort of meta-file management useful

suppose have application modeled mvc following simple directory tree.

myapplication/ --readme.md --.gitignore --.gitattributes --main.p --model/ ----myapplication.m --view/ ----myapplication.v --control/ ----myapplication.c --plugins/ 

this application works , foo allows plugins added.

i've designed myapplication can create plugin without modifying of code myapplication, when runs, main.p grab plugins finds in plugins directory, plugins responsible own model/view/control files.

so want start working on new plugin, plugina. rather cloning myapplication , starting work, can create repository plugina, repository contains following.

myapplication/ --readme.md --.gitignore --.gitattributes --model/ ----plugina.m --view/ ----plugina.v --control/ ----plugina.c --plugins/ ----plugina.p 

now create new repository used developing , testing plugina.

this repository merger of myapplication , plugina, created in same manor created repoab above. have merge conflicts .gitignore , readme.md

myapplication/ --readme.md (conflict plugina/myapplication) --.gitignore (conflict plugina/myapplication) --.gitattributes --main.p --model/ ----myapplication.m ----plugina.m --view/ ----myapplication.v ----plugina.v --control/ ----myapplication.c ----plugina.c --plugins/ ----plugina.p 

not huge problem, handle conflict , can continue dev. conflicts undoubtedly lower number of times commit or update code, knowing have hurdle.

with technique can have large number of plugins , can create version of myapplication random collection of plugins. since i'm using repositories rather copy/pasting plugin code can have benefits of version control plugins in repo makes use of them, can keep plugins date, if find global issue plugin can push plugin repo, if plugin update doesn't work repo can roll back.

this whole workflow held trivial hurdle of these constant merge conflicts.

git isn't built sort of thing. you're going have merge conflicts coming repos , b, , if there way set rules want, no more work script perform renames , concatenations you're describing.

the closest thing can using git submodules. lets put repo , repo b subdirectories in repo ab. remain totally independent in subdirectories, repo ab maintains state - basically, ab tracks version of each checked out.