[PATCH] Add *.rej to .gitignore

[PATCH] Add *.rej to .gitignore

[Jeremy Fitzhardinge]

*.rej files really are unwanted.  If there are any .rej files, they can be found by
some other means (perhaps git itself could warn when committing with *.rej files present,
or add some distinct notion of "ignored files" vs "never commit" files).

(This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

diff --git a/.gitignore b/.gitignore
index 869e1a3..3d56938 100644
--- a/.gitignore
+++ b/.gitignore
@@ -62,5 +62,6 @@ cscope.*
 ncscope.*
 
 *.orig
+*.rej
 *~
 \#*#

Re: [PATCH] Add *.rej to .gitignore

[Sam Ravnborg]

On Tue, Feb 17, 2009 at 11:59:37AM -0800, Jeremy Fitzhardinge wrote:
> *.rej files really are unwanted.  If there are any .rej files, they can be 
> found by
> some other means (perhaps git itself could warn when committing with *.rej 
> files present,
> or add some distinct notion of "ignored files" vs "never commit" files).
> 
> (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)

When working with patch having .rej files to show up in "git status"
and "git commit" is a nice reminder to you that there was
some manual work to be done.

So unless git are educated to remind you by other means we should
keep the current behaviour and be reminded when we see .rej
files present in "git status" / "git commit".

In other words - I do not agree on applying this patch.

	Sam

Re: [PATCH] Add *.rej to .gitignore

[Linus Torvalds]

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.

		Linus

Re: [PATCH] Add *.rej to .gitignore

[Ingo Molnar]

* 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

Re: [PATCH] Add *.rej to .gitignore

[Alexey Dobriyan]

On Tue, Feb 17, 2009 at 01:16:32PM -0800, Linus Torvalds 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.

Or you can see .gitignore as a list of files that shouldn't _ever_
be committed. This is objective definition instead of some
"we most certainly don't want to ignore them".

I added *.rej because of this, ignored revert, because was sick and
tired of possible arguing, and the inability of reverter to write
rej-ls script.

Re: [PATCH] Add *.rej to .gitignore

[David Miller]

From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Tue, 17 Feb 2009 11:59:37 -0800

> *.rej files really are unwanted.  If there are any .rej files, they can be found by
> some other means (perhaps git itself could warn when committing with *.rej files present,
> or add some distinct notion of "ignored files" vs "never commit" files).
> 
> (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
> 
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

I don't know about this.

I really want to know if there are reject files there if I
am checking to see if my tree is clean.

This has caught many patch application errors for myself
personally in the past, so I really don't want git to
start silently ignoring those things.

People should delete reject file explicitly, as they are
evidence of a patch that would not apply cleanly.  If you
abort trying to add the patch, fine, but cleaning up the
reject files is part of that operation.

Re: [PATCH] Add *.rej to .gitignore

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Jeremy Fitzhardinge <jeremy@goop.org>
> Date: Tue, 17 Feb 2009 11:59:37 -0800
> 
> > *.rej files really are unwanted.  If there are any .rej files, they can be found by
> > some other means (perhaps git itself could warn when committing with *.rej files present,
> > or add some distinct notion of "ignored files" vs "never commit" files).
> > 
> > (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
> > 
> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> 
> I don't know about this.
> 
> I really want to know if there are reject files there if I am 
> checking to see if my tree is clean.
> 
> This has caught many patch application errors for myself 
> personally in the past, so I really don't want git to start 
> silently ignoring those things.
> 
> People should delete reject file explicitly, as they are 
> evidence of a patch that would not apply cleanly.  If you 
> abort trying to add the patch, fine, but cleaning up the 
> reject files is part of that operation.

Well, it depends on the workflow. You are making the assumption 
that everyone is using your workflow, and you are judging them 
based on that false assumption.

In my workflow i never miss .rej files because i use tools that 
_do not allow_ rejects to occur - only if i intentionally force 
them. So i cannot "miss" any .rej files - i generate them very 
consciously so all my attention is on them already.

For example i never use the naked '/usr/bin/patch' tool for 
example (which generates rej files without any forcing) - i 
consider that practice a serious workflow error for various 
reasons.

In fact i prefer to keep .rej files around and not remove them, 
to have some minimal history and to be able to see recent 
rejects and if there's a problem i can still reconstruct whether 
i did a patch conflict resolution incorrectly.

What _can_ happen on the other hand is for a .rej file to get 
into a git repo accidentally - while nobody ever would want them 
to get into any git tree, ever.

So ... by all means this is a sane workflow, and Jeremy and 
Alexey i suspect has a similar workflow as well.

Anyway, the .rej problem can also be solved via the pre-commit 
hook - but unfortunately there's way too much sub-par commits 
from elsewhere in the tree, making consistent use of the 
pre-commit hook quite a challenge.

	Ingo

Re: [PATCH] Add *.rej to .gitignore

[Sam Ravnborg]

> > From: Jeremy Fitzhardinge <jeremy@goop.org>
> > Date: Tue, 17 Feb 2009 11:59:37 -0800
> > 
> > > *.rej files really are unwanted.  If there are any .rej files, they can be found by
> > > some other means (perhaps git itself could warn when committing with *.rej files present,
> > > or add some distinct notion of "ignored files" vs "never commit" files).
> > > 
> > > (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
> > > 
> > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > 
> > I don't know about this.
> > 
> > I really want to know if there are reject files there if I am 
> > checking to see if my tree is clean.
> > 
> > This has caught many patch application errors for myself 
> > personally in the past, so I really don't want git to start 
> > silently ignoring those things.
> > 
> > People should delete reject file explicitly, as they are 
> > evidence of a patch that would not apply cleanly.  If you 
> > abort trying to add the patch, fine, but cleaning up the 
> > reject files is part of that operation.
> 
> Well, it depends on the workflow. You are making the assumption 
> that everyone is using your workflow, and you are judging them 
> based on that false assumption.
> 
> In my workflow i never miss .rej files because i use tools that 
> _do not allow_ rejects to occur - only if i intentionally force 
> them. So i cannot "miss" any .rej files - i generate them very 
> consciously so all my attention is on them already.
So in your advanced usage it does not matter what git does
with .rej files.
And it hepls people using git in a more naive way.

This is an easy judgement - lets do what benefit the most.

	Sam

Re: [PATCH] Add *.rej to .gitignore

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> > > From: Jeremy Fitzhardinge <jeremy@goop.org>
> > > Date: Tue, 17 Feb 2009 11:59:37 -0800
> > > 
> > > > *.rej files really are unwanted.  If there are any .rej files, they can be found by
> > > > some other means (perhaps git itself could warn when committing with *.rej files present,
> > > > or add some distinct notion of "ignored files" vs "never commit" files).
> > > > 
> > > > (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
> > > > 
> > > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > 
> > > I don't know about this.
> > > 
> > > I really want to know if there are reject files there if I am 
> > > checking to see if my tree is clean.
> > > 
> > > This has caught many patch application errors for myself 
> > > personally in the past, so I really don't want git to start 
> > > silently ignoring those things.
> > > 
> > > People should delete reject file explicitly, as they are 
> > > evidence of a patch that would not apply cleanly.  If you 
> > > abort trying to add the patch, fine, but cleaning up the 
> > > reject files is part of that operation.
> > 
> > Well, it depends on the workflow. You are making the assumption 
> > that everyone is using your workflow, and you are judging them 
> > based on that false assumption.
> > 
> > In my workflow i never miss .rej files because i use tools that 
> > _do not allow_ rejects to occur - only if i intentionally force 
> > them. So i cannot "miss" any .rej files - i generate them very 
> > consciously so all my attention is on them already.
>
> So in your advanced usage it does not matter what git does 
> with .rej files.
>
> And it hepls people using git in a more naive way.
> 
> This is an easy judgement - lets do what benefit the most.

I'd argue with calling it 'naive', i'd call it 'dangerous'. 

Anyway, i definitely dont want to prevent others from having a 
defense against mistakes (even if those mistakes are at least 
partly self-inflicted).

My only beef is that i think i have a good workflow, still i 
have no efficient automated defense against .rej files getting 
into the tree. I have to use 'git commit -n' too frequently, and 
that overrides the pre-commit hook.

I.e. i should start using the workflow i consider more dangerous 
- and i should start removing .rej files while they are clearly 
useful even after the commit.

Isnt that backwards?

	Ingo

Re: [PATCH] Add *.rej to .gitignore

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 18 Feb 2009 01:49:19 +0100

> I'd argue with calling it 'naive', i'd call it 'dangerous'. 
> 
> Anyway, i definitely dont want to prevent others from having a 
> defense against mistakes (even if those mistakes are at least 
> partly self-inflicted).
> 
> My only beef is that i think i have a good workflow, still i 
> have no efficient automated defense against .rej files getting 
> into the tree. I have to use 'git commit -n' too frequently, and 
> that overrides the pre-commit hook.
> 
> I.e. i should start using the workflow i consider more dangerous 
> - and i should start removing .rej files while they are clearly 
> useful even after the commit.
> 
> Isnt that backwards?

I think by and large most people only commit with explicit additions
into the index file either by specifying files explicitly on the
"git commit" command line or explicitly calling "git add".

You see a problem when you're telling git "look at my tree and figure
out what to commit."  Putting the kitchen sink into .gitignore and
relying upon that is not a tenable solution.

Instead of hoping git does exactly what you want it to do, tell
it explicitly.

Re: [PATCH] Add *.rej to .gitignore

[Stefan Richter]

Ingo Molnar wrote:
> My only beef is that i think i have a good workflow, still i 
> have no efficient automated defense against .rej files getting 
> into the tree.

Only workflows which do not involve pull requests are prone to this.
-- 
Stefan Richter
-=====-==--= --=- =--=-
http://arcgraph.de/sr/

Re: [PATCH] Add *.rej to .gitignore

[Bodo Eggert]

Ingo Molnar <mingo@elte.hu> wrote:
> * David Miller <davem@davemloft.net> wrote:
>> From: Jeremy Fitzhardinge <jeremy@goop.org>

>> > *.rej files really are unwanted.  If there are any .rej files, they can be
>> > found by some other means (perhaps git itself could warn when committing
>> > with *.rej files present, or add some distinct notion of "ignored files" vs
>> > "never commit" files).
>> > 
>> > (This effectively reverts 1f5d3a6b6532e25a5cdf1f311956b2b03d343a48)
>> > 
>> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>> 
>> I don't know about this.
>> 
>> I really want to know if there are reject files there if I am
>> checking to see if my tree is clean.
[...]
> Well, it depends on the workflow. You are making the assumption
> that everyone is using your workflow, and you are judging them
> based on that false assumption.

If different users need different .gitignores, you need a per-user setting.
Let there be ~/.git/gitignore.