Re: Merging submodules

["H.Merijn Brand" <h.m.brand@xs4all.nl>]

On Fri, 1 Aug 2008 11:52:08 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:

> On Fri, Aug 1, 2008 at 09:04, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> >
> > Almost perfect now.
> >
> > 4gl/new 121 > git-ls-files | grep fnc_declare
> > include/fnc_declare.h
> > 4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> > commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> > Author: H.M. Brand <merijn@a5.(none)>
> > Date:   Tue Jul 29 16:45:43 2008 +0200
> >
> >    Backward comp functie voor PV indicatie
> >
> > diff --git a/fnc_declare.h b/fnc_declare.h
> > index acd686c..25d9a73 100644
> > --- a/fnc_declare.h
> > +++ b/fnc_declare.h
> > @@ -136,6 +136,11 @@ eaf_N Indicaties    ($x1);
> > :
> >
> > all the diffs are still showing as if they were against the folder they
> > were originally committed in. Is that correct? I would now have expected
> > something like
> 
> It is correct for old commits, when you look at an old commit it
> doesn't know that later it is merge in a subfolder. For new commits it
> depends on how you made them, in the modules and doing a subtree merge
> or directly in the "superproject".

After we join/merge these into the super-project, we're going to remove
the sup-repos, so all new commits will be made in the super-repo.

What I'm a bit worried about is that if people are looking for a change
in "include/inih001.h", they will not be able to find the commits on
that path, as the old commits have stored it without the path element.

Will that be a problem, or is git/gitk clever enough to still find
commits to both?

-- 
H.Merijn Brand          Amsterdam Perl Mongers  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/