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. 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). I still think that your solution doesn't solve the problem. >>> 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. This is what I'm talking about, and this is what Xtla is doing (note: it used to actually grab the list in dvc-log-edit, and take this one to perform the commit, which seems to be what xmtn was doing, but we came up with the same conclusion). >> 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. 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. > 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. > 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). > 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. And to me, having two variables where we can have just one increases the complexity (both for the user and the developpers). 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. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
