search

1RedOne / Get-UnknownDevices

A tool for identifying missing devices from DeviceManager
https://foxdeploy.com/2015/07/31/using-powershell-to-find-drivers-for-device-manager/
Apache License 2.0
30 stars 7 forks source link

Submit to PowerShell Gallery? #1

Open mgreenegit opened 9 years ago

mgreenegit commented 9 years ago

I think this is a great concept. Would you consider it for PowerShell Gallery? Also if you would like it to be a portable module, I would be happy to assist.

1RedOne commented 9 years ago

I actually went to submit it, but I don't have a full module yet, just this command so I just closed the tab :(

mgreenegit commented 9 years ago

See what you think about this. The folder contains the portable module. I also have it return information to indicate devices were skipped, and I don't know if that is of value to you or not. Without it my first impression was "why didn't it return anything?" https://github.com/mgreenegit/Get-UnknownDevices/tree/dev

If this is of interest to you, if you would like to create a dev branch I'll submit a pull request. If not, no big deal. Thanks.

1RedOne commented 9 years ago

Question: Whats the best practice for a situation like this? I've done some extra work so that it will not search for drivers within a .zip or .cab file ( a common situation for image engineering). Should I publish my changes over the original Get-UnknownDevices? Should I save it as Get-UnknownDevicesv2?

I don't come from a dev background so I'm not sure how to handle this.

Also, how does one generally go about handling changes to two branches at once then, like the work I've done, and you've done? I like the ideas you've implemented but kind of am lost in the 'gittiness' of this process.

mgreenegit commented 9 years ago

I come from the same background. Git tracks commits, so it is pretty easy to reference a previous version. That's also a nice thing about it being a module is you can easily track versions or even have multiple versions side by side.

Generally, you would want a "dev" branch where you are working on the next version and a "master" branch that has the current stable. You can Pull Request between branches to sync them up when you are ready. That also makes it easy for you to review and accept other people's Pull Requests because you can accept them in to dev and when you are ready you can merge in to Master.

There's a project called "Git Hug" that's like an interactive game for learning GitHub. That's what I used to get started and found it a good problem-solving oriented way to get familiar based on searching for how to handle the next puzzle. Just FYI.