Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> Now, I think it is fair to say that if your worktree is somewhere >> totally unrelated to your cwd, no amount of going up will take you to >> the top. IOW, you have to come down after going up some levels. In >> such a case, it is easier to code the implementation of --show-cdup to >> give an absolute path. >> >> But in that case you are not even in the working tree to begin >> with, aren't you? Does git need to support that? > > I'd say yes. > > It is utterly _inconvenient_ to have to cd to the working tree when you > just want to check the status, for example. And git already knows about > the work-tree! That is a bit different issue. In such a case, I would agree it would still be sensible for "git diff" to show the whole tree diff, for example. In other words, my "does git need to support that" is not about "even when the location of a worktree is known, operations that require a work tree should fail when invoked from outside of it". Think about what the sensible thing to do is for "git diff ." Within a work tree, it instructs git to behave as if the user issued the command from the toplevel with prefix as the argument. And scripts that want to mimick that behaviour would use --show-prefix to obtain the prefix string, and --show-cdup to obtain how to move to the toplevel. Outside of a work tree, I think the only two semi-sensible behaviours exist. Either tell the user that we cannot understand what "." should mean in that context and error out (IOW, "Not inside a work tree"), or assume that the user meant "from the top". So in such a case, if we do not want to error out to make things more "convenient", one possibility would be: * give empty as prefix; * give absolute or cwd relative path to the work tree for cdup (it would not be a sequence of ../ anyway in this case). I think this is in line with the traditional behaviour when GIT_DIR is explicitly given. We assume the cwd is the toplevel, and return empty prefix and empty cdup. Having said that, I am not convinced that "assume toplevel outside of a work tree" is a win for the end users. If the command errors out with a message telling the user that relative path does not make sense from outside a work tree, the user would understand. If the command does not error out but always works relative to the toplevel without explanation, it might confuse the user more until the he realizes "assume toplevel outside of a work tree" is the rule that is applying to his case. - 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
