[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jan 2014 20:51:44 +0500
From: Muhammad Junaid Muzammil <mjunaidmuzammil@...il.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: CUDA multi-device support
Ok, Sure these are something that I would be considering in the future. I
am more comfortable with Linux command line, thats why I prefer to use git
status and git diff prior to making commits.
Surely, I'll look forward for handling the case when GPU devices
> MAX_CuDA_DEVICES.
Currently, I don't have physical multi GPU access. Will have to look for
some alternatives.
On Tuesday, January 7, 2014, magnum wrote:
> On 2014-01-07 10:11, Frank Dittrich wrote:
>
>> On 01/07/2014 06:44 AM, magnum wrote:
>>
>>> and always review things like PRs,
>>>
>>
>> Yes, there should just be your own few commits.
>> And if you notice unrelated changes in them, you might want to "git
>> rebase" first.
>>
>
> That may solve it, or make a mess of your changes. The real problem was
> that you staged changes that wasn't yours. I think it's safer to say that
> if you see unrelated changes in your commit you should "git reset --soft"
> back and redo it right. Or just fire up git-gui, tick amend and remove the
> bad stuff.
>
> Note that it's normally not a problem if the branch you request to pull is
> lacking the newest commits in my repo. You don't need to rebase unless the
> newer commits actually clashes because your branch sat for a while and got
> stale, like Sayantan's bleeding-mask branch.
>
> magnum
>
>
Content of type "text/html" skipped
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.
