Re: What is in git.git

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> The original gitlink proposal did exactly this: it recorded
> the place where a subproject is bound by putting a gitlink into
> a tree. This way, the binding point can be changed, and is subject to
> versioning itself.
>
> I just realized that this is not currently possible with the bind lines.
> What about the following usage szenario:
> - in a superproject, I use a subproject X implementing some lib by 
>   binding it at X/. My Makefile recurses into X/ for this.
>   This is recorded at commit point (A)
> - later on, I realize I need another lib from a probject Y; I want
>   to put the libs X and Y into subdirectory lib/ of my superproject;
>   i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.
>   The Makefile is changed accordingly to build the subprojects.
>   This is recorded at commit point (B)

The original gitlink proposal records commit object name in the
link object itself, so do bind lines in the commit object in
bound commit proposal.  In either way, you need to deal with the
subproject relocation at the Porcelain level.

I was hoping that, upon seeing these two commits (let's say we
are dealing with two-way merge aka "checkout"):

	In commit 1:
		bind xxxxx... X/

	In commit 2:
		bind yyyyy... lib/X/
                bind zzzzz... lib/Y/

the tool could notice that xxxxx... and yyyyy... are related in
their ancestry chain, detect the relocation of subprojects, and
update the $GIT_DIR/bind file (maybe with some help from the end
user).  We can do something similar in gitlink approach as well.

> A $GITDIR/bind alone will no work, as moving back to (A) would keep
> the binding point of subproject, and make is broken.

I do not see why.  $GIT_DIR/bind can be adjusted by the tool
upon checkout to reflect the reorganized tree.

> What about putting $GITDIR/bind information directly into reference files?
>
>  $HOME/gitproj> cat .git/refs/heads/master
>  92347432598...
>  bind main=/
>  bind subpro=sub/

I think that would also work.  Although I do not immediately see
major difference in expressiveness either way, that may be a
cleaner way to achieve what we want to do.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html