Re: Merge Tracking Auditing - SoC

On Tue, 17 Apr 2007, Hyrum K. Wright wrote:

> Daniel Rall wrote:
> > On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> >
> >> Daniel Rall wrote:
> >>> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> >>>
> >>>> Daniel Rall wrote:
> >>>>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
> >>>> ...
> >>>>>> * In the case of svn log, would the user be better served if we just
> >>>>>> included the original revision logs in line with the logs (i.e., no
> >>>>>> special indentation, etc.)?
> >>>>> A good case has been made for no indentation. Some indication of that
> >>>>> we're not showing the actual log message would be useful.
> >>>> I'm having trouble parsing that last sentence. Would you mind restating it?
> >>> If we decide not to show the *actual* log message used with a commit
> >>> (which would be consistent with what we're going to do for 'blame'),
> >>> some indication in the output of the *original* log message(s) that
> >>> they aren't the actual log message, and are being displayed in lieu of
> >>> the actual message, might be useful.
> >> So, basically something to the effect of: (the revision numbers below
> >> are somewhat bogus.)
> >>
> >> ------------------------------------------------------------------------
> >> r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> >> === result of merge in r24678 ===
> >>
> >> * notes/merge-tracking.txt
> >> Add issue #2769, and sign up for it.
> >>
> >> ------------------------------------------------------------------------
> >> r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> >> === result of merge in r24678 ===
> >>
> >> * notes/merge-tracking.txt
> >> Sign Kamesh up for the "all unmerged revisions" task, per his request.
> >
> > Yes, exactly. This is a divergence from what svnmerge.py does (IIRC,
> > Giovanni suggested it), in that there's no indentation of the
> > *original* log message(s), and that we aren't listing the *actual* log
> > message.
>
> I like this representation better. Is there a particular reason for
> omitting the *actual* log message?

I too prefer something like this representation to what svnmerge.py
does. Omitting the actual log message would be more consistent with
the behavior of 'blame', which will be showing the original revision
number in which a line was changed, rather than the actual revision
number. (While I personally kind of like the idea of showing both, I
think the additional output might be more noise than signal).