Re: Managing multiple branches in git

On 6/2/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Hmm, but is there a way to create those clones from a single local
> > "database"?
>
> > (I like the monotone model much better. This mixing of working copies
> > and databases as if they were a single thing is silly and uncomfortable
> > to use.)
>
>
> I agree, .git as a subdirectory of the working directory doesn't make
> much sense to me.
>
> I wondered for a second about symlinking .git from several checkout
> directories to a common master, but AFAICT .git stores both the
> "repository" and status information about the current checkout, so
> that's not gonna work.

You cannot share .git, but you can share object directory (.git/objects).
Which contains the bulk data. There are various ways to do it, symlink
should be one of them.

> In the one large project that I have a git tree for, .git seems to
> eat only about as much disk space as the checkout (so apparently the
> compression is pretty effective). So it wouldn't be totally impractical
> to have a separate repository for each branch, but it sure seems like
> an ugly and klugy way to do it. And we'd still end up with the "same"
> commit on different branches appearing entirely unrelated.
>
> At the same time, I don't really buy the theory that relating commits on
> different branches via merges will work. In my experience it is very
> seldom the case that a patch applies to each back branch with no manual
> effort whatever, which is what I gather the merge functionality could
> help with. So maybe there's not much help to be had on this ...

Sure, if branches are different enough, the merge commit would
contain lot of code changes. But still - you would get single "main"
commit with log message, plus bunch of merge commits, which may be
nicer than several duplicate commits.

--
marko