Matthieu Moy <[EMAIL PROTECTED]> writes: > Stephen Leake <[EMAIL PROTECTED]> writes: > >>>> Solution 0 also works for me. >>> >>> It doesn't change your problem. >>> >>> M-x dvc-status RET >>> mark files > > Add > > c (to create a log buffer) > go back to dvc-status > > ... > >>> 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. > > And it wouldn't abort.
Yes, that is the usage with solution 0. > And you'll get a full commit, even with files marked in the status > buffer (I've just checked, with your latest commit in, at least with > git backend). Yes. > I still think that your solution doesn't solve the problem. Then you still misunderstand the problem. But we seem to be making progress anyway :). >> But you are addressing a different problem. > > They're different views of the same problem. If you know that all > buffer are in sync, you just don't need the dvc-partner-buffer thing > to perform a commit, you look to see if there's a buffer with marked > files, if so, take this list, and otherwise, make a full-commit. Ah. That is a different solution. I don't think it's viable; consider the case of two parallel workspaces, each controlled by different back-ends with different repositories. You always commit them at the same time, and review them in parallel, in two status buffers. Thus there are two status buffers with marked files, and two log-edit buffers; which does the commit choose? In that case, solution 0 for dvc-add-log-entry also fails, and solution 1 or 2 needs to be very smart about picking the right log-edit buffer, but it is possible (based on the tree the source file is in). I've never actually done that, but there are lots of discussions about "library projects" that could lead to that scenario. >> 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. > > Note that it's not only about dvc-add-log-entry, but also about > dvc-log-edit, which can also be called from a source buffer, and also > creates a log-edit buffer. Yes, I had not considered that. I would never do that, and would not object if DVC refused to allow that. Maybe we could have an option for "strict" mode (or "pedantic" ?). But I _do_ want to use dvc-add-log-entry this way, and have it work correctly. At this time, we don't have to address the issue of dvc-log-edit not working correctly when called this way. >> This also addresses your earlier comment about not using >> dvc-partner-buffer for anything other than simple navigation. > > I have nothing against using dvc-partner-buffer for both navigation > and file-list (partly because I never use dvc-partner-buffer for > navigation, so I'm don't really care personnally). Ok, that makes things simpler. >> 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. > > I'd find it more confusing that anything else to have DVC prompt me > about a status or diff buffer while I'm asking for a log-edit > buffer. It would have to be a verbose prompt; something like: "Which of these buffers are you using for reviewing files?" or "In which of these buffers will you mark files for commit?" If you don't know _why_ it's asking, that will still be confusing. A yet more verbose prompt: "Creating a log-edit buffer; it must be associated with a diff or status buffer, to allow marking files for commit. Which buffer?" > And to me, having two variables where we can have just one increases > the complexity (both for the user and the developpers). I guess by "two variables" you mean "dvc-partner-buffer" and "dvc-files-buffer". I agree, that is not necessary. > If you insist in having this prompt, well, I disagree, but let's say > I'm OK with it ;-), but this should be taken care of separately of > the question of duplicating the variable IMHO. Yes, we are now converging on solution 1. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
