git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Deon George <deon.george@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Feature Enhancement Idea.
Date: Wed, 23 Sep 2009 22:56:52 -0700 (PDT)	[thread overview]
Message-ID: <m3bpl0c2cf.fsf@localhost.localdomain> (raw)
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>

Deon George <deon.george@gmail.com> writes:

> I'm not sure if this is the right place, but I thought I'd post my
> idea and maybe somebody will either redirect me to the right place, or
> give me that "that won't happen".
> 
> Im fairly new to GIT (wish I had discovered it long ago), and I really
> like using it - great work guys/garls :)
> 
> My idea is to enhance GIT to support (I'll call it) development
> "layers". The current design of GIT is that the working repository and
> working directory assume that all files belong together in the same
> project. I would like to see GIT go 3D and support layers, so that
> files (and/or file content) can belong to multiple repositories (or
> considered unique projects), even though the working tree presents all
> files as if they were one.

[cut very long description]

> Could this be included as part of GITs functionality (or is it
> possible already) ?

First, I assume there that you do not allow for the same file to
belong to different repositories.

Second, if all parts that you want to belong to other repository are
in separate subdirectories, and all files in those subdirectories
belong to this other repository, you can try either submodules 
(git-submodule), or subtree (subtree merge, or third-party git-subtree
helper).  Note also that this assume that you want to have 'master'
repository which indirectly or directly has al the files.


Third, if the above isn't what you want, then you can manually
intermingle working directories of different git repositories
(probably requiring decouplig of bare git repository (git-dir)
from working area (work-tree)).  Git repository know what files
it tracks, so you would only need to take care to ignore files
that belong to other repositories.

If it is to manual for you, and to error prone, you are welcome
to come up with set of scripts implementing "layers" feature you
want.  That is how initial version of submodule feature was done...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  parent reply	other threads:[~2009-09-24  5:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  6:17 Feature Enhancement Idea Deon George
2009-09-23  8:26 ` Christian Couder
2009-09-23  9:06 ` Johan Herland
2009-09-23 11:12   ` Deon George
2009-09-23 18:17     ` Ciprian Dorin, Craciun
2009-09-23 23:19       ` Johan Herland
2009-09-23 20:08 ` Junio C Hamano
2009-09-24  5:52   ` Deon George
2009-09-24  5:56 ` Jakub Narebski [this message]
2009-09-24  9:25   ` Deon George
2009-09-24 16:45     ` Eric Raible

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=m3bpl0c2cf.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=deon.george@gmail.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).