How frequently do you git commit? Big changes or small changes?

SVN
It's a non autistic version control system. It just werks.

I'd rather not use something as old and archaic as svn.

Attached: disgusting.jpg (408x510, 59K)

>I'm retarded and can't use git

Attached: (you).gif (405x228, 498K)

>old and archaic
What's the difference?
Can you name three reasons why SVN is bad?

Stop trying to keep something alive that is already dead. Just use git.

git is for niggers who need to commit every 5 minutes

The users speak louder than words. I've never met anyone who uses svn over git.

Oh I'm sorry for keeping a comprehensive history of my work for easy debugging and explaining my school of thought to other developers.

small brained nigger

Pretty much every 20/30 minutes of work.

It's a weird mix of having enough for it to be worth committing and wanting to keep those green squares up so I look like a tryhard

Attached: green_blocks_very_epic.jpg (273x83, 17K)

>absolutely no argument beside hurr old!1!!
Absolute state of gitcucks

Attached: p3zEtxM.png (500x533, 66K)

At least once a day. Always before making big changes.

This is my first time posting in this thread. I have an honest question. Lets say you are using SVN and you checkout some source code and make some changes. Now you go to submit your changes back to the central repository that everyone pulls from. However, in the meantime, someone else has already submitted changes to that respository and now your changes are based on an outdated version of the source. How would you bring your code up to date with the more recent changes made by other people?

You pull changes and resolve conflicts (if any)?
Same as git.

>You pull changes and resolve conflicts (if any)?
How? Does SVN have features built in for this? Using git I would just do a git rebase and then push

Yeah it does. What did you think SVN was?
It's a normal version control system although not decentralized. It's actually pretty good for small teams which do not work remotely.

Well, the way you described it, you would handle it differently (less elegantly, in my opinion). Imagine a node tree for a second. It starts on A. From A, someone else creates B and you create C. B and C are not connected to each other, only to A. Then B and C converge into D when you are done. That is my understanding of what you described when you said "pull changes and resolve conflicts". With a git rebase, it functions slightly differently. If we start from A, someone else creates B, I create C (both from A), then I rebase, it restructures the node tree. Instead of having B and C converge into D, it instead rewinds my work back to the most recent common commit between the branches (A, in this case) and then plays the new commits on top of that (giving me B), and then plays my changes on top of that. So then you have A->B->C when you are all done instead of A->B->D/A->C->D. It makes your node tree cleaner, and it only takes a single command.

>less elegantly, in my opinion
Stopped reading there. Gitcucks confirmed for autists.

Someone should man git

See

>t. I love pretending I'm spiderman when browsing my repo history

sethrobertson.github.io/GitBestPractices/

small changes to keep my work, rebase before merge for clean history. i hate clusterfuck git log history

Attached: 1497313400387.jpg (753x707, 29K)

Honestly I want to git commit suicide pretty much everyday.

Every change, makes commit messages short and sweet, and makes reverting changes much easier

atomic commits, squash when merging

kek here's this gem from my gitconfig
>ff = only

l2squash or work on some real projects

SVN is fine for personal use or for a small project with a few people of equal skill. In a large project with a dozen or more developers or if you have to manage commits from interns/people who's code needs to be deep reviewed then git is better.

I spam the fuck out of commit and push so my github timeline looks green as fuck desu, I can't be the only one.

Before committing you'd do an Update (effectively the same as Pull in git). It would autonmerge everything it could and ask you to resolve any conflicts, just like Git.

I try to do a commit every time I change a function, but I end up not doing it

Once per pull request, git workflow slows me down significantly. I don't want to spend a second out of the flow thinking if this chunk should be committed or not. I also never had to revert changes smaller than the whole pull request, and everything gets squashed into master. I don't really get the people who commit every 5 minutes, I literally don't care about your commit beauty, only resulting code matters.

I've been brainwashed to make commits as small and atomic as possible. If you can't help your autism and change whitespace or variable names then make a separate whitespace commit or renaming commit.

old = literally old
archaic could just mean it uses old concepts or components

t. 99th percentile english student

>never merge unless...
This is a horrible mentality. You should start with "never rebase unless..." and then come up with the exceptions from there, not the other way around.

I honestly don't know why anyone would prefer using SVN after using Git- unless you are a brainlet who doesn't understand the obvious benefits of a decentralized VCS. Git is to DVD as SVN is to VHS. One is clearly the better technology.

Stupid retard here. I just started learning, and for some reason -m isn't working for me for git commit. Am I missing something? Pls no bully.

Nvm, found my issue.

>on a personal project
only before trying something risky
>on a work project
only once per major feature (I don't want the client to see my commit times/work patterns)
>on a FOSS project
By the book because I respect the time of other contributors

(Me)
>only once per major feature
Should clarify that I may well commit more frequently than that but I definitely make sure to squish it all down before I push

Learn about fixup commits and rebase-squashing and you'll learn to make atomic commits naturally

This. If the Levenshtein distance between commits is greater than 1, you're doing it wrong.

If I can't describe the commit in one sentence, it's too big. If sequential commits in a row can be described with the same sentence, they should have been 1 commit.

I always push to master because I'm one person so who gives a fuck

my employer uses SVN

a few times a day, when the project builds without errors, runs as I expect it to, and there are meaningful changes worth putting out there.

always. you can rebase later if you have autism anyhow.

when I'm going to take a shit so I can pull it to my laptop and work in the toilet

it took them til fucking 1.10 to even make merging add/remove/move changes so they don't conflict

My workflow is just to make a topical branch, commit whenever I have a build that works & has been through a debugger or test suite at least once. I tend to commit in fairly large chunks, I don't like to think about revision control while I'm in the middle of coding.

I'll commit broken builds to branches if I'm in the middle of a major change or refactor. (The only time I ever commit a broken build to a release branch is if there's some bootstrapping step that needs to be changed.)

>Can you name three reasons why SVN is bad?
easy af

no fucking branching
no easy way to revise history
constantly changing repo format
some features are limited to how new the svn server is
svn mirroring large repos can be prohibitively slow and near impossible to sync multi-directionally.
"sparse" checkouts require manual effort unless you happen to be in your trunk and don't have any hierarchy where you wanna sparse checkout.
changelists don't work on directories, hell any action on new directories is fucked in general.
fun errors on build systems when commits with a lot of file moves and deletes create manual merge conflict work.

Only if it compiles without error or (problematic) warnings. So it depends on how long it take to get the change working, not the size of the change.

>Pretty much every 20/30 minutes of work.
That's dumb. That means you can have a single feature change split into multiple commits which do not stand by themselves.

I don't even know what you are implying. Are you trying to tell me you don't understand how to use squash?

Yea, if I made some change, committed it locally, then later made some small improvement, I will amend it.

Well obviously you don't commit for no reason just because you hit a certain amount of time, but you can always squash them into one commit and then rename it to something else, besides they'd probably be in a branch and that entire branch would be merged so no matter what happens you end up with one big commit to master after a feature is finished

my rule of thumb is that i only commit if i'm changing no more than a single subsystem in my project

One per buildable change. That way I can easily push single commits onto a different branch if I want to move over just one component or change.

That teenage boomer that is still using git

Attached: pikachu_laughing_6363.gif (198x198, 15K)

commit any compiling change I'm sure enough I will not have to revert
push any task done, or more often if it's code others need to work on

amend is only to hide unwanted changes in "automatic" merges

an employee of mine just pushed a commit that modifies files in three different packages, adds the compiled bytecode that his IDE makes, and includes large sections of commented-out code.

the commit message was "latest changes"

i think i'll be letting him go on Monday

No, that's what rebasing is for

Ask Linux what he thinks about SVN.

I use RCS. I don't understand why you newfags have to overcomplicate things.