Re: What is in git.git

Josef Weidendorfer [off-list ref] 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.

On Sunday 22 January 2006 03:44, you wrote:

	In commit 1:
		bind xxxxx... X/

Ah, OK, sorry.
This was a misunderstanding from my side; please forget the
other suggestion about change reference files, too ;-)

Josef