Hi, On Sat, 28 Jul 2007, Junio C Hamano wrote: > 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 am happy that you agree with the way I implemented it... > 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. Yes, I want that behaviour. > 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. There are two reasons against that... - it is really convenient to be able to say "git add .vimrc" (think Martin Krafft's desired setup). Let's just put some uppercase warning at the side of --work-tree in git-init.txt to tell the user about the behaviour. - the implementation of "you are not in the worktree" would not be elegant: "git log" should succeed, "git log dir/file" should not. Ciao, Dscho - 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
