git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: Raul Dias <raul@dias.com.br>
Cc: git@vger.kernel.org
Subject: Re: same files on different paths on different branches
Date: Fri, 18 Mar 2011 10:20:33 +0100	[thread overview]
Message-ID: <1300440036.4261.29.camel@bee.lab.cmartin.tk> (raw)
In-Reply-To: <4D82A1F4.4060801@dias.com.br>

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.

   cmn

  reply	other threads:[~2011-03-18  9:21 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 [this message]
2011-03-18 13:12   ` Raul Dias

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=1300440036.4261.29.camel@bee.lab.cmartin.tk \
    --to=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=raul@dias.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).