Re: fixing workdirs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pierre Habouzit <madcoder@xxxxxxxxxx> writes:

> On Thu, Jul 08, 2010 at 12:40:11PM -0700, Junio C Hamano wrote:
>> Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
>> 
>> > for the first one, the fix is simple: workdirs have now a name, and
>> > their HEAD reflog lives in the "master" git repository reflog namespace
>> > under logs/workdir/$workdir_name/HEAD. The workdir HEAD reflog is then a
>> > symlink to the masters.
>> 
>> I think this is a sane thing to do, except for the "symlink" part but that
>> would be just a minor implementation detail.
>
> What would you suggest instead of the symlink then ? (knowing that all
> the workdir is just a full symlink farm at them moment).

I can imagine that we may want to have a general mechanism to help an
object store that belongs to one "primary" repository be aware of ref-like
things that live outside of the repoistory itself, and not just a special
purpose hack suitable only to handle the workdirs.  E.g., we have talked
about a "fork" created by "clone -s" wanting the forkee repository to be
aware of its refs, so that rewinding the refs in the forkee repository and
then running gc there won't remove the objects now unnecessary in the
forkee but still needed by the forker repository.

It shouldn't be hard to do something similar to "gitdir: " support for
this without using a symlink, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]