3 ms·

But... but... but... git bad!

by pyre 12y ago

eridius 12y ago
It's a prevalent meme, isn't it? I'm surprised at how many people never even realized how fundamentally dangerous it was to issue an `svn update` with local changes. And perhaps less seriously but still problematic, how `svn commit` can put the repository into a state that never existed on any developer's machine (because it effectively does a rebase on the server), which is not always safe to do even when there's no merge conflicts.
- Xylakant 12y ago
  > how `svn commit` can put the repository into a state that never existed on any developer's machine git add -p creates the same issue for git (a commit that never existed on disk) and git rebase with squash and/or reodering of commits does as well. That's usually considered best practice. The problem I often observe with git (pull -)rebase is that people have a hard time wrapping their mind around the fact that all commits change and when they change and in what state the checkout is are when they get a merge conflict (remote HEAD plus whatever was already applied). The conflict is often unavoidable and you can argue that rebase is making it easier to resolve the conflict, but it's harder to reason about than "ok, update does a merge and I get whatever is on the server plus my local changes".
  - eridius 12y ago
    The difference between `svn commit` and the various forms of `git add` or rebasing is that the developer can test the commits (or visually inspect them) before pushing. In fact, the argument that `git add -p` produces a commit that didn't exist on disk is exactly the same as the argument that developers can commit code that they never actually built & tested. Which is to say, the important point isn't that the commit tree existed in isolation on the developer's disk, but rather that the developer did any testing necessary to verify that the commit is good. And the reason why `svn commit` is bad in this regard is because it creates the never-before-seen result on the server. > The conflict is often unavoidable If the conflict is unavoidable, then you're going to get a conflict regardless of how you go about it (rebase vs merge vs `svn update`). The difference is with `svn update` you can't abort the whole process and start over if you need to, because you've already permanently lost the previous state of your work tree. Whereas with `git rebase` and `git merge`, you can abort and you'll get the exact state you had prior to the command.

But... but... but... git bad!

by pyre 12y ago

But... but... but... git bad!

It's a prevalent meme, isn't it? I'm surprised at how many people never even realized how fundamentally dangerous it was to issue an `svn update` with local changes. And perhaps less seriously but still problematic, how `svn commit` can put the repository into a state that never existed on any developer's machine (because it effectively does a rebase on the server), which is not always safe to do even when there's no merge conflicts.

Xylakant 12y ago
> how `svn commit` can put the repository into a state that never existed on any developer's machine git add -p creates the same issue for git (a commit that never existed on disk) and git rebase with squash and/or reodering of commits does as well. That's usually considered best practice. The problem I often observe with git (pull -)rebase is that people have a hard time wrapping their mind around the fact that all commits change and when they change and in what state the checkout is are when they get a merge conflict (remote HEAD plus whatever was already applied). The conflict is often unavoidable and you can argue that rebase is making it easier to resolve the conflict, but it's harder to reason about than "ok, update does a merge and I get whatever is on the server plus my local changes".
- eridius 12y ago
  The difference between `svn commit` and the various forms of `git add` or rebasing is that the developer can test the commits (or visually inspect them) before pushing. In fact, the argument that `git add -p` produces a commit that didn't exist on disk is exactly the same as the argument that developers can commit code that they never actually built & tested. Which is to say, the important point isn't that the commit tree existed in isolation on the developer's disk, but rather that the developer did any testing necessary to verify that the commit is good. And the reason why `svn commit` is bad in this regard is because it creates the never-before-seen result on the server. > The conflict is often unavoidable If the conflict is unavoidable, then you're going to get a conflict regardless of how you go about it (rebase vs merge vs `svn update`). The difference is with `svn update` you can't abort the whole process and start over if you need to, because you've already permanently lost the previous state of your work tree. Whereas with `git rebase` and `git merge`, you can abort and you'll get the exact state you had prior to the command.