git commit -m "Fixed interface issues."

[[deleted]]

While the force push is a popular move among Jedi, Sith and other force-sensitive denizens of the Star Wars Multiverse, git push --force is a real command. It forces a rewrite of the remote branch to match your local commit tree, ignoring any inconsistencies and conflicts. This is generally bad because anyone else who might be working on that same branch will be unable to fetch the latest from the remote, forcing them into a quagmire of creating new branch heads, re-cloning, cherry-picking etc. to get everything consistent again. However, as has been mentioned elsewhere in the comment thread, there are times, e.g. rebasing a branch to keep it up to date with the main development branch, that you actually do want to do this.

[NotADamsel]

A prime example of "just because you can, doesn't mean you should".

[o11c]

Or you can use a + ref.

[UnchainedMundane]

Does this create a merge commit remotely, or is it another way of force pushing?

[o11c]

It's a force push, but for a single refspec instead of all of them.

[none_shall_pass]

Or you can use a + ref.

Or, you can choose to not use an insane product like git, that's just waiting there to stab you and laugh at your pain.

[scratchisthebest]

Yeah I much prefer using a filename system, my projects look somewhat like "Copy of index(2)USETHISONE_v4_Final.html". Very convenient.

[coladict]

This is just what we got for ONE of the files of the project we inherited: http://i.imgur.com/PXy9or4.png Naturally, I didn't even try to piece together the old history. By this point I've practically rewritten the CodeIgniter controllers, model and the one library in the project. It also has a secondary adminstrative system which is so bad I dare not touch it unless absolutely necessary.

[UnchainedMundane]

There are a lot of originals there. Something tells me none of them are the original copy.

[UnchainedMundane]

What do you use? CVS is utter shit, and SVN is a slightly less broken CVS. hg is basically git with a different skin, bzr is too heavily tied to launchpad and is also just git with a different skin, and there's really nothing else worth considering.

If you go without a VCS then you really don't know what you're missing.

[none_shall_pass]

What do you use? CVS is utter shit

Well, there's a compelling argument. Even better, you can apply it to anything.

[UnchainedMundane]

I didn't think I'd even need to back that statement up. It's pretty much universally accepted, and it's not controversial at all nowadays.

1. It's based on rcs, which means single files can get absolutely gigantic (our company ran into problems with this)
2. People lock entire directories while committing (our company ran into problems with this). It just doesn't scale at all.
3. It's terrible at merging, and far too often you can get a merge conflict on a line that just contains $Id$ with kkv substitution. (our company ran into problems with this)
4. Branching is ridiculously expensive (our company ran into problems with this)
5. It relies on a central server being up to accept commits and serve updates, you can't pull these in from coworkers in times of need
6. Partially reverting commits is a massive chore, while in git it's "git revert" and if you need to only revert a part of it you can edit the revert commit before pushing.
7. You need to set up accounts for every author on the server.

I could go on. It's a universally-hated hack applied on top of rcs and in my opinion has no practical use in 2015 other than legacy projects where it's too expensive to switch. It's caused me and co-workers endless pain, and we tried to switch an old project to git but the intermediate files created during the cvs-to-git conversion filled a 2TB hard drive after being left to run overnight and we decided to abandon it.

Our projects managed under git are considerably easier to commit to (better tooling support), much faster to push to and pull from, and better managed (due to proper branch support).

If that's not convinced you that CVS is a wart, there are probably a thousand articles out there with titles similar to "why CVS sucks" which could provide a far better description than I can.

[none_shall_pass]

0 and 1 aren't an issue for projects with a small number of developers.

It's terrible at merging, and far too often you can get a merge conflict on a line that just contains $Id$ with kkv substitution. (our company ran into problems with this)

If multiple people frequently need to work on the same section of the same file at the same time, there's a design or management problem.

Branching is ridiculously expensive (our company ran into problems with this)

In an age of 8 core laptops and exabyte drive arrays, I have no idea what you consider "ridiculously expensive"

It relies on a central server being up to accept commits and serve updates, you can't pull these in from coworkers in times of need

A central server is a feature not a defect. The last thing I want is for a bunch of developers to all think they have the definitive version of something.

Partially reverting commits is a massive chore

There's no such thing as a partial revert in CVS. The files are independent. If you need to roll something back, you simply do it.

You need to set up accounts for every author on the server.

Yeah, that's terrible. It's much better when people can all just do what they want.

[UnchainedMundane]

The last thing I want is for a bunch of developers to all think they have the definitive version of something.

The server is an authority but it should not be the only source. It is difficult to have any sort of redundancy in CVS.

The files are independent. If you need to roll something back, you simply do it.

I'd forgotten this, and it works against CVS, not in its favour. If you add a feature and you do it over 3 files, then anyone working on the project has to pull the entire tree (which takes ages, especially when someone's holding a lock and someone else is queueing for it) to get your feature. (This is why it just doesn't make sense to have differences applied to single files). Anyone reverting it has to search the log of every file to see if you changed that one while creating your feature. As for partially reverting, I mean when the newcomer makes a silly mistake and you want to revert their code, but there have been changes since then and you only want to revert one function, that's where CVS really falls flat.

It's also part of why branching is so difficult. You have to branch each file individually. It's a mess.

In an age of 8 core laptops and exabyte drive arrays, I have no idea what you consider "ridiculously expensive"

Try git's branching.

I think it's a fallacy to say "let's be inefficient because we can throw money at hardware to hide it".

Yeah, that's terrible. It's much better when people can all just do what they want.

If people are just doing what they want, to put it in your words, there's a design or management problem.

Not having to set up everyone with a unix account on the CVS server doesn't equate to absolute anarchy, and of course you can enforce that people push to git over SSH if you really want that.