Matthieu Moy <[EMAIL PROTECTED]> writes: I'm snipping the discussion of whether DVC should refuse to do some things to protect the user; we'll have to disagree on that point.
There is still an issue of getting DVC to do the right thing in dvc-add-log-entry. >> 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 Yes. > (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. No, that's the whole point here; dvc-add-log-entry creates the log-edit buffer, and it is invoked from the source file, _not_ from the diff or status buffer. Thus it sets dvc-partner-buffer in a way that breaks dvc-log-edit-done. >>> 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. Yes, that's true. I don't see how it is relevant. You seem to have missed the point about how the log-edit buffer is created in this scenario; that explains most of the misunderstanding in this discussion. >> 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. Yes, that is true. But it is not the problem I am attempting to fix; see below. >> 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 In solution 0, C-x V a would abort, because there is not yet a log-edit buffer, and it doesn't know how to create it properly. >> 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. This is the old xmtn behavior; it captures the marked files when the log-edit buffer is created, but does not update it when the marks in the ewoc change. We just removed that behavior for that reason. > 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). Keeping it as a comment, _not_ used by dvc-log-edit-done for the actual list of files to commit, and marking it as possibly out of date, would be ok. > 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. Yes, that is the ultimate solution to the problem of having multiple commit buffers open. But you are addressing a different problem. The problem I am attempting to fix is dvc-add-log-entry calling dvc-log-edit, and setting dvc-partner-buffer in a way that breaks dvc-log-edit-done. That is what my three solutions address. Solution 0 simply refuses to create the log-edit buffer in dvc-add-log-entry; then the only way to create log-edit buffers is from a diff or status buffer, and dvc-partner-buffer is correct for dvc-log-edit-done. Solution 2 allows dvc-add-log-entry to create the log-edit buffer. You want to have dvc-partner-buffer in the log-edit buffer set to the source buffer in this case, because that was the original intent of dvc-partner-buffer. That means dvc-log-edit-done cannot use dvc-partner-buffer to find the list of files to commit; it must use the new variable dvc-files-buffer instead - dvc-log-edit must set that variable to the diff or status buffer. This also addresses your earlier comment about not using dvc-partner-buffer for anything other than simple navigation. Solution 2 (in addition to introducing dvc-files-buffer) improves on solution 0 by attempting to figure out how to create the log-edit buffer with dvc-files-buffer set appropriately, by searching for diff and status buffers, and prompting the user. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
