|
|
|
|
|
|
by dboreham
1729 days ago
|
|
|
I'm speaking about the concepts that underly the interface, not the details of options and so on. svn was orders of magnitude better: you checked out a repo, you made local changes, you got to see the changes you made before committing, you committed changes, unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling. That's it. Now, I admit that much of the conceptual complexity with git is to do with it being a decentralized system. svn was not. However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity. |
|
|
The only extra step that git introduced was pushing the changes up to the remote.
- svn checkout -> git clone
- make changes (same for both)
- see changes (svn diff -> git diff)
> unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling.
Which is what you would have to do with git as well if upstream was updated and you pulled it down to your working copy with git.
> However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity.
I think part of the problem is that people want to make getting changes from the repository and sending changes to the repository a single step, whereas git only did that for getting changes with the git pull command. There's no corresponding git push command that handled committing as well as pushing the changes to the remote.
What should have been done was to never give that option. That is, the git pull command should not have been a thing and people would have to learn that there are two steps. One is the network operation of getting the changes or sending the changes and the other is to apply those changes to the working copy or staging those changes in the working copy before sending them over the network.