Stephen Leake, 2007-07-14:
> Matthieu Moy <[EMAIL PROTECTED]> writes:
>
>> Most of the time, "$backend diff" shows the difference between the
>> last revision and what would be the current revision if you commited
>> now. This does not include unknown files.
>
> Yes, that is the current state.
>
> Is that desired? We can fix it; should we?
I think it [omitting unknown files] is desired for historic diffs (since
the concept of unknown files only makes sense when there's a workspace),
but not for the commit interface (where unknown files are important to
be reminded of).
Yet another reason why the diff mode should be distinct from the
commit/revert/... interface.
>> The summary at the top "looks like" the output of "status", but it's
>> actually obtained by parsing the diff (in particular, this avoids
>> running the tool twice for "status" and "diff").
>
> Ok, that makes sense.
If status gives us information that we want in addition to the diff
(e.g. about unknown files), there's nothing wrong with calling the tool
twice. Anything else is premature optimization:
* hg and git are said to be very fast anyway.
* Calling status followed by diff is likely to be fairly fast for any
system due to caching.
* For mtn, we can get additional caching benefits by running status and
diff in the same mtn automate stdio instance.
>> So, if you wanted to add a summary of the diff, that would be by
>> parsing the output of diff ("parse" seems to imply a lot of work, but
>> that's really about re-search-forward-ing "+++ \\(filename\\)" and
>> such things).
>
> Right. In fact, DVC should supply parsers for the standard Gnu diff
> formats.
At least with mtn, the diff contains additional useful information (e.g.
about renames) in a non-standard syntax. I suspect other tools behave
similarly, each with its own syntax. So it seems best to allow
backend-specific processing here.
Christian.
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
