New commands to be added:

detoul script-install <file-path> [<name>]
detoul script-uninstall <name>
detoul script-cat <name>
detoul script-edit <name>

Installed scripts will be automatically in the $PATH for run directives (see #37).

First, there should be an installer for each release (hopefully it can be automatically built with a simple Makefile). It just has to deploy the code at a good location, add it to the Cygwin path, and make sure that the bash-completion script is sourced every time.

Second, there should be a "latest" installer that keeps the source code up-to-date with the git repository. Other than that, it should behave just the same as the per-release installer.

Instead of today's rebase-squash-add-parent, actually run git merge (plus all the goodies that take has). This should be a drop-in replacement, but with easier conflicts to resolve.

Not marking as breaking changes, until a scenario that works with the old take-merge is found not to be working with the new take-merge

Today for each release-branch pair, the rr-cache will be created and sealed after the first successful take. This means that if a branch advances and new conflicts now exist, there's no way to take it into the release.

I see no need for a description.

There should be a command like detoul run-unit-tests that tests that detoul runs all right on the machine (in addition to dependency checking done by the package manager), especially while in Alpha/Beta releases. This will help identify issues and hidden dependencies earlier.

Today the commit hashes different on each detoul make, as the author and timestamp of the make is included in the hash.

I propose that the author and timestamp used will be the same as of the last commit from the source branch.

And not necessarily a whole branch (from common ancestor to tip).

Remember what the results where, given the inputs.
Let git-gc clear the cache.
Cleanup the cache's index manually, whenever looking up in it.

I can no longer reproduce it, but I will leave here all the details I've gathered back when it was deterministically reproducible (sadly, on a proprietary closed-source project).

It was last reproduced with detoul from 3c9184d .

When using detoul edit, adding a comment, detoul would commit the change but not close the stdout pipe (stderr pipe closed correctly). This caused the terminal to hang for about 10-20 seconds (because the cat that runs on stdout didn't exit).

If the problem occurs again, it will be known that either (a) it existed since at least 6171f8e or (b) it existed back then, was resolved, and then reintroduced. Even in case (b), this issue could be helpful for diagnosing - as today detoul's source code is pretty short and simple, and if it gets complicated - it might be easier to test the issue on an older revision.

If the problem doesn't occur again, it might still be interesting to find out what was happening.

And generates ugly output.

This relates to #16.

Ideally, the command-line parser should read the detoul help output as a DFS and assign values.

The bash-completion script could use the same DFS to know what of type can the next argument be, and suggest based on that.

It's just an tracked file that is never added to the tree.

This changes the user's environment without informing her. If a branch didn't exist before running the take, it should be deleted afterwards.

Suggested scheme:

• rebase => take
• rebase-squash => take-squash
• take-squash => take-merge

And then detoul add-to will behave accordingly:

• no flags => take (--message ignored)
• --squash => take-squash
• --merge => take-merge

There should be a config to turn this off.

Run it until it fails.

Generally: improve the UX and usability of detoul.

See #6.

I have no experience with development on Mac, and I don't even know which package managers are common for the White OS.

See #6.

Should be a straight-forward "remember where it was, and delete HEAD@{0} until you return there".

See #5.

Exempli gratia:

detoul add-to february-release branch-1 branch-2 branch-3

Consider how it will work with the extra flags (especially of all, --message).

Explain how it works, when it refreshes, and which git config's are needed (or not).

Today Windows is only supported with Cygwin. This is (somewhat) an issue, because the "Git Bash" utility uses MinGW.

One issue at least that exists:

• grep doesn't support the -P argument

This is required for all packages.

Known, at least:

• bash
• perl
• sed
• coreutils
• git

Examples:

• file renames
• file deletions
• wide changes that require a fix in separate new files (logical merge conflicts)

It shouldn't even think that it's a detoul spec. It should warn that there's an archived spec by the name, and continue assuming that it's a branch/tag/commit.

So that the only message won't be Failure..

This will both remove them from the auto-complete suggestions, and stop erroneous dependencies on them.

They should be kept in detoul-spec/.archive/specs.

The command should be a trivial detoul archive <release>.

There should be detoul unarchive <archived-release>, and detoul cat should work on both <release> and <archived-release>.

See #6.

Most importantly, there should be an Arch package for latest release. There should also be a detoul-git package offering the latest bleeding-edge version.

I believe this will make merge conflicts much simpler.

See #37 and #38.

Squash to git merge-base "$DETOUL_BRANCH" "$branch".

This will give much easier merge conflicts.

If implemented, makes #27 obsolete.

In case of a faulty merge, there must be a reasonable way to "forget" the rr-cache.

Instead, let that happen on rr-cache-reloading.

run (which in its basic form is an alias for the now-deprecated exec directive) should run the given command under bash, when building the target release.

run will have two aliases:

• first-run
• finally-run
  , which will do exactly the same with a single difference: detoul add-to will insert the take directive before all run-last directives.

A new command, detoul add-script-run-to <release> [--first|--finally] <command> will add a run line to the <release> script, or a first-run or a finally-run if applicable (and of course, place them correctly).

The order of finally-run directives should be maintained to be chronological by all utility command. The order of first-run directives should be maintained to be reverse-chronological by all utility command.

Today:

• specs-push runs git push -f
• specs-pull runs git pull

They both should be "soft" on default, and both should have a --force flag.
specs-pull should use git pull --ff-only on default, unless given arguments --merge (which removes --ff-only) or --rebase (which replaces the --ff-only with --rebase).

And maybe even always, with --ff-only.

It breaks functionality.

detoul init should create a .gitattributes file marking rr-cache images as binary files.

They can be done today by creating a fictitious release spec with a series of "exec", but it could be modeled more elegantly, without requiring to update the "checkout" line.

(Explanation:
these are branches that are computed every time from other resources, for example a compilation output of a different project)