Jeff King venit, vidit, dixit 23.02.2015 15:42:
> On Mon, Feb 23, 2015 at 03:16:59PM +0100, Michael J Gruber wrote:
>
>> --to requires a directory, not a file. Say so in the usage string.
>
> Sounds like a good goal, but...
>
>> - OPT_FILENAME(0, "to", &opts.new_worktree,
>> + OPT_STRING(0, "to", &opts.new_worktree, N_("dir"),
>> N_("check a branch out in a separate working directory")),
>
> OPT_FILENAME also calls fix_filename(), which munges the filename so
> that relative paths given by the user will work, even though git has
> chdir'd to the root of the working tree.
Ooops, I wasn't aware of that. We do use OPT_STRING in quite a few
places for directories, though.
> So you need to handle that somewhere. I think it might be less painful
> to teach OPT_FILENAME to be more flexible in the usage message it
> prints.
We have at least path, template-dir dir which can benefit from that.
After Junio's call, I'm trying to look a bit at list-files and multiple
workdirs. I guess I should collect those bits.
BTW: multiple workdirs commit messages and doc talk about a hard link
named "link" in worktrees/<id>/, but I don't get any from "checkout --to".
Instead, and in addition to the expected "gitdir", I get a file
"gitfile" whose content is a relative path (*not* prefixed with "gitdir:
"), probably to the worktree .git gitfile (relative from the base
worktree). But "gitdir" "points to" the same, using (i.e. it contains)
an absolute path.
I can't quite make sense of this. Maybe the doc is behind? But still.
"gitdir" and "gitfile" pointing to the same file.
Michael
--
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