Stephen Leake <[EMAIL PROTECTED]> writes: > 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.
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. > 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. > 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. >> 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). > 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. You're trying to adress multiple problems (dvc-add-log-entry, nested trees management, and the way partial commits are done) in a solution that would only change dvc-log-edit, and which makes it inconsistant with other commands. 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. Similar specification => similar expected behavior. > [...] > > "In which of these buffers will you mark files for commit?" That sounds reasonable. >> 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. Yes, that's it. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
