While we are at such requests ...
When you pull from one of the trees, like netdev, the commit messages
are sent to the bk commit list with the original date stamp of the patch
in the netdev tree.
For example, if Jeff commited a patch from somebody in his netdev tree 3
weeks ago, and you pull Jeff's tree today, we'll get all the commit
messages today, but dated from 3 weeks ago.
That means that in my mailing list archive, where my mailer sorts them
by date, I can't say, for example, everything that is before the 2.6.11
tag release was in 2.6.11. It's also difficult to spot "new" stuffs as
they can arrive with dates weeks ago, and thus show up in places I will
not look for.
I don't know if I'm the only one to have a problem with that, but it
would be nice if it was possible, when you pull a bk tree, to have the
commit messages for the csets in that tree be dated from the day you
pulled, and not the day when they went in the source tree.
Ben.
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
>
> I don't know if I'm the only one to have a problem with that, but it
> would be nice if it was possible, when you pull a bk tree, to have the
> commit messages for the csets in that tree be dated from the day you
> pulled, and not the day when they went in the source tree.
Nope, that's against how BK works. It's really distributed, so "my" tree
has no special meaning, and as such the fact that I pull has no meaning
either - it doesn't trigger as anything special.
The only thing that ends up being special is when it hits the public tree
which has the trigger to send out the emails. IOW, the date of the _email_
is special (in that it says when a commit hit the public tree), not not
the commits changesets themselves.
Now, if James trigger scripts set the date of the email by the date of the
commit, that sounds like a misfeature, but you'd better talk to James, not
me, since he's the one doing that part..
Linus
Two's company ...
On Thu, 10 Mar 2005 13:41, Benjamin Herrenschmidt wrote:
> While we are at such requests ...
>
> When you pull from one of the trees, like netdev, the commit messages
> are sent to the bk commit list with the original date stamp of the patch
> in the netdev tree.
>
> For example, if Jeff commited a patch from somebody in his netdev tree 3
> weeks ago, and you pull Jeff's tree today, we'll get all the commit
> messages today, but dated from 3 weeks ago.
>
> That means that in my mailing list archive, where my mailer sorts them
> by date, I can't say, for example, everything that is before the 2.6.11
> tag release was in 2.6.11. It's also difficult to spot "new" stuffs as
> they can arrive with dates weeks ago, and thus show up in places I will
> not look for.
>
> I don't know if I'm the only one to have a problem with that, but it
> would be nice if it was possible, when you pull a bk tree, to have the
> commit messages for the csets in that tree be dated from the day you
> pulled, and not the day when they went in the source tree.
>
> Ben.
On Thu, 10 Mar 2005 13:41:59 +1100
Benjamin Herrenschmidt <[email protected]> wrote:
> I don't know if I'm the only one to have a problem with that, but it
> would be nice if it was possible, when you pull a bk tree, to have the
> commit messages for the csets in that tree be dated from the day you
> pulled, and not the day when they went in the source tree.
When I'm working, I just do "bk csets" after I pull from Linus's
tree to review what went in since the last time I pulled.
On Wed, 2005-03-09 at 19:47 -0800, David S. Miller wrote:
> On Thu, 10 Mar 2005 13:41:59 +1100
> Benjamin Herrenschmidt <[email protected]> wrote:
>
> > I don't know if I'm the only one to have a problem with that, but it
> > would be nice if it was possible, when you pull a bk tree, to have the
> > commit messages for the csets in that tree be dated from the day you
> > pulled, and not the day when they went in the source tree.
>
> When I'm working, I just do "bk csets" after I pull from Linus's
> tree to review what went in since the last time I pulled.
Yes, but the commit list archive is handy. I have quite good search
capabilities in my mailer for example, and sometimes, when doign
regression, it's quite useful to browse what went in between two
releases with it (it's just more handy than bk csets).
Ben.
On Wed, 2005-03-09 at 19:28 -0800, Linus Torvalds wrote:
>
> On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
> >
> > I don't know if I'm the only one to have a problem with that, but it
> > would be nice if it was possible, when you pull a bk tree, to have the
> > commit messages for the csets in that tree be dated from the day you
> > pulled, and not the day when they went in the source tree.
>
> Nope, that's against how BK works. It's really distributed, so "my" tree
> has no special meaning, and as such the fact that I pull has no meaning
> either - it doesn't trigger as anything special.
Yes, but it would be easy to have the messages dated from the day they
are sent :) Even if you put the real commit date in the message itself.
It's really disturbing to receive mails dated a long time in the past
don't you think ?
> The only thing that ends up being special is when it hits the public tree
> which has the trigger to send out the emails. IOW, the date of the _email_
> is special (in that it says when a commit hit the public tree), not not
> the commits changesets themselves.
Yes, but the email gets the old date.
> Now, if James trigger scripts set the date of the email by the date of the
> commit, that sounds like a misfeature, but you'd better talk to James, not
> me, since he's the one doing that part..
Hah ok. Which James ?
Ben.
Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 19:47 -0800, David S. Miller wrote:
>
>>On Thu, 10 Mar 2005 13:41:59 +1100
>>Benjamin Herrenschmidt <[email protected]> wrote:
>>
>>
>>>I don't know if I'm the only one to have a problem with that, but it
>>>would be nice if it was possible, when you pull a bk tree, to have the
>>>commit messages for the csets in that tree be dated from the day you
>>>pulled, and not the day when they went in the source tree.
>>
>>When I'm working, I just do "bk csets" after I pull from Linus's
>>tree to review what went in since the last time I pulled.
>
>
> Yes, but the commit list archive is handy. I have quite good search
> capabilities in my mailer for example, and sometimes, when doign
> regression, it's quite useful to browse what went in between two
> releases with it (it's just more handy than bk csets).
Speaking strictly in terms of implementation, David Woodhouse's
bk-commits mailer scripts could probably easily be tweaked to -not- set
an explicit Date header on the outgoing emails.
It then becomes a matter of deciding whether this is a good idea or not :)
Jeff
On Thu, 2005-03-10 at 01:13 -0500, Jeff Garzik wrote:
> Speaking strictly in terms of implementation, David Woodhouse's
> bk-commits mailer scripts could probably easily be tweaked to -not- set
> an explicit Date header on the outgoing emails.
>
> It then becomes a matter of deciding whether this is a good idea or not :)
The original changeset date is also in the body of the mail anyway so it
wouldn't be lost if we changed this. I have no real preference either
way. Bear in mind that the Date: header you got would then be the time
my script ran, not the time it was actually committed. That may differ
by days, in some cases (thankfully not often).
--
dwmw2
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote:
>
> > Now, if James trigger scripts set the date of the email by the date of the
> > commit, that sounds like a misfeature, but you'd better talk to James, not
> > me, since he's the one doing that part..
>
> Hah ok. Which James ?
I was thinking about Bottomley, but Jeff points out that it's not James
who does it, but David Woodhouse.
I'm a retard.
Linus
On Thu, Mar 10, 2005 at 07:11:45AM -0700, David Woodhouse wrote:
> On Thu, 2005-03-10 at 01:13 -0500, Jeff Garzik wrote:
> > Speaking strictly in terms of implementation, David Woodhouse's
> > bk-commits mailer scripts could probably easily be tweaked to -not- set
> > an explicit Date header on the outgoing emails.
> >
> > It then becomes a matter of deciding whether this is a good idea or not :)
>
> The original changeset date is also in the body of the mail anyway so it
> wouldn't be lost if we changed this. I have no real preference either
> way. Bear in mind that the Date: header you got would then be the time
> my script ran, not the time it was actually committed. That may differ
> by days, in some cases (thankfully not often).
I've just been using sort by arrival as an imperfect, but still mostly
correct work-around (a few things have shown up after the email with the
tag, but only a few). I'd argue having the mails have the fuged date is
useful when trying to re-create sub-sets of a given tree.
Note that for the specific problem Ben has (looking at all ChangeSets
from A to B), I've got a kinda slow script that fakes the bk-commits
messages given two repositories, if this sounds of any interest to
anyone.
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Mar 10, Tom Rini wrote:
> I've just been using sort by arrival as an imperfect, but still mostly
Just procmail the stuff, if bk cant do it.
:0 f
* ^X-my-mailinglist-tag: bk-commits-head.vger.kernel.org
| formail -i "Date: `env TZ=UTC date -R`"
This doesnt help for "out of order" arrival, but you get the idea about
"what happend yesterday".