Commit notifications include too little data about merged revisions

We used to do this in the past, and it was determined that most often this isn't what is desired.

The complete history is available for any user to look at in more detail if they so desire, but in the situations where people commit *a lot*, the email became almost useless.

 wrote:
> We used to do this in the past, and it was determined that most often
> this isn't what is desired.
>
> The complete history is available for any user to look at in more detail
> if they so desire, but in the situations where people commit *a lot*,
> the email became almost useless.
>
> ** Changed in: launchpad-code
> Status: New => Won't Fix

I think there's room to experiment a little more here -- part of the
problem before was that it was like 'log -v' output and the lists of
changed files from trunk merges became overwhelming. But if we just
showed the log messages somehow intelligently grouped by author and with
a limit on the number we showed in the mail, I think it might be better
than what we have today.

Cheers,
mwh

On Mon, 18 Jan 2010 06:57:48 Michael Hudson wrote:
> wrote:
> > We used to do this in the past, and it was determined that most often
> > this isn't what is desired.
> >
> > The complete history is available for any user to look at in more detail
> > if they so desire, but in the situations where people commit *a lot*,
> > the email became almost useless.
> >
> > ** Changed in: launchpad-code
> > Status: New => Won't Fix
>
> I think there's room to experiment a little more here -- part of the
> problem before was that it was like 'log -v' output and the lists of
> changed files from trunk merges became overwhelming. But if we just
> showed the log messages somehow intelligently grouped by author and with
> a limit on the number we showed in the mail, I think it might be better
> than what we have today.
>
> Cheers,
> mwh
>

OK, lets see what we can do.

  status triaged

As mentioned at the pub this evening, I'm in the same boat as Thierry ;-)

My main gripe is that the patch attached to the email message includes the *full diff* of everything that's changed, but the body of the email merely includes the highest level commit message, "merged a bunch of fixes". If all of the changes are going to be flattened into a single monolithic diff, I think it would be prudent to flatten and include the changelog of everything in the merge.

In Ubuntu packaging, we strongly suggest that developers merging packages do something similar when they build the *.changes file. If merging from Debian, and several revisions have gone by, we like to see all the changelog entries between now and the last upload, using dpkg-genchanges's
       -vversion
              Causes changelog information from all versions strictly later than version to be used.

So there is sort of prior art here, that it would be nice if we were consistent with...

\o/

Sorry that we haven't had any progress on this, we've been fighting a war on tech debt and performance. If someone would like to hack on this it should be pretty straight forward: just pass more options to the bzr log code, to get the included commits; the attached diff can stay as-is. Its probably a few hours work for someone.

Honestly, Rob, this is less important to me now than it was before.
Just FYI. Thanks ;-)