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

[Ingo Molnar]

* David Miller <davem@xxxxxxxxxxxxx> wrote:

> From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
> 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@xxxxxxxxxx>
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/