 |
|
Is the correct answer.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
It shows a distinct lack of intellectual curiosity that the journo didn't even open on up to see what was inside.
He also didn't follow the logic through: the case it came in wasn't a disk either.
|
|
|
|
|
The 3 1/2" discs were also floppy; it was the case that was rigid.
If I put water in a steel canteen, the water is still liquid.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I agree I probably should have noted this, but I am not sure the general public (those not on CodeProject) think about it that way - obviously the writer (I find it difficult to call him a journalist) never cracked open a 3 1/2" floppy disk case.
Soren
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I use tape all the time. As a verb. Why just yesterday I taped a message. On the side of my computer, so I would be reminded to do something.
Floppy disks were indeed floppy. That was before they made them hard. Especially if you took them out of the wrapper they were in. Yes, after spilling a soft drink on a floppy, I did take one out, wash it off and put it in another so I could still use it. I figure the next best thing will be flexible electronics, so everything will be floppy again.
So, if we shouldn't use "search engine", is it OK to use "search engines" to refer to the whole group of Bings and Googles and ... ?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Obviously written by a 20-something douchebag with only a grammar school education.
Artificial intelligence is a useful term for any application that deliberately emulates human reasoning to solve a problem.
'Surfing the web' is evocative of the experience: lightly touching here and there, occasionally dipping your toe in, drowning in the breakers if you're not careful.
'Web cam', a camera for putting pictures and video on the web. What's wrong with that?
'Tape' as a verb; we still use the phrases 'turn it up' or 'turn it down' for volume, don't we?
Smartphones; not all of them are smart, thankfully, and they still make actual phone calls.
At one time, floppy disks were indeed floppy[^].
Software Zen: delete this;
|
|
|
|
|
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository."
The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS.
To all the potential git authors / bloggers / developers out there:
I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings.
For example, "commit" in Git could be better described using the word "stage".
Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar.
In fact, I don't think the word "commit" should be used at all with Git!
Marc
|
|
|
|
|
Marc Clifton wrote: I don't think the word "commit" should be used at all with Git!
You don't the developers should all be committed? 
|
|
|
|
|
Well, generally we are afraid of commitment...
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
That's what makes version control so desirable.
|
|
|
|
|
Indeed. Making a branch...
|
|
|
|
|
|
Yeah, in fact while we are at it, I disagree with the term "checkout" because you are just retrieving a local copy of the file in question. When you checkout a book from a library, you have total control of it until you return it ("checkin").
I worked with another (corporation private) source code system where you really did checkout the file. If you did so, you 'owned' it until you checked it back in and nobody else could touch it. A concurrent checkout feature later appeared, which is similar to what all of the other SCMs do, but it had a different verb.
--
Harvey
|
|
|
|
|
Exactly. Great point.
Marc
|
|
|
|
|
H.Brydon wrote: When you checkout a book from a library
no one else can read it. That's not how version control works.
In CMS it's RESERVE, like reserving a table in a restaurant -- others can see it but only you can use it. And if you reserve it but don't use it people start complaining and telling you to UNRESRERVE it if you're not actually going use it.
|
|
|
|
|
Okay I'll agree with that... but in a library with conventional books (ie. the paper kind) you don't have to checkout a book to read it or photocopy something in it. If you checkout something, it is in 'checked out' status until it is returned to the library and goes through the checkin process.
Conventional SCMs treat a checkout as "gimme a copy" without any gateway mechanism or record of who has it checked out. That's not really a checkout in the conventional sense.
My point is that an SCM checkout doesn't really check anything out.
--
Harvey
|
|
|
|
|
But stage is already taken by the ... well, stage (the thing you add to before you commit it) 
But you are right, understanding that everything except push and fetch happen on the local repository took a while to get used to. And git terminology is so overwhelming it sucks. It'll bombard you with mystic messages on every step.
|
|
|
|
|
Looks like you just don't 'Git' it, eh? 
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Sorry.
...
...
...
...
(Neither do I!)
Bob Dole The internet is a great way to get on the net.
 2.0.82.7292 SP6a
|
|
|
|
|
Oh, go on, git out of town! 
Marc
|
|
|
|
|
brisingr@gryphon-pc ± git quit "I HATE GIT!"
Git has quit.
brisingr@gryphon-pc $
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
Hey Marc, I'll hold him/her/it down while you do the kicking.
Software Zen: delete this;
|
|
|
|
|
My feeling is that there is a lack of understanding of the concept of a hierachy of repositories. When the file is added to your local repo it is being committed in the classic VCS sense, as it is being added/updated in a versioned controlled repository. The difference is that the respository is (typically) personal rather than (unusually) shared. When you copy your versions to the remote location you are combining together repositories, which is quite a different act to the commit of a number of files.
|
|
|
|
|
I think the word to meaning changes have much to do with the Linus Torvalds[^] absolutely hating the way svn, tfs and others did things and deciding to develop git in a vacuum (sort of speak) as in completely throwing the baby out with the bath water in terms of the conventions that developers were familiar with and starting over from scratch. Like learning Chinese and then learning Spanish. They both have ways of saying I am hungry but that is where the similarities end. Note: I know nothing of either languages but, it was a wild guess that they have no influence on each other.
|
|
|
|
|
I don't think in this particular case it's the wording.
Git uses a significantly different model than most centralized VCSs. Essentially, git doesn't manage versions, it manages patches, and lets you mix and match these at will. While at it, it takes great care to keep a history of all the mixing and matching you did. Now, this pretty much make the notion of a version in the way other VCSs define and use it vanish. And that's where the big problem lies. Head is just a convention, there's nothing that makes head essentially different from any other branch, other than people connecting to a repo designating it as head and the repo forcing you to merge in patches previously merged on head if you want to add another patch. But in the end it's still just a collection of patches.
[Off topic from here onwards]
The model is quite flexible and powerful, but I don't think there are many dev shops actually needing this power. Your customer doesn't want several branches, he just wants head, so eventually you need to merge every patch into head. Why bother with patch management at its best, then?
This whole patch management headache makes sense when you maintain the Linux kernel (quite a few million), receive lots of patches from thousands of developers (about a million lines were deleted/removed or changed from the 3.3 to 3.5 dev version evolution) and have different distros merge and match distinct sets of patches from one version to the next, a traditional VCS won't cut it.
IMO, it makes sense to see where you stand between two extremes: the single developer which just wants to track his sources, and doesn't maintain distinct branches, and the Linux kernel. Depending on where you stand, git might absolutely not make sense. Or svn.
What I've seen people do is use git for configuration management. This is IMO brain-damaged. Git is a VCS, not a tool for managing binary variants of distinct libs, apps and the like.
|
|
|
|
|
Yeah. It is the result of a geek (he who must not be named) working over a weekend and no one reviewing the work.
If the lord himself wrote it, it must be you who is stupid enough not to understand it, right?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
