Matthieu Moy <[EMAIL PROTECTED]> writes: >> 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. > > So, what's the expected behavior for you? > > You have a problem with dvc-add-log-entry setting the partner buffer > while creating the *log-edit* one, but you seem to have no problem > setting it when reusing an existing buffer.
Hmm. dvc-partner-buffer should not change when the buffer is reused by dvc-add-log-entry. But if dvc-add-log-entry calls dvc-log-edit, it is changed (I was assuming it wasn't if the buffer was reused). So my patch is broken; I guess I did not test very well :(. So dvc-add-log-entry can't just call dvc-log-edit to reuse a buffer; it has to switch to it only. I was thinking of doing that anyway, because xmtn recomputes the commit comment when you call dvc-log-edit, which is not appropriate for dvc-add-log-entry. >> Then you still misunderstand the problem. > > AAUI, your problem is that dvc-add-log-entry sets the partner buffer > to the source file. > > The same thing happens when creating a new *log-edit*, and when > reusing it. IOW, when reusing the *log-edit* buffer, it also sets it > to a source buffer. That's at least the case with bzr and git, I > didn't try xmtn. Right. That is done in the back-end function. And I missed the point that dvc-log-edit sets dvc-partner-buffer even when the log-edit buffer is reused. >> 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? > > If the buffers are in sync, you don't care which one to chose. Since they are commiting to different repositories, it does make a difference. Suppose the workspace for project A is ready to commit, but B still has some files to review. You are in the log-edit buffer for A, and hit C-c C-c. But dvc-log-edit-done chooses the log-edit buffer for B, and it does the wrong thing. >>> 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" ?). > > Well, I rarely do that myself, but one may want to do a quick commit > without review (please, don't do that on a public project ;-), but on > a personal project, for situations like "I finished working on my > laptop, let's commit and push to my desktop", it can be perfectly > fine). That's a good point; with CVS, I often commit one file without going thru a status buffer. The same usage should be supported by DVC. In that case, dvc-log-edit needs to use the same logic as dvc-status to figure out the back-end and root; that is, it needs to consistently use dvc-current-active-dvc. And dvc-log-edit needs to set dvc-partner-buffer in a way that tells dvc-log-edit-done that it should commit the source buffer only. Setting dvc-partner-buffer to the source file in this case makes sense, but I don't think any of the current back-ends treat that as meaning "commit only this file". That could be added. Or maybe there needs to be a different mechanism for this case. There is also a problem when there are multiple back-ends for a workspace. Currently, to select the back-end, I have the following in a text file: (let ((dvc-temp-current-active-dvc 'bzr)) (dvc-status "/Gnu/dvc-fileinfo/")) (let ((dvc-temp-current-active-dvc 'xmtn)) (dvc-status "/Gnu/dvc-fileinfo/")) Then I use C-x e to execute the appropriate form, starting the status buffer. This is acceptable overhead for status, since it is not done often. But for quick single-file commit, it's too much. Perhaps dvc-log-edit could prompt the user if two back-ends are detected. I'm not sure if we want to put that into dvc-current-active-dvc. Or there could be a wrapper function that does the prompting, and then calls the current dvc-log-edit. dvc-log-edit is currently interactive, so adding wrapper is changing the current UI. >> At this time, we don't have to address the issue of dvc-log-edit not >> working correctly when called this way. > > We do. For a simple reason : > > consistency. That means we need to do it eventually; not right away. There are _many_ inconsistencies in the current code! We can't fix everything at once. > You're trying to adress multiple problems (dvc-add-log-entry, nested > trees management, and the way partial commits are done) Well, the _problem_ is dvc-add-log-entry; the _context_ is nested trees, multiple back-ends, and partial commits. It's the same context for all DVC issues. > in a solution that would only change dvc-log-edit, No, I'm trying to change only dvc-add-log-entry. > and which makes it inconsistant with other commands. dvc-add-log-entry is currently inconsistent in a typical usage (at least for me). I'm trying to make it consistent. dvc-log-edit is also inconsistent as you point out above, but in a rare usage (for both of us; others may disagree that it is rare). These are two separate problems, and as far as I can tell at the moment, they have different, unrelated solutions. Hmm. One variant of the "quick single file commit" case is the user calling dvc-add-log-entry to start the process instead of dvc-log-edit. I'm proposing to add intelligent prompting to dvc-add-log-entry when a log-edit buffer needs to be created, so that may actually provide a solution for this case. Hmm. Or perhaps the intelligent prompting should be moved into dvc-log-edit. That would make the solutions overlap. And maybe dvc-status and dvc-diff should do similar prompting when multiple back-ends are detected, avoiding my overhead forms above. Things get complicated when you try to address more than one problem at a time :). I'd like to just fix dvc-add-log-entry. I'll try to write the prompting code in a nicely factored way, so it can be reused or moved if we decide to do that for these other issues. > dvc-log-edit is just the same as dvc-add-log-entry, except that > dvc-add-log-entry inserts something in the log buffer, while > dvc-log-edit doesn't. Actually, xmtn-dvc-log-edit inserts the entire commit comment, which is also a problem for dvc-add-log-entry. >> "In which of these buffers will you mark files for commit?" > > That sounds reasonable. Ok. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
