Florian La Roche <laroche@xxxxxxxxxx> writes:
> Here a patch to correctly allow also bare
> repositories.
>
> ...
>
> --- git-sh-setup.sh 2007-03-05 03:15:33.000000000 +0100
> +++ git-sh-setup 2007-03-13 17:08:22.000000000 +0100
> @@ -49,8 +49,8 @@
>
> require_work_tree () {
> test $(is_bare_repository) = false &&
> - test $(git-rev-parse --is-inside-git-dir) = false ||
> - die "fatal: $0 cannot be used without a working tree."
> + { test $(git-rev-parse --is-inside-git-dir) = false ||
> + die "fatal: $0 cannot be used without a working tree."; }
> }
>
> if [ -z "$LONG_USAGE" ]
Changing the meaning of the function and call the change "to
correctly allow" needs a bit more explanation. The function is
supposed to be called by certain operations to make sure that
they are not run from anywhere other than inside a working tree
associated with the repository, and that is why it says "we are
happy when the repository is not bare and we are not inside .git
directory --- otherwise we are unhappy".
I suspect that you found a command that calls this function,
when it should also be usable in a bare repository. If that is
the case, the caller needs to be fixed, perhaps not to call this
function at all, or perhaps call it only before performing an
operation that _needs_ working tree (I do not think of an
example offhand, but it is conceivable that a command can work
fine in a bare repository under an option but requires a working
tree with a different option). Changing the meaning of this
function so that it is always happy with bare repository means
you are breaking the assumption of other callers.
For example, git-fetch in a bare repository is fine. It is an
operation to update the object database and (optionally) advance
the refs used to track the other side. On the other hand,
git-pull, git-reset nor git-checkout are not. As they are meant
to update the working tree from the repository, running them in
a bare repository, which lacks the working tree by definition,
does not make sense. That is why they use this function.
-
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