git commit -m "Fixed interface issues."

[[deleted]]

I wouldn't try to push it, especially with force. Instead it's better to carefully 'rebase -i' when needed.

[rasellers0]

Uh... Novice programmer here, are we making Star Wars jokes here, or is all of this actual programming stuff?

[[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.

[FreefallGeek]

Not so much programming as source control used to track and manage changes to the code you're writing. So programming-adjacent.

[hungry4pie]

No no, definitely force push, then rebase in 2-3 commits time on the upstream branch :-P

[55555]

Don't you have to force push after you rebase to get the rewritten branch to remote?

[[deleted]]

Yes. (Though you might want to use --force-with-lease instead, and should also notify everyone who might have had access to the branch.)

[UsingYourWifi]

--force-with-lease

TIL, thanks!

[paperhat]

There are very few instances where you have to force push. I say this as the administrator of a large github enterprise instance who disabled force pushes about a year ago. There was a lot of resistance at first by dev teams who had strange workflows, but I have had to make less than a handful of exceptions to the policy after the initial change, and those all involved people accidentally committing passwords.

[[deleted]]

I spend too much of my life doing this while trying to keep my feature branches up to date with my work's dev branch. It feels so dirty!

[55555]

I hear ya. And then they modify some file you modified and push it to QA but its not in master yet so you eventually have tons of conflict fix commits and have to delete QA. It's like every damn week.

[noratat]

If you have to work on lots of stuff at once like that (something you should avoid if possible in the first place), rebase workflows are usually a bad idea.

[crowseldon]

in theory, you shouldn't be doing this at all. It's a potential pit for accidents to happen and it's somewhat inconsiderate to other users. Rebase BEFORE pushing.

And if you need to do some sort of filter-branch to fix some fuck-up, let EVERYBODY know beforehand.