git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: What is in git.git
Date: Sat, 21 Jan 2006 18:44:06 -0800	[thread overview]
Message-ID: <7v64odj821.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <200601220033.26321.Josef.Weidendorfer@gmx.de> (Josef Weidendorfer's message of "Sun, 22 Jan 2006 00:33:25 +0100")

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.

  reply	other threads:[~2006-01-22  2:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-21  8:03 What is in git.git Junio C Hamano
     [not found] ` <200601211524.03096.lan@ac-sw.com>
2006-01-21 10:33   ` Alexander Litvinov
2006-01-21 10:36 ` Alexander Litvinov
2006-01-21 19:37   ` Junio C Hamano
2006-01-21 22:22     ` Junio C Hamano
2006-01-21 23:33     ` Josef Weidendorfer
2006-01-22  2:44       ` Junio C Hamano [this message]
2006-01-24  1:52         ` Josef Weidendorfer
2006-01-22  3:12       ` Petr Baudis
2006-01-22 17:53       ` Daniel Barkalow
2006-01-22 20:08         ` Junio C Hamano
2006-01-22 20:26           ` Daniel Barkalow
2006-01-22 20:35             ` Junio C Hamano
2006-01-22 20:41       ` Junio C Hamano

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=7v64odj821.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Josef.Weidendorfer@gmx.de \
    --cc=git@vger.kernel.org \
    /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).