3 ms·

> Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun

> Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them! I am not sure what you're talking about. Every semi-popular VCS I know of allows you to differentiate between files with and without (or with resolved) merge conflicts. Examples (in alphabetical order, because people can get religious here, and I don't want to appear to favor one over the other): Bazaar: Integrated in bzr status and also available as a separate bzr conflicts command. Fossil: Part of fossil status and fossil changes; will display files with conflicts with a CONFLICT rather than EDITED marker. Mercurial: Here, hg resolve --list or hg resolve -l will list merged files, both resolved snd unresolved (marked with R and U, respectively). Monotone: Monotone has mtn show_conflicts and mtn conflicts show_remaining and in general a fairly sophisticated (or complicated, depending on who you ask) set of commands for analyzing and resolving merge conflicts [1]. Subversion: Conflicts are marked with "C" in svn status. (I've excluded Darcs, which has a model that's quite different from the traditional merge command, but for the same reason has fairly extensive machinery for dealing with conflicts, for better or worse.) [1] http://www.monotone.ca/docs/Conflicts.html http://www.monotone.ca/docs/Conflicts.html

david-given 12y ago
Is the git index just a changelist? (Genuine question --- I've never been able to get my head around what it's for.) Most VCSes support these, even Subversion.
- rbehrends 12y ago
  Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident. This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds. The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.
  - obsurveyor 12y ago
    So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up. git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it. The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
  - Shorel 12y ago
    As a developer that's actually something I love git for. In a big company with several tickets describing errors in the system, I can work on several issues at the same time. Or explore different ideas and implementations. Now, the issue with the compile and testing can be real, but I have an easy workaround. I have another working copy/checkout of the repository, called <repository>-ro. I never edit files in the read only copy, unless it's to fix a merge conflict. All tests and merges are done in this other copy. Any revision does eventually exists on disk, in this copy.
    - rbehrends 12y ago
      You don't need a staging area if you want to just commit selectively. No VCS that I know of will stop you from doing just that if you really want to. bzr/fossil/git/hg/mtn/svn commit path1 ... pathn will selectively commit only the listed files/directories (some of them will even allow you to commit individual hunks, as in "git add -p", if you like to live dangerously). The biggest problem with the staging area is that (1) it can happen accidentally that you forgot to "git add" a file or (2) it really only gives you any advantage over selective commits when you stage a non-trivial selection of files, which is exactly where things have a chance of going wrong.

david-given 12y ago

Is the git index just a changelist? (Genuine question --- I've never been able to get my head around what it's for.) Most VCSes support these, even Subversion.

rbehrends 12y ago
Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident. This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds. The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.
- obsurveyor 12y ago
  So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up. git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it. The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
- Shorel 12y ago
  As a developer that's actually something I love git for. In a big company with several tickets describing errors in the system, I can work on several issues at the same time. Or explore different ideas and implementations. Now, the issue with the compile and testing can be real, but I have an easy workaround. I have another working copy/checkout of the repository, called <repository>-ro. I never edit files in the read only copy, unless it's to fix a merge conflict. All tests and merges are done in this other copy. Any revision does eventually exists on disk, in this copy.
  - rbehrends 12y ago
    You don't need a staging area if you want to just commit selectively. No VCS that I know of will stop you from doing just that if you really want to. bzr/fossil/git/hg/mtn/svn commit path1 ... pathn will selectively commit only the listed files/directories (some of them will even allow you to commit individual hunks, as in "git add -p", if you like to live dangerously). The biggest problem with the staging area is that (1) it can happen accidentally that you forgot to "git add" a file or (2) it really only gives you any advantage over selective commits when you stage a non-trivial selection of files, which is exactly where things have a chance of going wrong.