3 ms·

It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other posi

by zmmmmm 10y ago

It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems, so we never needed these elaborate workflows. Now suddenly Git is considered a defacto tool, and downstream effects of using it are transforming the entire software development process.

dpc_pw 10y ago
"Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems" Are you kidding? :) CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE PITA. People used to lock files, so noone else could change them when they were working with them. Merging different feature branches was like locking whole repository with huge lock, so noone else could touch anything at the time. Any time I had to work with legacy revisioning systems I wanted to kill myself. Git workflows are conventions to help improve small issues with staff that wasn't even possible befor (before Distributed VCS). And a lot of these problems are superficial ("oh those merge commit are annoying in `git log`"). It reminds me: https://www.youtube.com/watch?v=ZFsOUbZ0Lr0 https://www.youtube.com/watch?v=ZFsOUbZ0Lr0
- jimbobimbo 10y ago
  In Subversion you'd need to explicitly lock the file, it doesn't require it. Merge the is also not as bad as you're describing. I actually had more headaches with merges in Git than in Subversion.
nlawalker 10y ago
>> Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems They generally don't exist with Git, either, if you limit yourself to the same set of features and capabilities that other revision control systems have. Take Microsoft Team Foundation version control for example. All of the "problems" with Git disappear if you use a workflow that gives you the same features as TFVC and have the same expectations (especially around history): collaborate around a single shared repo instance, push every commit when it's made, and allow fast-forward merges only. Conflict? Rebase locally. Personally, I think a good idea for a Git tutorial would be to recreate the workflow of another version control product into Git in order to introduce some of the new ideas in a familiar war.
BWStearns 10y ago
> these problems simply didn't exist or were not nearly as severe with previous revision control systems I (have to) use one of these systems you speak of without the horrors of having to worry about merge histories or organizing any branches whatsoever. I have to worry that someone in California broke some code, somewhere right before lunch and it'll take me as long to workaround as it will to just take a second lunch. I have to worry that if I miss a release because of QA issues I need to spend a bunch of time reversing all my changes temporarily and then redoing them in a new release and hoping nothing got borked in between. I have to worry about how to show someone out of the office what my changes look like because they're still too janky to push into the release branch. If I'm working from home and Comcast decides I'm due for my weekly outage then I'm SOL. I have to worry about a failed commit going and locking files on other people because apparently I'm the only person ever to run a command that fails (granted, PEBCAK), so let's not worry about making that failure impact a centralized shared state in a negative way. You can spend a lot of time thinking about the best way to do something in git because it lets you do a lot. The choice is essentially "Elaborate workflows" vs "bridge the inadequacies of the tooling by brittle ritualized human processes". Git problems are VCS' first-world problems.

by zmmmmm 10y ago

dpc_pw 10y ago

"Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems" Are you kidding? :) CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE PITA. People used to lock files, so noone else could change them when they were working with them. Merging different feature branches was like locking whole repository with huge lock, so noone else could touch anything at the time. Any time I had to work with legacy revisioning systems I wanted to kill myself. Git workflows are conventions to help improve small issues with staff that wasn't even possible befor (before Distributed VCS). And a lot of these problems are superficial ("oh those merge commit are annoying in `git log`"). It reminds me: https://www.youtube.com/watch?v=ZFsOUbZ0Lr0 https://www.youtube.com/watch?v=ZFsOUbZ0Lr0

jimbobimbo 10y ago
In Subversion you'd need to explicitly lock the file, it doesn't require it. Merge the is also not as bad as you're describing. I actually had more headaches with merges in Git than in Subversion.

nlawalker 10y ago

>> Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems They generally don't exist with Git, either, if you limit yourself to the same set of features and capabilities that other revision control systems have. Take Microsoft Team Foundation version control for example. All of the "problems" with Git disappear if you use a workflow that gives you the same features as TFVC and have the same expectations (especially around history): collaborate around a single shared repo instance, push every commit when it's made, and allow fast-forward merges only. Conflict? Rebase locally. Personally, I think a good idea for a Git tutorial would be to recreate the workflow of another version control product into Git in order to introduce some of the new ideas in a familiar war.

BWStearns 10y ago

> these problems simply didn't exist or were not nearly as severe with previous revision control systems I (have to) use one of these systems you speak of without the horrors of having to worry about merge histories or organizing any branches whatsoever. I have to worry that someone in California broke some code, somewhere right before lunch and it'll take me as long to workaround as it will to just take a second lunch. I have to worry that if I miss a release because of QA issues I need to spend a bunch of time reversing all my changes temporarily and then redoing them in a new release and hoping nothing got borked in between. I have to worry about how to show someone out of the office what my changes look like because they're still too janky to push into the release branch. If I'm working from home and Comcast decides I'm due for my weekly outage then I'm SOL. I have to worry about a failed commit going and locking files on other people because apparently I'm the only person ever to run a command that fails (granted, PEBCAK), so let's not worry about making that failure impact a centralized shared state in a negative way. You can spend a lot of time thinking about the best way to do something in git because it lets you do a lot. The choice is essentially "Elaborate workflows" vs "bridge the inadequacies of the tooling by brittle ritualized human processes". Git problems are VCS' first-world problems.