Julian Phillips [off-list ref] writes:
quoted
quoted
(1) We could by convention declare a worktree whose .git/refs
is a symlink, and have git-gc and friends check for it, and
either refuse to run or automatically chdir and run there.
If we were to do this, we probably should check more than
just .git/refs but some other symlinks under .git/ as well.
(2) We could dereference .git/packed-refs, when it is a
symlink, by hand, just like we dereference a symlink HEAD
by hand (see resolve_ref() in refs.c), and run the
creat-to-temp-and-then-rename sequence to update the real
file that is pointed at by it.
Its not all the clear which one is the best, but (2) sounds as the most
promosing aproach. Hopefully, I'll have time to cook up a patch this
evening.
Personally I think (1) might be slightly better, in the refuse to run
form. gc is a repository operation, not a working directory one - and
by refusing to run in a workdir this is made clear. You could print
out a message that includes the location of the actual repo to be more
friendly though.
I've seen Peter's patch that attempts to do (2), and I think
that probably is a right direction. A worktree that borrows a
repository from another worktree is trying to allow you to do
as many things you would normally do in the original worktree,
with a caveat: certain things are less safe and/or confusing and
you must know what you are doing if you use such a setting.
But whatever solution you go for, you can't use _any_ workdir that
points at a repo that is having gc run on, either directly or
indirectly, without risky odd behaviour.
And I think the above is just one of certain things that are
less safe (one "confusing" is that working on the same branch
would result in gremlin updates).
There still is an issue of what to do if the .git/packed-refs is
a symlink to a symlink. Peter's patch does a wrong thing, by
creat-then-rename overwriting the symlinked target; at least we
should detect that case and error out, I think.
Recursively dereferencing the symbolic link by hand to a limit
to avoid infinite recursion (error out when we reach the limit)
would be a more elaborate solution that probably is the right
thing to do.
On Wed, Apr 18, 2007 at 09:23:14AM -0700, Junio C Hamano wrote:
Julian Phillips [off-list ref] writes:
quoted
quoted
quoted
(1) We could by convention declare a worktree whose .git/refs
is a symlink, and have git-gc and friends check for it, and
either refuse to run or automatically chdir and run there.
If we were to do this, we probably should check more than
just .git/refs but some other symlinks under .git/ as well.
(2) We could dereference .git/packed-refs, when it is a
symlink, by hand, just like we dereference a symlink HEAD
by hand (see resolve_ref() in refs.c), and run the
creat-to-temp-and-then-rename sequence to update the real
file that is pointed at by it.
Its not all the clear which one is the best, but (2) sounds as the most
promosing aproach. Hopefully, I'll have time to cook up a patch this
evening.
Personally I think (1) might be slightly better, in the refuse to run
form. gc is a repository operation, not a working directory one - and
by refusing to run in a workdir this is made clear. You could print
out a message that includes the location of the actual repo to be more
friendly though.
I've seen Peter's patch that attempts to do (2), and I think
that probably is a right direction. A worktree that borrows a
repository from another worktree is trying to allow you to do
as many things you would normally do in the original worktree,
with a caveat: certain things are less safe and/or confusing and
you must know what you are doing if you use such a setting.
quoted
But whatever solution you go for, you can't use _any_ workdir that
points at a repo that is having gc run on, either directly or
indirectly, without risky odd behaviour.
And I think the above is just one of certain things that are
less safe (one "confusing" is that working on the same branch
would result in gremlin updates).
There still is an issue of what to do if the .git/packed-refs is
a symlink to a symlink. Peter's patch does a wrong thing, by
creat-then-rename overwriting the symlinked target; at least we
should detect that case and error out, I think.
Recursively dereferencing the symbolic link by hand to a limit
to avoid infinite recursion (error out when we reach the limit)
would be a more elaborate solution that probably is the right
thing to do.
I thought about the case where packed-refs is a symlink to another symlink
and then decided that it's not worth to implement this because a workdir
should be linked to a _repo_ and not another workdir.
-Peter