Re: symlinked directories in refs are now unreachable

From: Matt Draisey <mattdraisey@sympatico.ca>
Date: Aug 15, 2005, 09:01 UTC
Message-ID: <1124096475.749.64.camel@della.draisey.ca>
In-Reply-To: <7v1x4v4pfx.fsf@assigned-by-dhcp.cox.net>

On Mon, 2005-08-15 at 00:41 -0700, Junio C Hamano wrote:

Show 14 quoted lines

> Matt Draisey <mattdraisey@sympatico.ca> writes:
> 
> > ...  My own programming efforts rarely exceed two or three files
> > per project, and don't justify there own .git/objects repository.
> > Still, a few projects do benefit from having their own commit history,
> 
> I am afraid I am not quite getting it.
> 
> You are interested in many projects that have outside upstream,
> and you typically modify only small portion of each of them,
> which is quite a typical behaviour for individual developers.
> For some reason you want to keep those repository "clean"
> without your own commit objects or changed objects only
> reachable from your commits.  Is it what is happening here?

No, all the projects are my own. I am not a developer at all, merely a hobbyist. Upstream projects don't fit into this scheme.

Show 14 quoted lines

> > I've only written a commit tool.  All the other git and cogito tools I
> > invoke from the outermost directory like so 
> >
> > $git-cat-file commit per/Minesweeper/master
> >
> > Symlinking still works here as expected.  The per directory is just
> > there so I don't stomp on the outermost namespace, the Minesweeper is a
> > symlink to the nested project's refs directory.
> 
> Hmm.  So you have two GIT managed trees, $D/matt and $D/Minesweeper,
> and a symlink between them like this.  Is that what is happening here?
> 
>   $D/matt/.git/refs/heads/per/Minesweeper -> $D/Minesweeper/.git/refs/heads
>

No, they are nested

    $D/.git/refs/heads/per/Minesweeper -> $D/Minesweeper/.git/refs/heads

The outermost repository merely aggregates a bunch of small unrelated projects that are not yet ready for an independent existence. The idea is to put everything under revision control in the hope that eventually something useful falls out.

My commit tool walks up the chain towards root until it finds the objects directory and does the appropriate thing.

Show 20 quoted lines

> Of course 'git-cat-file commit per/Minesweeper/master' would
> work in "$D/matt" directory.  How do the set of paths recorded
> in the index file used in these repositories relate to each
> other?  Is $D/matt/ tracking the same set of files as the other
> repository tracks?  Is it meant to be a superset?  Subset?  More
> or less independent "private additions"?
> 
> There must be some advantage to this arrangement than the more
> typical arrangement I've seen people do, which is to have two
> branches in Minesweeper (that is the upstream, right?)
> repository, one "origin" and the other "master".  Upstream
> changes you fetch and pull into "origin" branch while you commit
> your changes to "master" branch.  I just do not yet see what
> that advantage is, and I strongly suspect because I misread your
> description and misunderstood the two repository arrangement you
> have and how they are used.
> 
> By the way, did you want to take this discussion private or was
> it by accident you did not CC: the list?
>

No, I didn't want to take it private. I just don't know how my email programme works. I also just discovered that Evolution's Forward As > Redirect is really a bounce and not a forward at all (it doesn't change the to: address)