Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.

But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.

So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.

If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.

Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.

So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?

Others may have different experiences, especially if they work on large teams.

The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.

Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it.

Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).

Some authors probably have tons of concurrent drafts of a novel they're writing. But I'll bet most have a single draft.

I'm afraid (to a fault), I am primarily a lone developer so this is the angle I come at these things from...

Change any of that, and you need a better technique.

There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like.

Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.

On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to.

> So enough with the "This is better than this" mentality

I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).

SVN's locking ain't so amazing, it must be said, because it's clearly not the way it's intended to work. But it's better than nothing, certainly, and TortoiseSVN on Windows has some nice features that make it work fairly well.

Another issue is the filling of your hard drive with crap - obviously git keeps the entire repository locally, and SVN keeps a previous revision (I think?), which is a bit useless for enormous hundreds-of-gigabytes repositories mostly filled with stuff that's not significantly further compressible. To add insult to injury, git then spits in your face by not letting you retrieve only part of the repository! - well, obviously the problem is that git just isn't designed for this kind of thing, not that its decisions are unreasonable. Shame, though... some kind of binaries-and-locking support would be nice. It would be great to be able to use git for everything.

You can create a git repository that has other git repositories in it (submodules) but you can't checkout an arbitrary subtree of a git repository. I spent a long amount of time searching for this, so I know.

Now, people have written scripts that will convert a directory to a git submodule by moving history around and stuff like that, but you need to check out the whole repository first.

That makes absolutely no sense whatsoever, unless it is a troll. Nothing can be "good enough" simply by virtue of not being something else.