On Thu, Sep 24, 2009 at 09:55:49AM -0700, Konstantin Khomoutov wrote:
>
> On Sep 23, 5:42 pm, Simon wrote:
>
> > /base -- /common_dir1
> >\ \ \ /common_dir2
> > \ \ /site1
> > \ /site2
> >
> > What I'd like to do is to be able to setup a repository to track all
> > changes to /base, /common_dir1, /common_dir2 & /site1 and another
> > seperate repository to track /base, /common_dir1, /common_dir2 & /
> > site2.
>
> May be just create three repos: one for base + common_dir1 +
> common_dir2,
> and another two -- for sites?
> Then you could deploy each site like this:
> 1) Clone "common" repository and get the base directory with common
> dirs.
> 2) Clone the site repository under the base directory.
> 3) Add the just created site directory to the .gitignore site located
> under /base.
This sounds a little complex.
Perhaps the git way would be to have a base "master" branch
and N number of long-lived site specific topic branches.
You'd probably need to rework the directory structure
to make it so that each site has a completely self-contained
tree. They can't share common files (so there'll be
duplicate files on disk) but disk space is cheap
compared to the convenience it buys you.
Keep a different checkout (on a different branch) for
each site. It's simple, and you can still have them all
pointing to the same shared repo for pushing changes back
(each site pushes to a different branch, of course).
Keep the common and site-specific parts in different
directories. Then it'll be easier to know that changes
to them should happen in different commits.
Changes to the common part should ideally happen on the
common master branch. This branch gets merged into
the site branches as needed.
The beauty of it is that when you do happen to
accidentally commit to the wrong branch you can always
cherry pick that commit onto master -- just remember
to make changes to site and common in different commits.
> The compilcation is that whenever you modify both common files and
> site-specific files during one unit of work, you will need to commit
> (and push) updates separately in each repository. But as I understand
> submodules, they would require essentialy the same approach.
The approach I described doesn't remove the need to be atomic
in your changes to common and site, but it does let you do
without having to create a new repo everytime a new site
comes around. In my scheme new sites correspond to new
branches, and branches are cheap.
Another win from doing it this way is that you can easily
compare sites from anywhere.
e.g. from site1:
$ git fetch origin
$ git diff origin/site2
Have fun,
--
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en
-~--~~~~--~~--~--~---
