Stephen Leake <[EMAIL PROTECTED]> writes: > Matthieu Moy <[EMAIL PROTECTED]> writes: > >> Stephen Leake <[EMAIL PROTECTED]> writes: >> >>> Then all back-ends would commit all files (or possibly no files), >>> rather than the correct list of files, if the user had marked some. >>> That's wrong. >> >> It doesn't change the existing behavior: >> >> You can already do something like >> >> Run dvc-status >> Run dvc-diff >> Run dvc-log-edit <-- partner buffer is diff. >> switch to dvc-status >> mark files >> switch back to dvc-log-edit without running log-edit >> commit. >> >> You mark files at some point in time, but you don't commit them >> individually. > > Yes, that is true, and also bad, and DVC should either not allow this, > or fix it in some way. This is the use-case for a "read-only" diff.
Why the hell should people not be able to run both dvc-diff and dvc-status? It keeps comming back in the discussion, accompanied with some "the user should not X", "the user should not Y", ... I don't want to turn DVC into a rigid interface, like a wizard with a "next" button on each screen, and "commit" at the end. There's nothing wrong in running, for example, status first, to get a quick overview, add unknown files if there are some, and later run dvc-diff. It is *not* equivalent for the user to running per-files diff. Typically, if your changes to be committed consists of many very small hunks, you'll get the global picture in a buffer with dvc-diff, and it will be really painfull to view the files one by one. > But in this case, it is clear the user is abusing DVC; they've started > two commit views into the same workspace. They're not "commit views", they're diff and status. You can run diff for tons of reasons, commit is only one of them. > That's similar to opening two Emacsen, and editing the same file in > each; users should know not to do that. So, what's the point? You're fine with letting the user launch two Emacs instances, and not with letting two different commands? > In the dvc-add-log-entry case, the user is not doing anything wrong. > The sequence is: > > run dvc-status > view a source diff with ediff > run dvc-add-log-entry > which runs dvc-log-edit, setting partner buffer to source > mark files in dvc-status buffer > run dvc-log-edit-done Which is available as a keybinding only in dvc-log-edit-mode (probably it should just die if you call it from a non-dvc-log-edit buffer), so you'd have typed 'c' or some other binding to get to the log buffer. >> Individual files commit is always done with respect to the buffer >> you're comming from. > > In this case, you interpret "comming from" as the source buffer, but I > interpret it as the status buffer. > > The fact that the log-edit buffer happened to be created by a > keystroke that was executed with the source buffer current is > accidental; making that source buffer define the list of files to > commit is _not_ what the user intends here. They are doing a commit, > with the list of files to commit in the status buffer. DVC should > understand and expect that. If you mark files, you have to go to the status buffer, or diff buffer. Then, I hardly see a flow where you would not want to see your list of marked files before commiting. > We need to come to some compromise that we can all live with. > > You are rejecting solution 1 (set dvc-partner-buffer to the status > or diff buffer in this case). That's fine. > > Is solution 2 acceptable (new dvc-files-buffer variable)? It works for > me, and I think, from what you have said so far, that it would work > for you. But I'm not sure. Solution 2 doesn't really change the problem, it just changes the variable name. If, now, I run dvc-status, start doing something, then burry the buffer (manually, or with dvc-buffer-quit-mode set to 'burry), go for lunch, come back and do something else, I'll end up with a list of files to commit which comes from a buffer I didn't even remember about. > Solution 0 also works for me. It doesn't change your problem. M-x dvc-status RET mark files RET (to open a file) C-x V a C-c C-c At least with git, it does a full commit. > Is there another solution? There's something we had for Xtla which I think we didn't port to any other back-end : when running dvc-log-edit, it inserts a comment at the end of the log buffer with the list of files selected, if there are some. It's hard to ensure that the list is precisely up-to-date, but at least refreshing it each time log-edit or some other functions opening the log buffer makes it hard to commit without an up-to-date liste. Regardless of what is chosen, this is a cool feature, it would be nice to port it to other back-ends (well, actually, it should mostly be in DVC). The other option is to keep the marked files in sync in different buffers. That way, you don't have to worry about the buffer you're starting the commit from. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
