Good points there, all of them. Even when it comes to planes, pilot training does teach them the general theory of how their engines, whether reciprocating or turbine, work, even if it doesn't teach them how to maintain/repair them.
I admit my own Git knowledge isn't the best, but then again, I am willing and working on learning it better. The extent of my current knowledge outside of the commands I use is that I know a bit about its object store (trees and blobs) and I'm familiar with some of the other commands and features, even if I don't use them. I also fully admit that if I had to use Git at work, not only would I be much more knowledgeable about it purely from more extensive usage, but I absolutely would learn more about it even beyond my day to day stuff because you never know when you might need to use obscure feature X. As it is right now, I do try to read up more on Git, listen to Git podcasts, etc., in my spare time to broaden my knowledge.
I'll have to add, though, that if you're using Git as a single user vs. a group, it is much simpler to use and you could probably get away with knowing less about it and still be proficient enough. A lot of Git's more advanced capabilities are for dealing with distributed and group development. When you're a sole developer, you probably won't be doing too many complicated merges, so it's easy to slack off on learning those features. However, it would still be a good idea to learn those additional features in case your project ever expands from being a single user pet project.
Now I gotta go look up what Git "Fast-forward" vs. "Merge made by the 'recursive' strategy" means. Gee, thanks! :P
If you already know about trees and blobs, you know way more about Git than you give yourself credit for. It is true that if you are not sharing your code with anyone there are many things you do not have to learn, such as push, pull, fetch, remotes, etc. But even working with yourself you might have the code on multiple machines and use a private Github repo, and then you have to learn them.
Oh, I know about push, pull, fetch, and remotes as it is (or to a limited extent -- I think I should learn more about them and I'm ashamed to admit that I haven't yet). I actually keep all my Anime Boston stuff in a git repo and use git to keep it synchronized between all my machines.
Oh, I know about push, pull, fetch, and remotes as it is (or to a limited extent -- I think I should learn more about them and I'm ashamed to admit that I haven't yet). I actually keep all my Anime Boston stuff in a git repo and use git to keep it synchronized between all my machines.
I think you know a lot about Git, and are thinking you don't know.
Well, I have trouble with push, so I usually just do a lot of back-and-forth pulls, although I think my trouble with push is that I'm not using a bare repo anywhere, so I need to monkey more with branches and such than I'd like in this relatively simple scenario. If I remember correctly, you can't push to a checked out branch, and that might be my problem. I've had no problems pushing to Github for another project I'm working on there.
I guess I think I don't know all that much about Git because I pretty much only use a tiny subset of its functionality, even though I think I know that subset fairly well. I've never had to use rebase or bisect and, as such, even though I have a high-level idea as to what they do, I don't think I'm knowledgeable about them because I don't know how to use them off the top of my head. Then there's all the history rewriting stuff git lets you do... Maybe my problem is that I can't consider myself knowledgeable about it until I have guru-level knowledge.
If you are trying to just copy your code between two separate machines both owned by you to work on, do not use push. Push is used to push specific commits onto remotes. If you want to move your work from your desktop to your laptop, just copy or rsync the entire folder. You actually only need the .git folder, but you may as well copy your working files anyway.
Yeah, rsync would've probably been sufficient, but I've been keeping all my stuff in source control for reasons other than syncing anyway, so I just used 'git pull'.
Yeah, rsync would've probably been sufficient, but I've been keeping all my stuff in source control for reasons other than syncing anyway, so I just used 'git pull'.
git pull = git fetch; git merge
What I would suggest instead is to use git fetch --all. This will download every branch from the remote, but won't merge anything so you can do that later by hand to get exactly what you want.
Hmm, that will probably work as I don't really do much branching for my Anime Boston stuff anyway (though that may change if I ever get around to doing a from-scratch rewrite of my Anime Boston panel tracking stuff).
Hmm, that will probably work as I don't really do much branching for my Anime Boston stuff anyway (though that may change if I ever get around to doing a from-scratch rewrite of my Anime Boston panel tracking stuff).
Every different task/component/bugfix/feature should have its own branch. Then you merge them into master when they are ready. This gives you the ability to easily build releases by selectively merging in what you want, and not merging what you don't.
Hmm, that will probably work as I don't really do much branching for my Anime Boston stuff anyway (though that may change if I ever get around to doing a from-scratch rewrite of my Anime Boston panel tracking stuff).
Every different task/component/bugfix/feature should have its own branch. Then you merge them into master when they are ready. This gives you the ability to easily build releases by selectively merging in what you want, and not merging what you don't.
Yep, I know that, but my Anime Boston stuff isn't set up like a traditional dev setup. It's mostly just logging changes to data files except for the handful of email scripts and templates I also have there. I did use branches more in the past when stuff was newer and I was actually developing more code for it. Nowadays, the code is pretty much all written, if old and creaky, so there isn't much in the way of new development going on there. However, if I do the aforementioned rewrite, I'll definitely use the recommended practices you mentioned.
If you understand the git object model and the index, then you're 90% there. Then it's simply mapping what you want to do to the commands. I don't mind if someone has to look up the more obscure commands as long as they understand the model and, as importantly, the social considerations unique to the repo we share. These would all be agreed upon in advance, e.g., prefer rebases to merges, don't merge master into topic branches frequently, and do a code review before touching master.
All I ever ask for is the ability to have independent workspaces and be able to save and shelve changesets. Sadly our current version of our version control software doesn't support shelving changes. Newer versions apparently do.
If we're going into semantics, that's a bad description too, because LaTeX handles far more than just layout. First and foremost it's a markup language (or if we're being really pedantic, a bunch of macros built on top of TeX), but that's not a very descriptive term. However, the term is also used to refer to the broader system, and as far as describing that I guess it's best to stick with the official term "document preparation system".
Basically, though, LaTeX, in conjunction with a text editor, performs the functionality one is usually referring to when one uses the term "word processor", and plenty more besides.
So, with greater accuracy in mind, it would be better to say something like this: "the Hole Hawg of word processing is the LaTeX ecosystem, in combination with Vim."
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Well, in that case the Hole Hawg of every computing task is x86-64 machine code ^_~
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Well, in that case the Hole Hawg of every computing task is x86-64 machine code ^_~
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Well, in that case the Hole Hawg of every computing task is x86-64 machine code ^_~
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Well, in that case the Hole Hawg of every computing task is x86-64 machine code ^_~
Hole Hawg in this case would probably be emacs (which ships with some crazy ass TeX/LaTeX macros out of the box and the ability to modify them/write your own as well) combined with straight TeX (LaTeX is just a bunch of TeX macros -- anything LaTeX can do, straight TeX can do with enough effort). :P
Well, in that case the Hole Hawg of every computing task is x86-64 machine code ^_~
Comments
I admit my own Git knowledge isn't the best, but then again, I am willing and working on learning it better. The extent of my current knowledge outside of the commands I use is that I know a bit about its object store (trees and blobs) and I'm familiar with some of the other commands and features, even if I don't use them. I also fully admit that if I had to use Git at work, not only would I be much more knowledgeable about it purely from more extensive usage, but I absolutely would learn more about it even beyond my day to day stuff because you never know when you might need to use obscure feature X. As it is right now, I do try to read up more on Git, listen to Git podcasts, etc., in my spare time to broaden my knowledge.
I'll have to add, though, that if you're using Git as a single user vs. a group, it is much simpler to use and you could probably get away with knowing less about it and still be proficient enough. A lot of Git's more advanced capabilities are for dealing with distributed and group development. When you're a sole developer, you probably won't be doing too many complicated merges, so it's easy to slack off on learning those features. However, it would still be a good idea to learn those additional features in case your project ever expands from being a single user pet project.
Now I gotta go look up what Git "Fast-forward" vs. "Merge made by the 'recursive' strategy" means. Gee, thanks! :P
I guess I think I don't know all that much about Git because I pretty much only use a tiny subset of its functionality, even though I think I know that subset fairly well. I've never had to use rebase or bisect and, as such, even though I have a high-level idea as to what they do, I don't think I'm knowledgeable about them because I don't know how to use them off the top of my head. Then there's all the history rewriting stuff git lets you do... Maybe my problem is that I can't consider myself knowledgeable about it until I have guru-level knowledge.
What I would suggest instead is to use git fetch --all. This will download every branch from the remote, but won't merge anything so you can do that later by hand to get exactly what you want.
Also, lol at Scott being so angry it made Rym touch his knob.
Basically, though, LaTeX, in conjunction with a text editor, performs the functionality one is usually referring to when one uses the term "word processor", and plenty more besides.
So, with greater accuracy in mind, it would be better to say something like this: "the Hole Hawg of word processing is the LaTeX ecosystem, in combination with Vim."