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

From: Ingo Molnar
Date: Tue Feb 17 2009 - 19:05:34 EST



* 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/