From: Raul Dias <raul@dias•com.br>
To: "Carlos Martín Nieto" <cmn@elego•de>
Cc: git@vger•kernel.org
Subject: Re: same files on different paths on different branches
Date: Fri, 18 Mar 2011 10:12:37 -0300 [thread overview]
Message-ID: <4D835A45.4070902@dias.com.br> (raw)
In-Reply-To: <1300440036.4261.29.camel@bee.lab.cmartin.tk>
On 03/18/2011 06:20 AM, Carlos Martín Nieto wrote:
> 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.
No they are completely different files that happened to have the same
content at that point.
-rsd
prev parent reply other threads:[~2011-03-18 13:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 0:06 same files on different paths on different branches Raul Dias
2011-03-18 9:20 ` Carlos Martín Nieto
2011-03-18 13:12 ` Raul Dias [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D835A45.4070902@dias.com.br \
--to=raul@dias$(echo .)com.br \
--cc=cmn@elego$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox