Re: symlinked directories in refs are now unreachable

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

Matt Draisey [off-list ref] writes:

quoted

...  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.

quoted

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.

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)