[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090217.170502.86474205.davem@davemloft.net>
Date: Tue, 17 Feb 2009 17:05:02 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: mingo@...e.hu
Cc: sam@...nborg.org, jeremy@...p.org, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, gitster@...ox.com,
caglar@...dus.org.tr
Subject: Re: [PATCH] Add *.rej to .gitignore
From: Ingo Molnar <mingo@...e.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists