You sure you aren't just overloading the crappy router's buffer with too many open TCP connections? I've seen that problem with a lot of routers and lowering the limit solves the issue.

Have you been to downtown LA recently with the multi-million dollar condos and lifts?

But before you die, do you care that I am going to kill you?

Hence why it's a stupid argument to try to use for astroid-based extinction.

What a stupid argument. If I kill you tomorrow you won't care because you're dead. So why worry about if I'm out to kill you?

The fridge that came with my condo died last year, my guess based on the design and model number is that it was built sometime around Y2K and was relatively high-end at the time. It even was energy star rated.

My new fridge is bigger and was definitely not the most efficient model on the showroom floor. My electricity bill averages has been at least $30 less each month compared to the previous year. I thought it a fluke the first month because we had been traveling, but it has repeated over and over.

At this rate, the electricity savings alone will pay off the new fridge in 6 years.

Yep - I brought one like that to college. It was my great-grandparents' and the manufacturing stamp made it 7 years older than I was. It didn't even say "microwave" - it was labeled as a "radar range".

Sadly, digital ones I've had to buy since it died have lasted 3-4 years tops.

Why would you assume that from a reference to typewriters?

I use command-line tools almost hourly.

Funny, the 1928 Underwood that I'm staring at has little pins that you move to wherever you want the tab stops to be, just like margins are fully configurable.

If you avoid spaces and use only tabs, OTOH, the code formatting will look correct on any editor with any tab setting.

The nominal expansion of tabs is to advance to the next column which is a multiple of 8.

Huh? Since when? On typwriters and early word-processors it was forced to 5 columns. And even most typewriters allowed you to move the tabstops to arbitrary places.

On every editor I've seen in the last 5 years the tab display width is configurable. If you like 2 spaces, great, if you like 8, have at it. It doesn't affect the rest of your team.

The only reason tab characters are a problem is because people mix and match tabs and spaces.

Python's whitespacing is an evil that should be purged with fire.

Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?

Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.

Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.

There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?

How do branches make it more difficult? You're intentionally conflating two different use cases. You want to do all your work in master and periodically push to a central server? Fine. I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed. I want to keep them in a branch so the work doesn't slip into a release. When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.

Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.

In Git you don't have to have one or the other scenario. You can have both at the same time. Branching off of a release branch and merging later back into that branch is just as simple as branching off of master. Merging and Pull requests allows for flow management on teams that may have owners of various pieces who need to review anything being committed against their branch/module/whatever.

No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.

I never said that Git is the Right Answer For Everybody - thanks for putting words in my mouth. If your preferred workflow doesn't map to the Git model, then don't use Git. Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.

The way SVN tracks individual file parent/child version relationships across branches (as opposed to Git's compressed delta of the whole project state) easily results in corrupt histories and merge conflicts that aren't really in conflict. It also quickly becomes overly complicated if you want a project structure that doesn't follow the "best practice" of trunk/tag/branches folders where the entire project is branched. (note, that's a community consensus to work around SVN's limitations, not something enforced by SVN itself). In SVN, branching from a branch, or from a tag, instead of branching from trunk, can get you into to the bowels of SVN cleanup and merge conflicts very quickly.

Granted, a nice aspect of SVN is you can have a single file exist at a different revision than the rest of your project - powerful, but very dangerous if you miss that a file is in that state.

Without branching, you can only have branch-like behavior by having multiple checkouts. And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.

When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other, and merging provides a place for reviewing and synchronizing changes across different efforts.

Event CVS and SVN have branching because it is useful. Stop being intentionally obtuse.

You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.

In Git, every time you check out a new copy you are getting the ENTIRE project history, not just the specific commit. That's part of the nature of a DVCS.

Hence why branching is built to be so easy, and why switching branches is effectively just essentially just changing a symlink.

If you want to be doing dev in another instance thing while a build is running, that's a good argument for a second checkout. But multiple checkouts just to avoid branching is not a good way to use Git, not a good argument against it.

Different VCS architectures result in different workflow styles. What made sense for SVN and CVS doesn't necessarily apply for Git or Mercurial. In SVN/CVS, branching and merging are monolithic tasks that are very cumbersome, so the best-practices workflows tend to minimize how often this happens. Git and Mercurial are the opposite. Because branching and merging is key to making DVCS work, it's highly encouraged and the process is almost trivial by comparison.

And use as many dev branches as you want in Git.

I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.

Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be. Because it is a DVCS, Git it built entirely around the idea of frequent branching. Every time you make a commit you are effectively branching.