Stephen Leake <[EMAIL PROTECTED]> writes: > Matthieu Moy <[EMAIL PROTECTED]> writes: > >> The _point_ of `define-dvc-unified-command' is to create a dvc-* >> function that only calls <back-end>-*. > > Well, ok. > > But we've been moving away from that; see dvc-add-files, > dvc-revert-files, dvc-remove-files, and now dvc-log-edit.
You probably didn't look at my latest commits. This was a problem in the existing code base, this problem is a solved one now. > These all have moved some of the user interface code out of the > back-end into the front-end, with the idea of making the DVC UI more > consistent across back-ends. Which is good, yes. The functions you mention above just lacked a way to be called for a given back-end, they have one now. >> _If_ we decide to implement dvc-status another way, with some DVC code >> before doing the dispatching, then we have at least two options: >> >> * stop using `define-dvc-unified-command', and do it the other way >> around: implement dvc-status, and use `dvc-back-end-wrappers' for >> that. >> >> * have dvc-status call bzr-dvc-status, which in turn would call >> dvc-status-internal, which itself is the implementation. > > Or, as above, refactor what is done in the front- and back-end > functions with the same name. > > If we want to keep functions defined by define-dvc-unified-command as > very thin dispatchers, then we need another convention for the common > DVC front-end UI functions. I don't understand what you mean here. >> I'm not 100% clear about the best method either, but what we have now >> is roughly: >> >> * <back-end>-something is a user-callable function. >> >> * dvc-something is a DVC-unified function that acheieve the same goal. >> >> * <back-end>-dvc-something is the target for a dispatching function >> (dvc-apply, dvc-function), and in most cases, it's an alias for >> <back-end>-something (without the -dvc-). > > That's not quite right. We also have <back-end>-something that are > dispatching targets; grep for 'dvc-function' for a first approximation to > this list. It includes "revision-get-file-revision", "diff-mode", > "tree-root", etc. Yes, the relevant word in my sentence above is "roughly" ;-). diff-mode is an exception, since you can actually do M-x git-diff-mode RET and it will do the right thing, but the other are probably just pieces of code where the (somewhat informal up to now) convention was ignored. So, if we make the convention more strict, we should fix these. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
