3 ms·

This seems blog fails to convey the why of gitless. It looks like a very thin veneer that's trying to hide the index, which I think is a really bad idea. The in

This seems blog fails to convey the why of gitless. It looks like a very thin veneer that's trying to hide the index, which I think is a really bad idea. The index is one of the two main reasons I prefer git over mercurial. The first paragraph says that git has usability issues, but no attempt is made to explain the reasoning and convince the reader that gitless solves these. I also have a UI nitpick: long parameters should have two dashes instead of one so that short parameters can be freely combined; switches like -exc, -inc and -su go needlessly against common convention. You should also not do such arbitrary truncation... --exc and --inc match --exclude and --include unambiguously, so you get shortened forms for free if you simply do a prefix search.

adekok 12y ago
The index seems to be a git-only feature. It's one of those concepts that's so simple, it makes you go "Why the hell didn't I think of that?" The index allows you to have partially staged commits. This is most important during merges. The merged changes are staged. The unmerged ones are left in the file system. So the diffs are small. 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! Arg. Hiding the index makes git easier for newcomers. It also hides a new workflow, unique to git. That workflow is better and more efficient than the ones for other VCS.
- rbehrends 12y ago
  > 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.
      - 12y ago

adekok 12y ago

The index seems to be a git-only feature. It's one of those concepts that's so simple, it makes you go "Why the hell didn't I think of that?" The index allows you to have partially staged commits. This is most important during merges. The merged changes are staged. The unmerged ones are left in the file system. So the diffs are small. 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! Arg. Hiding the index makes git easier for newcomers. It also hides a new workflow, unique to git. That workflow is better and more efficient than the ones for other VCS.

rbehrends 12y ago
> 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.
    - 12y ago