mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"\"S.Çağlar Onur\"" <caglar@pardus.org.tr>
Subject: Re: [PATCH] Add *.rej to .gitignore
Date: Tue, 17 Feb 2009 22:36:39 +0100	[thread overview]
Message-ID: <20090217213639.GA2949@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.0902171315400.21686@localhost.localdomain>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 17 Feb 2009, Jeremy Fitzhardinge wrote:
> > 
> > (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
> 
> I really dont' think we should ignore .rej files. 
> 
> They are _error_ cases, after all. People want to know about 
> them. And if you don't want to see them, you should remove 
> them.

hm, ok. Still it would be nice to have some sort of commit-time 
reminder.

I _do_ notice .rej files because i have:

  chmod +x .git/hooks/pre-commit

in my repo and .rej files trigger the checks there.

But the pre-commit hook is pretty painful to use when merging 
upstream updates: in the upstream kernel there's tons of commits 
that scream out loud and i have to commit a second time via 'git 
commit -n'.

I'm still holding out and all the commits we do in our repo are 
.git/hooks/pre-commit-clean, but it's discomforting to see how 
much stuff goes into the kernel with basic problems.

Just do something like this:

   $ chmod +x .git/hooks/pre-commit

   $ git checkout -b tmp.test v2.6.28

   $ git merge --no-ff --no-commit v2.6.29-rc5
   [...]
   Automatic merge went well; stopped before committing as requested

   $ git commit 2>&1 | grep ' (line ' | wc -l
   5334

So 5334 lines with trivial problems were introduced in this 
cycle alone (and that only scratches the surface really) - 
that's about 0.5% of all new lines (we added about 1 million new 
lines in this cycle).

That rate is too high IMO and the noise makes it harder to use 
this tool.

	Ingo

  reply	other threads:[~2009-02-17 21:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17 19:59 Jeremy Fitzhardinge
2009-02-17 20:08 ` Sam Ravnborg
2009-02-17 21:16 ` Linus Torvalds
2009-02-17 21:36   ` Ingo Molnar [this message]
2009-02-17 22:20   ` Alexey Dobriyan
2009-02-17 22:38 ` David Miller
2009-02-18  0:05   ` Ingo Molnar
2009-02-18  0:40     ` Sam Ravnborg
2009-02-18  0:49       ` Ingo Molnar
2009-02-18  1:05         ` David Miller
2009-02-18 15:21         ` Stefan Richter
     [not found] <c6Eh1-7Og-19@gated-at.bofh.it>
     [not found] ` <c6GLO-3xO-35@gated-at.bofh.it>
     [not found]   ` <c6IaO-60k-5@gated-at.bofh.it>
2009-02-19 20:25     ` Bodo Eggert

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=20090217213639.GA2949@elte.hu \
    --to=mingo@elte.hu \
    --cc=caglar@pardus.org.tr \
    --cc=gitster@pobox.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --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®