Junio C Hamano <junkio@xxxxxxx> wrote:
> But execution has room for improvement, and it is not your
> fault. The shell script version of require_not_bare is as
> fragile as is_bare_git_dir(), which I already do not like, and I
> think if we are going to use is_bare_git_dir() more, I think we
> would want to have something a bit more robust.
Agreed. But as you point out...
> If we could outlaw $GIT_DIR/index in a bare repository, then
> lack of $GIT_DIR/index combined with nonexistence of ref that
> is pointed at by $GIT_DIR/HEAD could become a good indication
> that the repository is bare ("the current branch unborn" check
> is needed not to mistake a repository before the initial commit
> as a bare one).
>
> Alas, many public repositories you would see (e.g. check
> kernel.org) have been primed with rsync of .git/ from
> developer's working repository and have leftover index that is
> otherwise unused. Because of this heavy historical baggage, I
> suspect that it is rather hard to convince people to allow us to
> use this technique.
I almost coded the require_not_bare() to look for $GIT_DIR/index
but didn't for the reasons you point out above. It is too bad that
we didn't enforce the existance of the index file better in the past.
> When you have $GIT_DIR in your environment, no working-tree
> command is expected to work unless you are at the toplevel of
> the working-tree. In the past, people talked about their
> workflows using more than one working trees that are associated
> with a single $GIT_DIR
What happens with $GIT_DIR/index in this case? Or $GIT_DIR/HEAD?
Its insane because both need to be affiliated with the working
directory, yet there's only the one set. Sure the user could also
arrange for $GIT_INDEX_FILE to be set based on the working directory,
but what about $GIT_DIR/HEAD? There is no equivilant.
> and that is certainly supposed to work.
> But I wonder how widely such a set-up is employed in practice.
> If we outlawed working-tree commands when $GIT_DIR environment
> exists, how much hurt are we talking about, I wonder.
I wouldn't be hurt, but I don't call Porcelain-ish unless I'm
entering commands directly on the command line, and I never set
GIT_DIR except in scripts, and even then its very rare and is more
to point at a bare repository than one with a working directory.
I suspect that probably isn't true for everyone.
> Another thing to think about is if we are happy with the above
> restriction that makes environment $GIT_DIR to imply you are
> always working at the toplevel. Maybe it could be a good idea
> to kill this bird as well by introducing $GIT_WORKTREE_TOP
> environment variable. Presence of it obviously means we are not
> in a bare repository, but at the same time it would allow us to
> teach setup_git_directory_gentry() to cd up to that directory to
> make the commands behave as expected.
I'm not sure what value that environment variable offers here.
Users who set GIT_DIR but don't today set GIT_WORKTREE_TOP are
broken by this change because its not set and we assume its bare.
So they need to also set this environment variable. But that
is probably going to be annoying for those users as I doubt they
are setting GIT_DIR on a per-directory basis.
Why not just tell these users to setup the working directories with
local .git directories and not use GIT_DIR?
--
Shawn.
-
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