Re: [Monotone-devel] Making 'log' show affected files

[Derek Scherger]

Julio M. Merino Vidal wrote:
> Hi all,
>
> a lot of people don't use changelog files in their projects (I'm one of
> them).  Or even if they do, they don't stick the changelog entry in their
> commit messages.

The manual effort of recording affected files in the ChangeLog certainly 
does seem to me to be rather pointless and error prone, particularly 
when the vcs knows exactly what files where changed.

> So, what happens?  'monotone log' output can look quite ambiguous, and one
> needs to manually 'cat revision' to see what happened at each point.

I agree, and I wonder if log should have perhaps 4 volume/verbosity 
levels. i.e. (quiet) list revisions briefly using the describe_revision 
format as heads does; (current) list somewhat more information like the 
current format; (files) list the details from the revision, add_file, 
etc. as you have done; (diffs) list the details of the revision as well 
as the actual diffs between files allowing one to "read" the revision graph.

> I would like to get some review on the patch.  It works, but I may be doing
> things in an "incorrect" way.  That is, maybe I should be using
> basic_io::printer (though I don't think so, given that 'log' directly writes

Can you not use basic_io:::printer to a stringstream and then send that 
to cout, or even just print directly to the cout stream?

> to cout).  Or maybe there is another way to "merge" information from all
> change_sets (what I'm doing now with the changes_summary structure).  Or
> maybe anything else I'm missing... ;)

Why bother merging them at all, how about just listing the two (or N) 
changesets separately. This might actually be a good thing, as you 
aren't losing any information. In most cases there will only be one 
changeset anyway.

> As a data point: Arch and Subversion do this, so it looks like many other
> people fins it useful.  Plus maybe you haven't found a need for this yet
> since almost all commit messages are in changelog form (but some of them
> aren't).

I also think I like the multiple Author: and Date: lines in log, rather 
than several entries per line. The is a slight problem either way with 
these though. The only way of associating an Author: with a Date: is 
through the signing key, but with things like the changeset migration 
most certs have been signed by the same key and this is no longer 
possible. I wonder whether author and date should be inherent in 
revisions? The same problem exists for changelog certs too but we 
probably really don't want these as part of the revision itsself.

Cheers,
Derek