This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binutils-cvs commit announcements

Sorry for the huge delay! I was in the US making some open-source
history for the whole of November and a bit of December too, and now
I'm living on the far side of the world from where I was! I just
happened to stumble upon your reply (buried in an inbox with hundreds
of other emails) while clearing out these exact emails with this

"gdb and binutils branch" in:inbox

And this popped up at the far end!

By all means, do send the script and I'll see what I can come up with!
I agree with your sentiments about git log, however for someone with
an interest in only certain aspects of binutils (core and XYZ arch)
the emails used to be nice to draw attention to a certain subset of
commits and easily ignore all others. Once attention is drawn, a more
detailed analysis can be done if warranted.

I guess the main question is whether it's a terrible idea to send N
emails for N commits? I would assume that it's undesirable, even
though this is how it was before. I wouldn't mind the volume myself,
provided the commit messages were high-quality, however it would for
sure mean a landslide of emails, which will certainly irritate many

Is *anyone* else subscribed to that list? If so, what are your preferences?


On Tue, Nov 19, 2013 at 4:30 AM, Tom Tromey <> wrote:
> Fred> And yes, I understand that it's being done on a per-push basis, rather
> Fred> than per commit as before, so either choose the first commit or last
> Fred> in the case of more than one, and add "plus 6 more..." or send N
> Fred> emails for N commits? This is how it was before, after all.
> It's not totally trivial.
> If you like I can send you the script and you can send a patch to
> implement what you want.  I'm fine with putting it in.
> Fred> My 2c. It just seems a shame as before you could see what they were up
> Fred> front and ignore the uninteresting ones. Now you either have to open
> Fred> all of them and read everything, or ignore the lot. I was reading
> Fred> certain commits before, but now I could only do it based on the
> Fred> author, which isn't useful if the commits are in the form of a
> Fred> supplied patch.
> I find it much more convenient to just pull and then "git log" according
> to the whim of the moment.
> Tom

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]