![]() There are two situations which occur with regularity where writing is important. Sometimes, it's just reading (Windows laptop died, quick can I get the hard drive out and recover some documents). Lots of stuff in there I don't need, but that's a terrible argument for leaving it out.Īs for uses, I have repeatedly mounted NTFS disks on Linux recently. Compatibility with a number of processor types which I haven't used and don't plan to? Drivers for hardware that I don't have and isn't modern enough that I'm likely to get one. So because you don't need it, nobody else does either? If I unleashed that theory on the Linux kernel, I'd sheer off a ton of things I've never used. "I've been using Linux for over well 10 years now and I can't recall the last time I had to look into a NTFS format drive." This is due to github's recent policy change regarding pass phrases and git command line, and the method I use can be put on computers you do not own (like customer machines) as needed to access github repos without revealing your token. Then, when you do 'git push' and git prompts for user/pass, you type in the user and paste the token when it prompts for password. In short, you would encrypt the github issued 'password' token in a file, and then run the utility from a command shell (say 'bash') and enter your pass phrase, and the github token will be on the clipboard. If you search for it on github, I wrote a simple program that lets you use a pass phrase to decrypt an encrypted file and put its contents in the clipboard (for X11 systems though). ![]() The rest of the commands can be looked up in the docs "whenever", as needed. You really only need to memorize and master a few git commands: Then use 'git commit' followed by 'git push' to your dev branch, and then do the pull request. Therefore you should just do all of your merges and any additional edits using a decent local merge tool (maybe 'meld'?) between your local working copy and the dev branch on github, after you do a 'git pull' on your local copy of the dev branch so you know that what you're comparing to for your merge is at least CLOSE to what you'll be doing the pull request for (assuming that no major edits in the official branch affect the pull request). submitting your dev branch's differences from the official repo) the github inteface works very well. When I read that part, I knew EXACTLY why Linus would say this. example follows.įrom the article: you should never ever use the github interfaces to merge anything (but that doesn't take the sting out of it the first time you sit down to use it.) However, the choice of nomenclature does begin to make more sense the more you become steeped in git. ![]() So there is learning involved (the choice of nomenclature just makes things that much more uncomfortable). ![]() (there are some of those floating around though) To the git project's credit there are very good tutorials to help you make friends with it, but the downside is they are some 30 page tutorials that are not geared to answer "the top 10 things you normally need to know to use git". The git command line is its own little language. The git nomenclature does suck! Not that it is bad, but that it is completely non-intuitive for someone who may otherwise be very skilled and fluent in a number of other projects that are now hosted on Github. You wouldn't sit down to write something in C having only a passing knowledge of the language, or you wouldn't write a Bind config or zone file without significant effort to learn the lingo of the Berkeley DNS named server. The CLI for git is a fantastic tool, but just like any advanced piece of software, you have to make friends with it first.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |