RFC: modify dataset="^" shortcut to become dataset="^*"

[yarikoptic]

#987 made me consider:

making analogy with git, it makes me think that may be ^ is suboptimal as a shortcut. In git, we have it to point to "previous" (or 1 up) commit. So theoretically we could make it understand ^ (direct superdataset), ^^ (two super-datsets up), ^n (n is a digit) - n superdatasets up (failing if there is no that many).

But then what to choose for the ultimate super -- ^*?

It will be backward incompatible since we did release already with current understanding of ^ but imho it is a tollerable breackage especially if we decide quick (I could implement). alternatively

• we could just use some other symbol to designate "x level up", e.g. "~" if to make git analogy, but it is somewhat bad since collides with "$HOME" (although unlikely anyone would use it that way)
• we could maintain ^ as ultimate top super-dataset, while allowing for ^^, ^^^ and ^n to go prescribed number of supers up. But then ^1 should be used for super 1 level up and it is somewhat inconsistent

what do you think?

[bpoldrack]

To me it makes sense, including ^* and the breakage it results in. I think you pointed out, why alternatives are not exactly desirable.

[mih]

This issue is officially being ignored.

[kyleam]

So theoretically we could make it understand ^ (direct superdataset), ^^ (two super-datsets up), ^n (n is a digit) - n superdatasets up

Doesn't seem to be the core thing that this issue is about, but this confused me. Your description of ^n breaks the git parallel here. ^^ is not ^2, it's ^1^1 or ~2. I don't see how git's ^n (nth parent) could have a superdataset analog.

[mih]

The discussion came to a conclusion. Verdict 50-50 for a move in no direction ;-)

[yarikoptic]

well, we are in "demand driven development". So far I frequently use save -S (which should be analog to save -d^ . I guess?) but do not care to jump specific number of super datasets up.