From: Petr Baudis <pasky@suse.cz>
To: Alexander Litvinov <lan@ac-sw.com>
Cc: git@vger.kernel.org
Subject: Re: Something looks like CVS modules
Date: Fri, 11 Nov 2005 22:29:53 +0100 [thread overview]
Message-ID: <20051111212953.GX30496@pasky.or.cz> (raw)
In-Reply-To: <200511111713.58018.lan@ac-sw.com>
Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> On Friday 11 November 2005 16:58, Petr Baudis wrote:
> > But this is troublesome, and doesn't fit into GIT's model at all. Do you
> > have any concrete example of a scenario where something like this would
> > be useful?
>
> For eaxmle: I have java lib A. I setup project B in this way:
> B/src/
> B/A/src
>
> Have another project C:
> C/src/
> C/A/src
>
> Both of them share the same code from library's module. I can tag them, edit,
> commit: do all work I usualy do. If I change something in B/A/src this will
> be updated into C/A/src.
Aha. So it isn't so much about modules, but more about nested checkouts,
described in Cogito's TODO as:
* Subprojects
Support a GIT project inside a GIT project:
x/.git
x/foo/bar/.git
x/foo/bar/baz/.git
x/quux/zot/.git
That means cg-update working recursively and cg-add'n'stuff
checking if there isn't another .git along the path of its
argument.
Needs more thought, especially wrt. fetching and merging
recursive semantics.
Yes, that would be nice - it is something that you get kind of for-free
in CVS given its internal architecture, but needs specially crafted
support in the GIT environment. But when thinking about it (and we
discussed it with Jonas during one night bike ride through Copenhagen
some time ago ;), most of the problems with fetching and merging
semantics turn out to be actually largely artificial, and just doing
the intuitively right thing should be ok.
Patches welcome. Otherwise, I will get to it, but not very fast. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
next prev parent reply other threads:[~2005-11-11 21:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-11 7:13 Something looks like CVS modules Alexander Litvinov
2005-11-11 8:05 ` Junio C Hamano
2005-11-11 10:28 ` Petr Baudis
2005-11-11 10:42 ` Alexander Litvinov
2005-11-11 10:58 ` Petr Baudis
2005-11-11 11:10 ` Sven Verdoolaege
2005-11-11 11:13 ` Alexander Litvinov
2005-11-11 21:29 ` Petr Baudis [this message]
2005-11-11 22:40 ` Josef Weidendorfer
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=20051111212953.GX30496@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=lan@ac-sw.com \
/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).