[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c75a5422a31925564eb2660030532bde@smtp.hushmail.com>
Date: Tue, 07 Jan 2014 11:25:42 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: CUDA multi-device support
On 2014-01-07 10:22, Frank Dittrich wrote:
> On 01/07/2014 06:44 AM, magnum wrote:
>> stage a hunk at a time as
>> opposed to a blind "git add -a ."
>
> I forgot to mention in my other reply: "a hunk at a time" should still
> be something that works as is. As a minimum requirement, it should still
> compile, and not cause build errors.
I meant *staging* a hunk at a time, it should still be a single commit
if applicable. Looking at the diff and then "git add" is OK too but it
is more prone to accidental inclusions (we recently had a binary
included in a topic branch because the few lines are easy to miss).
I always use git-gui (or gitx on OSX) and I often spot bugs at that
stage, so I can abort and fix it before it even enters the tree. I get
much better overview than with git-diff. It's also easy to omit
whitespace-only changes (you can stage individual lines in a hunk).
OTOH if you implement two different things and then start
staging/committing, it may be wise to split them to two separate
commits. What you said applies then, the first should not rely on the
second.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
