Matthieu Moy, 2007-07-07:
> Christian Ohler <[EMAIL PROTECTED]> writes:
>
>> After disallowing workspace operations from the diff buffer,
>
> Do you really, really, really mean that you want to remove the
> selective-files commit feature from the diff buffer?
It seems like the least painful alternative. Workspace operations from
the diff buffer look very nice at first but turn out to be confusing and
dangerous in general. Yes, we need to fix this somehow. The simplest
solution is to remove them entirely.
Stephen mentioned the alternative of allowing them (and presumably the
marking/unmarking) only if the diff shown is between the workspace and
its base revision. But this adds even more logic, and DVC is complex
enough as it is. I don't think committing from the diff buffer is
useful enough to justify the added complexity.
In fact, status buffers are the preferable commit interface anyway;
e.g., they also show unknown files that the user may have forgotten to add.
>> the sets of commands for diff buffers and status buffers become
>> essentially disjoint.
>
> Both have link to ediff,
The links to ediff are different. For ediff invoked from status, it
seems natural to have the ediff buffer associated with the actual file
to make ediff features like "revert this hunk" modify the workspace
accordingly; for ediff invoked from diff, it doesn't, since the buffers
are temporary. So the amount of ediff-specific code that can be shared
here is very limited.
> both are usefull starting point for "commit",
This is not true in general, and this is really my point. Diffs between
arbitrary historic revisions are NOT a useful starting point for commit.
> both need "go to file" kind of thing, ...
Only very little code could be shared for this feature, since the
feature itself is trivial. Also, from inside a diff hunk, you want to
go not just to the file, but to the corresponding line; this has no
analog in status mode.
> And indeed, the diff can be
> shown as part of "status" with at least git.
I don't know how git displays this, but what's wrong with C-x V s C-x V
=? This shows you the status in one window and the diff in another.
You can look at both at the same time. You can even conveniently scroll
the diff up and down while maintaining the position of point in the
status buffer.
I still maintain that the similarities between status and diff buffers
are minor.
Now for another major difference. Here's an excerpt of the list of keys
available in status buffers:
Commands:
key binding
--- -------
RET dvc-diff-jump-to-change
= dvc-diff-diff
K diff-file-kill
N diff-file-next
P diff-file-prev
^ dvc-diff-master-buffer
e dvc-diff-ediff
j dvc-diff-diff-or-list
k diff-hunk-kill
m dvc-diff-mark-file
n dvc-diff-next
o diff-goto-source
p dvc-diff-prev
u dvc-diff-unmark-file
v dvc-diff-view-source
{ diff-file-prev
} diff-file-next
<M-return> dvc-diff-scroll-down-or-diff
<backspace> dvc-diff-unmark-file-up
<mouse-2> diff-goto-source
<return> dvc-diff-jump-to-change
W s dvc-save-diff
w d dvc-diff-save-current-defun-as-kill
M-RET dvc-diff-scroll-down-or-diff
M-= dvc-diff-scroll-up-or-diff
The thing to note here is that they all operate on diffs, but there is
no diff in the buffer; it's a status buffer, after all. These commands
probably trigger errors of some sort. They shouldn't be available in
status buffers.
About half of the keybindings currently available in status buffers are
meaningless!
If you look at the list of keybindings in diff buffers, you'll similarly
notice several commands (admittedly fewer) that don't logically belong
there: For example, why would you want to pull while looking at a diff?
It's not common enough to deserve a special shortcut in addition to
the global keybinding.
The fact that the sets of meaningful keybindings differ significantly is
a really strong indication that we should have different modes.
> I'm not sure you realize the amount of work you're talking about. What
> you mean is to double the amount of effort to support correctly a
> back-end, and in particular, that's a rewrite of a substancial part of
> Xtla.
Where do you see a doubling of effort? We'd essentially be moving
features around a bit, not duplicating them.
If it has any effect on the amount of effort needed to add/maintain
back-ends, I'd expect a reduction, since introducing a clear diff/status
separation will make the DVC API more orthogonal and easier to understand.
I can't really judge how much would have to change in xtla. If xtla
depends heavily on the combined status/diff mode, can't we just take the
current code for dvc-diff-mode and move it into the xtla back-end (under
a different name)? Only the other back-ends would then use the new
split modes. It's ugly to have this special case for xtla; but
supporting tla and baz isn't worth too much effort since these systems
are obsolete.
> As a result, we won't have lost too many functionalities, but
> the way you describe it, you still do.
I'm afraid I don't understand the second half of this sentence.
> At a time where we have a real
> lack of manpower, removing functionalities at a high cost should
> really not be the priority.
If DVC has accumulated more features than we can maintain with the
amount of manpower available, if we can't fix problems with the design
any more, then dropping features that create trouble and are only
marginally useful can be a good way forward. It eliminates bugs and
simplifies future maintenance.
Committing from the diff buffer has questionable utility since you can
just as easily use the status buffer to commit. And it creates the
problems I described. It's a good candidate for removal.
Or let me phrase that as a question: What IS the major benefit of being
able to mark files and commit from diff buffers? Why can't you use a
status buffer, perhaps with a diff buffer visible in a separate window?
What other solutions to the problems of meaningless keybindings and
committing from the wrong diff do you see?
Christian.
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
