From: Ray Lehtiniemi <rayl@mail.com>
To: CPD <cdavidson@altsoftware.com>
Cc: git@vger.kernel.org
Subject: Re: Can you do this with GIT?
Date: Fri, 27 Jul 2007 13:52:11 -0600 [thread overview]
Message-ID: <200707271352.11147.rayl@mail.com> (raw)
In-Reply-To: <11834063.post@talk.nabble.com>
On Friday 27 July 2007 12:02, CPD wrote:
> We produce variations based on a (mostly) common codebase. In CVS I set up
> "environment" modules for each platform, then when you are working on that
> platform, you simply check out the correct environment and build. Only the
> needed code and tools are exposed in that environment (this is important as
> clients must NOT see each other's code and most customers have some
> customization). I do this by defining and renaming modules in the CVSROOT
> modules file.
this sounds very close to what i'm trying to achieve at the moment.
> Does GIT support anything like this? Or another way to acheive the same
> end?
i couldn;t find any ready way to do it.... but i've hacked up a few
preliminary thoughts on how this might work in git. comments and feedback
are welcome :-)
the basic idea is to import each snapshot of each vendor release as a tagged
root commit, then push all these tagged root commits into a central "library"
repository. each tagged root commit stands alone and functions as a cvs
module.
library repos are set up as remotes under git, and a simple script will import
a set of snapshots into a brand new project as a baseline for customization.
the three shell scripts, and the two control files used by them, are included
here:
==> vendor-tracking.sh <==
###########################################################
#
# Import a vendor snapshot into a "library" repository.
#
# To import a vendor snapshot, unzip the snapshot into
# a new folder. Then go into the folder and type
#
# xxx-import <library> <tag>
#
# This will create an empty git repo in the current
# snapshot folder and create a root commit in
# it which holds the snapshot. This root commit will be
# tagged as "tag" and then pushed into the "library" repo.
#
# No error checking is done.
#
###########################################################
xxx-import ()
{(
repo=$1
tag=$2
export GIT_DIR=/tmp/$$.$tag
rm -rf $GIT_DIR
mkdir -p $GIT_DIR
git init
git add .
git commit -s -m "Import $tag"
git tag $tag master
git push $repo refs/tags/$tag:refs/tags/$tag
rm -rf $GIT_DIR
)}
###########################################################
#
# Use a vendor release in the current project.
#
# To use a copy of some vendor snapshot in the current
# project, go to the top level of your current project,
# then type
#
# xxx-use <library> <tag> <path>
#
# The tagged snapshot will be fetched from the library
# and deposited into the <path> subdirectory, then committed
# to the project.
#
# No error checking is done.
#
###########################################################
xxx-use ()
{(
repo=$1
tag=$2
path=$3
git fetch $repo refs/tags/$tag:refs/tags/$tag
git read-tree --prefix=$path/ $tag
git commit -s -m "Use $tag as $path"
)}
###########################################################
#
# Create a new project from a set of vendor components.
#
# To start a new project with a known array of vendor
# components, create a remotes file describing the libraries
# and an manifest file describing the components and how they
# will be used. Then, in a new folder, type
#
# xxx-start <remotes> <manifest>
#
# This will create a new Git project in the current folder,
# add a remote for each library repository, then proceed to
# fetch and commit each vendor component into the new project.
# The new project is now ready to be customized.
#
# No error checking is done.
#
###########################################################
xxx-start ()
{(
remotes=$1
manifest=$2
git init
cat $remotes |
while read name url
do
git remote add $name $url
done
cat $manifest |
while read path remote tag
do
xxx-use $remote $tag $path
done
git checkout -f master
)}
==> remotes <==
lib1 ssh://me@home.com/home/me/work/library
lib2 //filesrv/git/library
==> manifest <==
path/to/A lib1 vendorA/componentA/version1
path/to/B lib2 vendorB/componentB/version2
i would prefer to import and tag raw tree objects, since i get some of my
snapshots as pre-assembled collections of (modified copies of) several
components. it would therefore be convenient to have several tags per
snapshot pointing at the subtrees corresponding to each component. however,
fetch and push seem to prefer commits over trees....
as it stands, the vendor snapshots have no "history" to them. each snapshot
stands in isolation. there was an interesting thread a few days ago about
importing ancient kernel history as a series of trees, then "stitching
together" a "synthetic history" from a collection of trees. i would see
something like that as the basis for "vendor tracking branches", which could
be restitched if an older snapshot is received "out of order".
hope it helps
ray
prev parent reply other threads:[~2007-07-27 19:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 18:02 Can you do this with GIT? CPD
2007-07-27 19:05 ` Johannes Schindelin
2007-07-27 19:45 ` Ray Lehtiniemi
2007-07-27 19:49 ` Johannes Schindelin
2007-07-27 20:08 ` Ray Lehtiniemi
2007-07-27 19:45 ` Linus Torvalds
2007-07-27 19:52 ` Ray Lehtiniemi [this message]
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=200707271352.11147.rayl@mail.com \
--to=rayl@mail.com \
--cc=cdavidson@altsoftware.com \
--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).