|
I can't speak to CVS, but having gone from svn to git, the way branching works alone is benefit enough to switch. I didn't find it hard at all to grok.
|
#
?
Apr 14, 2017 19:17
|
|
|
|
| # ? May 9, 2024 23:13 |
|
|
Clanpot Shake posted:I can't speak to CVS, but having gone from svn to git, the way branching works alone is benefit enough to switch. I didn't find it hard at all to grok. What exactly (from a user's perspective) did you hate about svn branching vs git? I used svn until 2003 or so, then moved to perforce (since the company i moved to used perforce) and only using git since 2008. I honestly forgot what was so bad about svn branching (i do remember not having that many branches before though).
|
|
#
?
Apr 14, 2017 21:21
|
|
|
SVN could get confused, and require you to go in and manually fix things up. I haven't had to touch svn in about 4 years though, so I don't know if that's still true.
|
|
#
?
Apr 14, 2017 21:47
|
|
|
When you're merging code into trunk or another branch that includes commits already made to that branch, svn sometimes can't handle that. I know I've had to literally do a merge that included only commit 1-4 and 6-8 of a branch. Because commit 5 is a merge of trunk which I already had in my branch, and svn wants to replay those changes again which causes a tree conflict. Sometimes it was easier to make a patch file and apply it to the other branch rather than do a merge.
|
|
#
?
Apr 14, 2017 21:47
|
|
|
Rubellavator posted:When you're merging code into trunk or another branch that includes commits already made to that branch, svn sometimes can't handle that. I know I've had to literally do a merge that included only commit 1-4 and 6-8 of a branch. Because commit 5 is a merge of trunk which I already had in my branch, and svn wants to replay those changes again which causes a tree conflict. Svn is so terrible.
|
|
#
?
Apr 14, 2017 21:55
|
|
|
Why is SVN so bad at merging? Gift holds everything as snapshots, and it does so well. I don't get why SVN never worked as well.
|
|
#
?
Apr 14, 2017 22:58
|
|
|
lifg posted:Why is SVN so bad at merging? Nobody really put much thought into this stuff till LT sat down and was like "this is crap" and wrote Git. Svn was great.... for its time. Now it's practically anachronistic.
|
|
#
?
Apr 14, 2017 23:22
|
|
|
Svn required a certain process to be followed and bit you in the rear end if you didn't. The anecdotes above confirm that. From personal experience, Git requires a process to be followed as well, if you want to be happy and not have headaches. Sure, it handles certain things better than Svn but is not without its faults. You can confuse Git without too much trouble too. The idea is that if your organization is following the svn process and the tool itself doesn't get in the way of developers, nightly build, etc. there really shouldn't be any reason to move to git. The worst thing is to change for the sake of change.
|
|
#
?
Apr 14, 2017 23:52
|
|
|
Volguus posted:Svn required a certain process to be followed and bit you in the rear end if you didn't. The anecdotes above confirm that. Oh I love Git, but it's definitely more of a toolset that you build a version control solution with. A toolset than includes hammers, screwdrivers, and couple chainsaws. It requires a well defined process and good training more than any other version control I've used.
|
|
#
?
Apr 15, 2017 01:12
|
|
|
lifg posted:Oh I love Git, but it's definitely more of a toolset that you build a version control solution with. A toolset than includes hammers, screwdrivers, and couple chainsaws. It requires a well defined process and good training more than any other version control I've used. Only if you have devs with aspergers on your team. Otherwise it's dead simple.
|
|
#
?
Apr 15, 2017 01:15
|
|
|
lifg posted:Oh I love Git, but it's definitely more of a toolset that you build a version control solution with. A toolset than includes hammers, screwdrivers, and couple chainsaws. It requires a well defined process and good training more than any other version control I've used. I find git much easy to deal with in everyday development. It is also usually easier for me to fix when a developer on my team does a force commit wiping out everyone's work for the last 4 months. I also have to deal with svn at work. I've ran into so many headaches trying to merge things together over time. The worst case is when several developers create branches whole cloth without using the copy command. Bonus if they have merged these together several times. Trying to merge that back into trunk or a release branch ends up taking me a day or more withblota of praying I got it right.
|
|
#
?
Apr 15, 2017 08:38
|
|
|
the killer feature of git over svn by far is being able to easily merge branches. this allows you to create small self-contained branches for each feature you develop. svn makes it easy to create branches, but it completely misses the point by making it a really loving terrible experience to merge. thus, most people using svn avoid branching and only really use it in a hamfisted way to section off older versions of the software. the svn way of not using branches for features suck, because what ends up happening on most development teams is that you have to work with a bunch of in-progress half-finished bullshit other people are pushing to the central repository that might break your poo poo and then you have to keep tracking down these problems over and over again
|
|
#
?
Apr 15, 2017 12:57
|
|
|
this is a superior way to develop even if you're literally just a 1-man dev team
|
|
#
?
Apr 15, 2017 13:08
|
|
|
HFX posted:I find git much easy to deal with in everyday development. It is also usually easier for me to fix when a developer on my team does a force commit wiping out everyone's work for the last 4 months. Woah, you need to turn protected branches on! Don't EVER let ANYBODY force commit.
|
|
#
?
Apr 15, 2017 13:40
|
|
|
Our problem is that we do a lot of force pushes to our feature branches to get a clean history before merging, which generally doesn't cause any problems. So people sometimes don't realize what a bad idea it is to force push to master. "Oh I'll just fix that typo in the commit message." We really should block it, but I vaguely recall the Stash plugin for that being all branches or none.
|
|
#
?
Apr 15, 2017 13:55
|
|
|
I also work with cleaning history before merging branches, and I did a git push -f origin master while on an unrelated branch a few days ago. Luckily my coworker had a local copy of the repo and he averted the crisis. I then learned about the git push --force-with-lease command which pushes to the current branch only if there has been no work done on it.
|
|
#
?
Apr 15, 2017 14:14
|
|
|
Oh that reminds me... apparently there is a git option (push.default) that makes git push work on the current branch only vs working on all your branches. One of our devs didn't have that set correctly and someone else was pairing with them and did a force push to all branches. Oops.
|
|
#
?
Apr 15, 2017 14:20
|
|
|
What's with all the forcing? I don't think I've ever needed to use that flag, and knowing what it does means you better be drat sure you know what you're forcing before doing it. Stash has an option to squash history when merging PRs if you need a clean way to revert. We have our setup pretty locked down. No pushing to master (with some select exceptions), PRs require 2 approvals and a green build, history squashed to make revert easy.
|
|
#
?
Apr 15, 2017 17:31
|
|
|
Clanpot Shake posted:What's with all the forcing? I don't think I've ever needed to use that flag, and knowing what it does means you better be drat sure you know what you're forcing before doing it. I really like that they added the squash feature to PRs in recent versions. It makes git flow easier to swallow since merging from downstream doesn't necessarily pollute history making it easier to follow.
|
|
#
?
Apr 15, 2017 17:38
|
|
|
Yeah, the only times I've had to force anything, I'd hosed something up badly.
|
|
#
?
Apr 15, 2017 17:39
|
|
|
comedyblissoption posted:the killer feature of git over svn by far is being able to easily merge branches. this allows you to create small self-contained branches for each feature you develop. I think the killer feature of git was not having branches as different directories in your file system. So literally we would have app/trunk, app/branchA, app/branchB, etc.
|
|
#
?
Apr 15, 2017 17:54
|
|
|
HardDiskD posted:I also work with cleaning history before merging branches, and I did a git push -f origin master while on an unrelated branch a few days ago. Luckily my coworker had a local copy of the repo and he averted the crisis. I then learned about the git push --force-with-lease command which pushes to the current branch only if there has been no work done on it. Why not just make another branch and clean that up locally before pushing it....
|
|
#
?
Apr 15, 2017 19:27
|
|
|
If you're in a really low velocity, low quality shop ( < 3 commits / day across 5 engineers with no code review is what I've observed is the line between low before competence and velocity starts increasing towards a hockey stick pattern) with really easily separated, non-overlapping developers svn works fine honestly. Increasingly, code review tools are becoming stagnant in that market which also reflects the kind of companies that are still on svn - usually dinosaurs or where the SCM is completely unrelated to their problems. Really tired of shops (as a consultant) where I'm the first developer to have issued a pull request in years because everyone has committed directly to master and nobody has ever run into merge conflicts despite these practices, so I can't even rationally argue for a lot of git use cases because they're not problems they ever have.
|
|
#
?
Apr 16, 2017 01:46
|
|
|
Clanpot Shake posted:PRs require 2 approvals This ensures that the two reviewers each assume the other reviewer actually looked at the PR
|
|
#
?
Apr 16, 2017 02:43
|
|
|
Progressive JPEG posted:This ensures that the two reviewers each assume the other reviewer actually looked at the PR Current place our lead devs got scolded for being too demanding on PRs for a group of expensive contractors and we were slowing them down. So now we approve everything without looking and can't wait for the regression and meltdowns to occur because their code is absolute garbage they don't even test locally before pushing up.
|
|
#
?
Apr 16, 2017 02:57
|
|
|
geeves posted:I think the killer feature of git was not having branches as different directories in your file system. So literally we would have app/trunk, app/branchA, app/branchB, etc. It is not at all obvious, but apparently you're supposed to use svn switch. Then you only have trunk, branchA, or branchB checked out, and then svn switch when you want to change trees. svn co https://path/to/repo/trunk appname cd appname svn switch https://path/to/repo/branches/branchA
|
|
#
?
Apr 16, 2017 03:59
|
|
|
Progressive JPEG posted:This ensures that the two reviewers each assume the other reviewer actually looked at the PR Fortunately (?) the stakes are high enough in a dollar sense that code gets looked at. Unfortunately we have so many cooks in the kitchen weird poo poo slips through and breaks something anyway, but that usually comes down to author incompetence than the reviewers.
|
|
#
?
Apr 16, 2017 04:11
|
|
|
a foolish pianist posted:Yeah, the only times I've had to force anything, I'd hosed something up badly. They're necessary if you ever do any rebasing. Phobeste posted:Why not just make another branch and clean that up locally before pushing it.... And what, open a new PR? That's way more annoying and confusing than just blowing away a private branch history.
|
|
#
?
Apr 16, 2017 04:53
|
|
|
raminasi posted:And what, open a new PR? That's way more annoying and confusing than just blowing away a private branch history. Why? With github you can make a comment in either PR invoking the name of the other and both of them will get links in the comment stream to the other one; just say "closed in favor of #152" or "supercedes #151" or whatever. Probably other git platforms have the same thing. Force pushing is terrible and branching and PRs are free.
|
|
#
?
Apr 16, 2017 14:07
|
|
|
Phobeste posted:Why? With github you can make a comment in either PR invoking the name of the other and both of them will get links in the comment stream to the other one; just say "closed in favor of #152" or "supercedes #151" or whatever. Probably other git platforms have the same thing. Force pushing is terrible and branching and PRs are free. But the goal is to not have a PR with a million individual commits, and only have the final changes in the PR. "I don't have to know how you got there", were my supervisor's words.
|
|
#
?
Apr 16, 2017 15:12
|
|
|
If the code review interface just shows a squashed view, and it can do a squash merge, then it doesn't seem like it really matters.
|
|
#
?
Apr 16, 2017 15:16
|
|
|
Agreed on the first point, the tools we used had always shown the squashed view. As for automatic squash merging, it is still iffy on GitHub et. al. because they take the first commit message and apply that to the squashed commit. In my case, the first commit is almost always "add tests" or something useless like that, so I take the opportunity to change that message when merging.
|
|
#
?
Apr 16, 2017 15:25
|
|
|
smackfu posted:If the code review interface just shows a squashed view, and it can do a squash merge, then it doesn't seem like it really matters.
|
|
#
?
Apr 17, 2017 01:42
|
|
|
I commit and push pretty often on a feature branch, so my commit log looks likequote:WIP I push the branch so that I can work elsewhere if I want and because sometimes I want a coworker to look at some bug I'm having. Once I'm actually ready, I rebase into quote:unit tests for capital letters in usernames and force-push. GitHub's PR interface makes it really easy to look at those three commits one at a time. Everyone with write-access to the master branch ought to be very careful, but it's not scarier than having root creds to the AWS account or access to the production database, etc. One time the Product team got an intern and she was supposed to give surveys to potential users about which new features the dev team should work on. Her second day, the head of data science runs over to her desk "turn off your computer right now! You're deleting all our regression data!" It turns out his team stored there terabytes of regression data in the company Dropbox. So first off, if you installed the Dropbox client it would immediately fill your laptop hard drive with their poo poo. And second, if you tried to delete those files to reclaim space, Dropbox would sync by deleting those files from everyone's machine. After they got things sorted out, he told her "it's weird! That seems to happen every time someone new joins the company." As far as I know, they have not changed their system.
|
|
#
?
Apr 17, 2017 01:58
|
|
|
Mniot posted:
What? Why? Force-push? In almost 10 years i had to force-push once, only because someone force-pushed and broke everything. Force-push for no reason can do a lot of things, none of which are desirable.
|
|
#
?
Apr 17, 2017 02:50
|
|
|
Volguus posted:What? Why? Force-push? In almost 10 years i had to force-push once, only because someone force-pushed and broke everything. Force-push for no reason can do a lot of things, none of which are desirable. Because the branch is present on the remote repository and I'm rewriting the history on that branch. That's what force-push does. I don't know what your workflow is that you believe is the One True Git Workflow, so I'm not sure how to explain what seems pretty obvious to me. Do you only work off of emailed patches?
|
|
#
?
Apr 17, 2017 03:10
|
|
|
As written, it sounds an awful lot like you are force pushing to the remote Master, not your own branch.
|
|
#
?
Apr 17, 2017 03:31
|
|
|
Yeah, I push to the remote version of my own branch, then make a PR. The above sounds like a nightmare. This thread is making me terrified about how devs understand git. a foolish pianist fucked around with this message at 04:01 on Apr 17, 2017 |
|
#
?
Apr 17, 2017 03:55
|
|
|
Volmarias posted:As written, it sounds an awful lot like you are force pushing to the remote Master, not your own branch. I don't see how you got that, but no, individual devs pushing from a feature branch directly onto master would be a very weird thing to do. I'm saying that I have a feature branch (or at other companies a private fork but same diff) and I want to both store my work-in-progress remotely and have a clean PR. Git's not magically more dangerous than anything else. I remember going from HFS to a Unix machine and being freaked out that if you accidently "rm" a file you can't just recover it back off the disk the next week. But the solution isn't to never delete a file; it's to keep incremental backups and pay attention.
|
|
#
?
Apr 17, 2017 04:44
|
|
|
|
| # ? May 9, 2024 23:13 |
|
|
Everyone who has mentioned force pushing sound like they're doing perfectly normal things. Pushing a rebase of a personal feature branch, doing history cleanups of a branch prior to review, merging fixup! and squash! commits after a code review, etc. There's nothing inherently wrong about pushing a history edit to the remote, as long as you do it to a branch that has no other active downstream clients. You don't have to do any of that of course, but it's not some kind of esoteric dangerous practice done only by those who don't know how git works. Force pushing is pretty common in many workflows that prefer rebase over merge, or encourage cleaning up WIP commits, since it leaves a lot less junk to clean up than creating new branches all the time. You're not going to magically blow up the repo just by typing --force. Sidenote: the worst git SNAFU I've seen was a dev who was new to git and used git merge to "swap" branches locally, and then regular-pushed the resulting frankenmerge to origin. It's the one time I've de-protected and force-pushed a history edit to master, because pretending that never happened and making some people deal with the hard resets was probably the lesser evil.
|
|
#
?
Apr 17, 2017 04:45
|
|
