Improve existing --no-checkout flag

[olsen232]

kart import supports --no-checkout, but it merely postpones creating a working copy. As of this commit, it will add also add the dataset to a set of non-checkout datasets in the config, so the dataset will stay out of the WC indefinitely.

Also adds kart checkout --dataset=foo --not-dataset=bar flags to add and remove datasets from the set of non-checkout datasets

Still TODO: show what the current set of non-checkout datasets is in kart status

Related links:

#905

Checklist:

• Have you reviewed your own change?
• Have you included test(s)?
• Have you updated the changelog?

[craigds]

hm, paths can contain dots (a.b.c is a valid path) - should this config structure be adjusted?

[olsen232]

Good catch - tested config files and pygit2 behaviour, dots are valid in the middle part (which seems to be the "user-defined" part) but not in the first and last part.
Updated code to recognise and allow for entries that look like dataset.SOME.NAME.WITH.DOTS.checkout

[craigds]

wild. ok

[rcoup]

Sorry, I didn't get to this earlier. Git config has standard ways of referring to weird section names, this looks like it's using the older deprecated dot notation?

eg:

[includeIf "gitdir:/path/to/foo/.git"]
	path = /path/to/foo.inc

https://git-scm.com/docs/git-config#_syntax

Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in the example below:

[section "subsection"]

Subsection names are case sensitive and can contain any characters except newline and the null byte. Doublequote " and backslash can be included by escaping them as " and \, respectively. Backslashes preceding other characters are dropped when reading; for example, \t is read as t and \0 is read as 0. Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don’t need to.

There is also a deprecated [section.subsection] syntax. With this syntax, the subsection name is converted to lower-case and is also compared case sensitively. These subsection names follow the same restrictions as section names.

[olsen232]

👍 Yup this is fine - in fact I'm using the pygit2 API to access the config (although it's not immediately obvious that I'm doing so from this code). pygit2's API converts git's more complicated syntax[section "subsection"] key = value into a mostly-simpler global key that looks like section.subsection.key - and as of Craig's comment, I tested to see if it can handle subsections with dots in, eg [section "subsection.with.dots"] key = value - it can, and for API access it converts it again to section.subsection.with.dots.key which I have handled now, it's straightforward as long as you know that that's what it will do.