“Did you check it in and push it up to Github?”
@gerthworm if you don’t name it “Perls of Wisdom” then I will be highly disappointed in you.
Commits are free, and try to commit at the end of each meeting. Don’t have a full set of patch notes for your commit like I did once:
Meeting? Nah, try to commit whenever you reach some new “oh cool this part works” or when you wanna try something new… commits are free and branches are too.
" A C program is like a fast dance on a newly waxed dance floor by people carrying razors." - Waldi Ravens
Ignore the real meaning of the words used in computer languages.
- In English, to commit* means that you’re making a decision not to go back. In Git, to commit means that you might want to come back to where you are now.
- In English, continue means to proceed to the next or a later step. In C and many other computer languages, continue means to go back to a previous step.
* I know it has other meanings, but none of them mean “make a bookmark” either.
I love this. I know there are many more but I can not think of any at the moment. I always assumed the GIT usage of commit was related to publishing. It refernced the stage of forwarding it to the printers. But, I totally could have made that up.
I think it comes more from the history of revision control. Previous to Git, more VC systems meant “commit” to be like a database commit, and that point was the “master” current version. Git does seem a little different in its heavy use of branches.
In case of fire:
- git commit
- git push
- git out
This one to me feels a bit closer to normal English. In a loop, “continue” does proceed to the next step (the next loop iteration). Granted, proceeding to the next iteration does mean it goes back to the “top” of a for loop block, but especially when contrasted with “break” (out of the loop), the usage is pretty clear.
I’m not sure where it comes from but one that sticks with me a boss told me a while back is
“Make it work, Then make it work better”
“Scope, Cost, and Time, You can only pick two!”
It always takes twice as long as you’d expect, even when you consider Hofstadter’s law.
I had a programmer working for me under contract a couple of decades ago who was really good at estimating time. I eventually asked him his secret. He said something like “I spitball out how long I think it will take to write. Then, I add one for programming issues, and increase the unit for testing and fixing.” I asked for clarification. He said something like “If I think it will take 3 days, I add one to get four days, then increase the unit to four weeks. Two hours becomes three days. Three weeks becomes four months.” I’ve used his system since then. I’ve never been as eerily accurate as he was, but I was a whole lot closer using it than with anything else I’ve tried.
A few more that come to mind in languages that are still in use (There are some truly bizarre ones from FORTRAN 77 and older languages; DO loops and Holerith formats, anyone?.) (Related: Does anyone remember programming VCRs when they had a long row of buttons and no on-screen prompts?)
- In Git, a “pull” usually moves/copies information away from you.
- Git add does a set union, not a mathematical addition.
- “Run one of the following branches of code” is expressed many different ways with the similar words in different languages (e.g. switch and case), but none of them make sense.
- Many languages’ “for” commands execute a statement given before the looped block AFTER each execution of the block. I’m not sure for is the right word, but the order of arguments is out to lunch; they should be: initialization, test, block, update, not initialization, test, update, block.
- Actually, GIt is pathologically wrong; I can’t think of a single git command that does what I expected it to do when I read what was supposed to be an English word. Git is the IKEA of software development: elegant, sturdy, but with language that appears to be English but is baffling to those with English as a first language.
pull is a
fetch followed by a
merge. In other words, grab new data from a remote system, and then fold it into your local copy. In no circumstances that I can think of will
pull send data out.
The strategy I’ve started using is to figure out how long I think it will take, then I triple it. It’s served me well over the years.
I also don’t understand this statement:
- git commit “I’ve decided i like these changes and I’ve decided to keep them”
- git fetch “get me that stuff from over there yonder”
- git push “I’m gonna make this stuff go over there yonder”
- git pull “I’m gonna go get that stuff over there yonder and bring it back myself”
These all make perfect sense to me.
I’m guessing that @GeeTwo is talking about pull requests where you’re asking for the changes you made on your branch to be pulled into the main branch. This seemed backward to me because several other CM tools refer to this as pushing you changes onto the main branch.
It’s a pull request, you’re asking the main developer to pull from your branch into their repository, since you don’t have direct push access. Also see github - Why is a git 'pull request' not called a 'push request'? - Stack Overflow
That’s because pull requests are named horribly. Ideally they would be called merge request as they are a request to merge a change set into a given branch.