[darcs-devel] [issue2042] repair should be a subcommand of check

[Guillaume Hoffmann]

> User centric
> ------------
> Having separate commands seems useful if the two styles of command
> require different flag sets.  You pointed out one issue below with
> test (and all the test related flags, I'll mention)

Yes, the --no-test may be a problem.

Having the --(no)-test flags belonging to the check command was
already noted on the mailing list as being a potential problem. I
think it was when we discussed the implementation of trackdown
--bisect. Someone said that maybe we should have a "darcs test"
command that would include all kinds of test-runs: test, test
--trackdown, test --bisect, test --delta, etc.

There is currently an overlap in the UI of testing repository
integrity and testing code integrity.

> I notice also that check has has --ignore-times, which repair does
> not. Anybody know what's about?

Looks like it used to check the index (if --ignore-times is passed,
index checking is ignored).
I don't know why we should sometimes dispend with checking it. Petr
probably knows why.

> I can see how repairing implies checking.

> Asking from a UI consistency standpoint, what do we currently do?  Is it
> appropriate to consider darcs get/init as another R/C pair, or does the
> analogy not hold

This doesn't really work since "init" can be used to version existing
unversioned code, not "get". But we do have another analogy:
"obliterate" is a proper supertask of "unrecord", but does have a
separate command. But "obliterate" (or its alias "unpull") is used
much more often than "repair" and certainly deserves its place in the
documentation and UI, IMO.

>  As a user, should I even care that repairing
> is just check plus a smidgen extra work?

In the manual, introducing repair as an option of check seems adequate
to me, it saves time and reduces the apparent number of concepts that
darcs involves.

>  How would does (knowing I
> have to run)
>
>   darcs check
>   darcs check --repair
>
> Make darcs any better to use?

It's less important that the documentation motivation but... you would
just have to press the "up" key and type --repair if you want to
repair :)


> Developer centric
> -----------------
> There must be alternative solutions for reducing the overlap, no?

Yes, an obvious one: the code for repair could be moved into
Darcs.Commands.Check, without having the UI changed at all (like
obliterate is in Darcs.Commands.Repair).



So the issues involved in my initial suggestion are clearer:

1) putting code for repair in an appropriate place to reduce code
repetition (that would be the Check module)
2) making --repair a flag of check
3) moving --(no)-test flag out of check, into a test command that
would also replace trackdown
4) why check --ignore-times ?

It seems easier to get a consensus on 1), but probably issues 2) and
3) should be tackled at the same time, discussion-wise. 4) is for
Petr.