xivSolutions

Regex can be painful in cases which go beyond the low-lying, easy ones. Also, people have different innate skills. I am one who does not do so well remembering esoteric character combinations. I use regex frequently enough to understand how it works, and what I need, but without fail, I lack the "muscle memory" to just know what to type when doing much more complex than a simple match. This usually leads me to Google, or to a tool like this.

I have similar trouble with odd terminal commands and flags. I am not afraid of them, but it simply not part of my mental make-up to remember them all. The ones I use frequently - no problem. Those I use only occasionally - Google. :-)

Let's face it - regex IS HARD if you are not a regex "power user" or if you are the sort, like myself, whose mental map is not optimized for such things.

A day or two before he posted the list, he had to go through a run-around with some dude who apparently had copied a whole bunch of his (10 years+) blog content to their own, no attribution, nothing. I believe he deals with this type of thing frequently. I also think this tools list is a popular item for such "re-blogging,"

In this particular case, it appeared the offender simply didn't understand proper "nettiquette" and once pointed out, promptly removed the content (although he appears to still have a whole bunch of OTHER people's stuff copied up there, so who knows?).

So, kindly watch the way you throw the word "you" around. I did not write the article, I just wanted to see what the community might have to say about it. I am coming to understand MVC decently well.

That said, your points are good, and I agree, based on what I have learned myself to this point.

:-)

Cool project, man. And, way to show class in handling the "detractors" here. I firmly believe that constructive debate is a good thing.

Totally agree about 50% of the joy coming from learning to use git. Frustrating at times, but in the end, that's the kind of thing that keeps me learning to code!

If I understand correctly, the subtree workflow is a (relatively) newer thing, and there is an actual subtree command either newly added or soon-to-be added which simplifies things a little further.

I decided to learn the old, hard way before I started exploring the subtree command itself (prior to the addition of the command, my understanding is that "subtree" represented a merge strategy, from which evolved the subtree "workflow" and out of which a git contributor evolved a "command," which appears to have been added to git 1.7.11:

http://log.pardus.de/2012/08/modular-git-with-git-subtree.ht...

I will likely follow up at some point with a post on using the actual subtree command as well.

I won't say any of this is hot, new information. This is my attempt to document the use of the subtree merge strategy/workflow in a way that would have helped me in figuring it out. While most of the information was out there, my best understanding came from working through multiple sources. If anyone sees where I have something wrong, I would love to know so I can correct it. I do NOT want to be propagating bad information. There is a real basic walk through for folks who are not deeply experienced with Git, and also a link to more of a reference for those who are more fluent and need less of the narrative/screenshots. As always, feedback is appreciated.