On Thu, 06 Sep 2007, Malcolm Rowe wrote:
> On Thu, Sep 06, 2007 at 04:13:39PM +0200, Charles Acknin wrote:
> > On 9/5/07, Heikki Orsila <firstname.lastname@example.org> wrote:
> > > Filed the issue.
> > I think 'svn diff' is a more (the most?) appropriate sub-command to
> > display the diffstat stuff, rather than 'svn log'.
> > As for "2. git log -p shows commit patches", I'm not sure whether it
> > would be most relevant in 'svn diff' or 'svn log' as it displays both
> > unidiffs and commit metadata, but I'm leaning towards 'svn diff' since
> > (a) the output is mostly made of unidiffs (b) the intent is to display
> > a patch, as git-log(1) says (and as it looks like).
> Right, but not necessarily a patch that you could apply - more a patch
> for review. There's no reason you couldn't (for example) run 'svn log
> --stop-on-copy --show-unidiff .../branches/foo' to review all work done
> on a branch so far, as individual changes.
As Heikki, I like 'svn log' as the home for this functionality, and
like '--with-diff' as the option name.
> (For extra credit, I'd like a way to skip changes that were the result
> of merges - can we do that already?).
'log -g' now indicates which changes were the result of a merge
(thanks to Hyrum's GSoC project!). This info could be used to perform
the filtering you describe. However, you might filter out meaningful
changes in the process, so I'm somewhat leary of this suggestion...
Received on Thu Sep 6 18:59:40 2007
- application/pgp-signature attachment: stored