I obviously didn't just learn about patch mode... git has many powerful features, but I feel this is the most powerful of those that many git users don't know about yet that will make the biggest positive impact in their daily git use. Not that patch mode is the most powerful feature git has.
I never advocate GUIs as the primary means by which a developer works with version control. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day.
If you write code day in day out you SHOULD be comfortable on the command-line. That's why I highlighted in the article that I need two tools to do my development: an editor and version control. You use these tools every day--EVERY day. There's no excuse for not knowing them intimately. They are the foundation for doing your job.
GUIs also aren't always available across platforms, either. For the most part, all the git CLI commands port from Mac, Linux and Windows (msysgit). Also, have you ever tried using a GUI when SSH'd into a remote server in a pinch? You can't. And you'll really wish you invested the time to learn those underlying CLI commands.
Do remember that half of all developers are below average/median for the relevant group. (See also "perpetual intermediates".)
My experience has been in forcing developers to use guis to do commits. It significantly improved their commits because they would browse over the changeset, could commit only specific hunks, didn't accidentally include extra gunk like test files, and generally made better messages.
It is certainly the case that the cli tools give experts the most power. But that power doesn't need to be exercised by everyone, and not even by experts on every occasion.
I would much rather my developer's heads are full of things relevant to the problem being solved (which is what pays the bills) than intricacies of cli tools.
What does a graphical diff and GUI message editor with interactive changelist management have to do with being "below median"? I came to write code, not restart my workflow from scratch every time I want to slightly edit my change.
Because everyone thinks of themselves as being above median, and a wiz at the tools. They know all the flags, workflows etc memorized and think everyone should be like them.
Whilst in the real world the other half do things like 'git commit -a' to make commits which likely picks up unwanted gunk. A gui does not require memorizing flags and makes everything plain.
I think denying beginners the GUI is particularly cruel. The command line is much more of an abstraction in this case, I think! - gitk displays the actual tree of this graph that git manipulates, but the command line just prints text ;) It's especially illuminating (or I found it so, anyway) to keep gitk --all open as you do merges, rebases, pushes, fetches, etc., refreshing the display after each operation - it makes it very clear what's actually happening. I found git a bit of a mystery until I realised I could see what it was doing this way, and suddenly everything became clear.
Or maybe that's just me. I don't claim to be the sharpest tool in the box.
But anyway, you need have no fear that people won't get forced into using the command line eventually, just because they like git gui. Any time you want to do anything remotely complicated, you need to drop out of git gui and hit the command line. gitk, for all its ability to display the history in a useful format, is similarly limited (or designed for a specific purpose, if you prefer).
I really didn't get on with GitX, but I don't remember it being a great deal more than git gui and gitk, in the same app, with a fancy OS X-looking interface. So the same would probably apply.
In general I agree. In the case of git, I disagree. The git CLI is downright terrible and dangerous to use unless you're already a git pro, I would never ever force a git newbie to stick with the CLI instead of using a GUI like SourceTree (which is fantastic).
I've used CVS, Subversion and Mercurial in the past and never needed or wanted a GUI, but with git, I don't even want to be bothered by all the inane commands and switches. I love git for all it does, but I despise the CLI because it simply is downright evil: inconsistent, incoherent, convoluted, allows you to shoot yourself in the foot in too many ways, terrible user messages, and so on.
The git CLI is downright terrible and dangerous to use unless you're already a git pro,
The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force.
>> The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force.
Sure, but that's not really an excuse for git to have such a confusing and possibly destructive command line. I'm not a GUI person at all, but the times I had to lookup 20 different ways that 'git reset' worked, or had to google what on earth the apparently random combination of words like refspec, remote, origin, branch and non-bare actually meaned have been enough to drive me to a GUI tool. Now I'm much happier and actually enjoy working with git. Obviously when you are only pulling and pushing from master, there's not much that can go wrong, but if that's all you do, Subversion would do the trick just as well. The CLI usability completely falls apart when you start rebasing, merging and cleaning up WIP commits.
A tool like Mercurial proves that DVCS systems do not have to have a confusing CLI, in all the years I've been using it, I've never felt compelled to use a GUI. Too bad the Mercurial back-end is so slow.
3 comments up I predicted 'reset' would make an appearance. What is the point of having multiple command names if the command name says nothing about its behavior, and the command flags trigger completely diverse functionalities? Just have the CLI be git -a to git -zz and stop teasing users.
Not necessarily: the Unix CLI has more powerful ways to saw off your leg, but it won't saw off your leg by accident, it won't destroy your files because you passed a strange flag to `ls`.
Mostly in agreement, I never said one shouldn't learn the git CLI and the fundamental concepts - I did that myself. But once you've mastered that, you're ready to move on to something that speeds up your day to day work.
Needing to use git now and then while SSH'd in is not a good reason to make your entire development process slower and more error-prone. I would also say that there is a larger problem with your process if you have the need to use git on "a remote server in a pinch".
It's kind of like learning to play a musical instrument. You absolutely must pay attention to the fundamentals as a beginner, but if you only ever work on the fundamentals you will never become a great musician.
this is one of the cases where the gui [i like git-cola personally] is definitely a better way to do things. if you complain that it won't work "in a pinch", you're optimising for the uncommon case. yes, it's useful to know how to do it from the command line, but for day-to-day use i find the gui more efficient.
Sorry, it wasn't my intention to be misleading. I'll give it more thought next time. I see how "changes" could be deemed with a negative connotation in that context.
Turns out the problem was an issue between APC and WP Super Cache. After WPSC tried to run garbage collection on cache files (a cron, configured in the plugin's settings), the server would end up then returning a 500 error. I'm still not entirely sure why, but I disabled APC for now and things are running as they should.
"Facebook and Twitter seem to addict people to a stream of trivialities that wouldn't be worth turning over for in isolation."
I wonder how modern 24/7 news organizations have affected people in this regard. Some people are addicted to news: people want to be the first to know something, to give themselves a sense of elitism or pride in letting their friends in on the news, or feel "informed" during casual discussion.
But social media has what national news media often doesn't: personal attachment. National news media will churn out "news" no matter what. There will always be stories to report on--it's just a matter of how many people they affect. Social media "news" caries the same weight. Some news, like that I just ate a really yummy lunch, far outweigh the announcing of a new job, or announcing a death.
The personality of your Facebook or Twitter newsfeed is just that: personal. It's tailored to people YOU (say you) care about. Therein lies the addictive nature.
I'd really just like to know why your framework reinvents the wheel for nearly every aspect of the application stack? Looking at the code even thus far, I don't see how Paraglide or Paragon improves on any aspect already offered by the largest frameworks Zend Framework, Symfony and Lithium, which already have documentation, encourage new contributions and follow best practices within their respective paradigms.
Why not contribute to an existing framework? Your efforts will be better received and more widely appreciated.
The absolute last thing the PHP community needs is another framework.
If this were a brand new framework, then maybe it would be a waste of my time, unless I had more compelling reasons. However, I started building my framework a few years ago and have just been making incremental updates here and there. Friends and coworkers have started to use it over time, and people like it. I've been told to publicize it over the last 3-6 months, but haven't gotten around to it.
My framework is minimalist and gets the job done. I'm a big fan of minimalism and I don't like that some modern frameworks are bloated and have something like hundreds of thousands of lines of code, as opposed to just a few thousand, and that includes components outside the core, like helpers.
Paragon has more work in it than Paraglide. Paragon can support multiple different backends with the same code, just different drivers. I know this exists in other PHP ORM frameworks now, but not a few years ago (not saying mine was the first, it just wasn't as widespread). Also, Paragon integrates cleanly with Memcache so the developer doesn't have to deal with cache and uncache logic.
Sure, you could do the same thing with other frameworks, but most of the other frameworks are full of bloat and not particularly fast. I think it's better to have a few components that do one thing really well rather than a monolithic framework that tries to handle every aspect.
I don't think the lack of optical or hard disk storage started the hole in history. Rather, perhaps IBM did when it invented the hard drive in the 1950s. Or maybe it was as early as Edison's phonograph in the 1870s. Whenever artifacts started requiring technology to interpret them (external dependencies, if you will) is when this hole in human history really began.
Perhaps future generations will see the digital revolution as a time of strictly furthering the bottom-line; a time when it became prohibitively expensive to print most data. Yet currently, we call this "being green."
How will future generations perceive this period in history?
I obviously didn't just learn about patch mode... git has many powerful features, but I feel this is the most powerful of those that many git users don't know about yet that will make the biggest positive impact in their daily git use. Not that patch mode is the most powerful feature git has.