mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH] tracing: Fix the outmost stupidity of tracing_off()
Date: Thu, 14 Jun 2012 19:48:23 -0400	[thread overview]
Message-ID: <1339717703.13377.285.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1206150106511.3086@ionos>

On Fri, 2012-06-15 at 01:12 +0200, Thomas Gleixner wrote:

> That's still not an excuse for utter stupidity, really. Just check the
> commit date vs. your discovery time.
> 
> I told you often enough to be more careful, but that one is really
> beyond comprehension.

I'm really thinking that this was due to a bad push. As I believe I had
stale code (made this fix locally, but pushed the broken branch) and all
my changes were on top of it. When updating to the latest tip, I had
code I didn't want to merge, or conflicts happened, that I ended up
cherry-picking changes. Which breaks from my normal workflow, which is
to make sure my old changes fast forward to tip before doing a rebase of
my new code.

I have several branches that I work on and when they are ready, I rebase
them on top of tip, run a bunch of tests, and then push them out.

I'm a heavy user of tracing_off() too, and since the development of my
work is usually on older branches, I would not have noticed the bug. As
after I get things working I usually rebase on top of tip before doing
my final tests and asking for the pull request.

I'm usually very careful about checking that things fast forward and
such, and that rebases don't have strange conflicts. This one slipped
by, and yes, I'm extremely ashamed and embarrassed by it. That's why I
said in my pull request 'This was one of those "oh crap" moments'.

-- Steve



  reply	other threads:[~2012-06-14 23:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14 22:47 Thomas Gleixner
2012-06-14 22:50 ` Thomas Gleixner
2012-06-14 23:38   ` Steven Rostedt
2012-06-14 22:58 ` Steven Rostedt
2012-06-14 23:12   ` Thomas Gleixner
2012-06-14 23:48     ` Steven Rostedt [this message]
2012-06-15  0:00       ` Thomas Gleixner
2012-06-15  0:32         ` Steven Rostedt
2012-06-15  4:18       ` Steven Rostedt
2012-06-15 11:54         ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1339717703.13377.285.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®