same files on different paths on different branches

> Hi,
> 
> I want to know if the following is possible to accomplish with git.
> (please reply to me too)
> 
> A project is composed of many sub-modules (not in git sense).
> These sub-modules are developed independently of the main project.
> They need to be reattached to the projects' tree.
> 
> The problems:
>     1 - a sub-module's tree does not have any projects file.
>     2 - when a sub-module is re-attached to the main project, its files
> are spread in many places (different from the the sub-module layout).
> 
> 
> Ideally the project would understand which files are the same, even on
> different places and apply the changes in the right files.
> This way a merge/cherry picking would keep the history information.
> 
> Is it possible to accomplish something similar to this?
> I understand that this is not how a git super-project works.
> I don't think it is possible with different git repositories.
> 
> I tried with a empty branch technique. 
> Created an empty branch with no history.
> Started a sub-module (non git) there and tried to propagate the changes.
> Git almost did the right thing.
> A change in branch submodule's
>     /foo/a.txt
> should have gone to branch master's
>     /bar/foo/a.txt
> but instead it went to
>     /bar/somethingelse/a.txt (which is the same as /bar/foo/a.txt)

> On jue, 2011-03-17 at 21:06 -0300, Raul Dias wrote:
>> Hi,
>>
>> I want to know if the following is possible to accomplish with git.
>> (please reply to me too)
>>
>> A project is composed of many sub-modules (not in git sense).
>> These sub-modules are developed independently of the main project.
>> They need to be reattached to the projects' tree.
>>
>> The problems:
>>     1 - a sub-module's tree does not have any projects file.
>>     2 - when a sub-module is re-attached to the main project, its files
>> are spread in many places (different from the the sub-module layout).
>>
>>
>> Ideally the project would understand which files are the same, even on
>> different places and apply the changes in the right files.
>> This way a merge/cherry picking would keep the history information.
>>
>> Is it possible to accomplish something similar to this?
>> I understand that this is not how a git super-project works.
>> I don't think it is possible with different git repositories.
>>
>> I tried with a empty branch technique. 
>> Created an empty branch with no history.
>> Started a sub-module (non git) there and tried to propagate the changes.
>> Git almost did the right thing.
>> A change in branch submodule's
>>     /foo/a.txt
>> should have gone to branch master's
>>     /bar/foo/a.txt
>> but instead it went to
>>     /bar/somethingelse/a.txt (which is the same as /bar/foo/a.txt)
>  If the problem you are seeing here is that git reports the physical
> path instead of the logical one (compare `pwd -P` and `pwd -l`), then it
> shouldn't really represent a problem, as the data is being written in
> the right places.
>
>> So is it possible to get closer to this with git  in a way or another?
>  git uses almost exclusively physical paths internally, which is why the
> user sees them. For example, this also happens:
>
>    carlos@bee:~/apps$ mkdir one
>    carlos@bee:~/apps$ ln -s one two
>    carlos@bee:~/apps$ ln -s two three
>    carlos@bee:~/apps$ cd three
>    carlos@bee:~/apps/three$ git init
>    Initialized empty Git repository in /home/carlos/apps/one/.git/
>
>  Notice how git is reporting the "right" path.
>
>  Is this the effect you're seeing? Above it's not clear whether you're
> using symlinks in your file system or why /bar/somethingelse/a.txt is
> the same as /foo/a.txt.