5 ms·

From the video, it looks like all changes are automatically staged. Ignoring the staging area is not going help users understand git I think. Otherwise, it loo

by norswap 13y ago

From the video, it looks like all changes are automatically staged. Ignoring the staging area is not going help users understand git I think. Otherwise, it looks very very cool.

JoshTriplett 13y ago
Agreed; the ability to commit a subset of the changes in your working directory makes it far easier to make a large number of small, focused, single-change commits. Tools like "git add -p" make that even easier. If you ignore the staging area, you become much more tempted to make several unrelated changes in one commit, rather than untangling them.
- snogglethorpe 13y ago
  I agree. The git UI has some warts, but the staging area isn't one of them. It's an extremely useful feature, and a true improvement over traditional SCM interfaces. It's nice to see people wanting to improve git's interface, but please, don't just dumb it down....
- lucian1900 13y ago
  The staging area doesn't really help much with that, though. Too often there are unrelated changes to the same file, which are precisely as inconvenient to split up as those in separate files without a staging area.
  - Mithaldu 13y ago
    The staging area makes it possible to split them up by selectively adding lines to it with `git add -p` or the much superior `git gui`.
  - jdpage 13y ago
    That's exactly what git add -p does, and it's vastly more convenient than when you don't have a staging area.
    - 6ren 13y ago
      I find the problem with git add -p is when you have changes that are overlapping - e.g. you've tried a few variations of implementing something, that have many commonalities - but sadly you didn't commit them as you went along, but now what to, for reference in case they are needed later. git add -p doesn't help tease them apart, because its hunks are based on diffs, and the granularity usually does not coincide with actual changes (nor syntax or semantics of the languages). Which is really expecting a bit too much! Diff's implementation of LCS algorithm is incredibly fast and works amazingly well for changes in different places. So what I do is edit the file to what I want, stage and commit, then undo and continue. This doesn't really use the staging area, and I'm hoping there's a better way to do it... if anyone can think of one?
      - Mithaldu 13y ago
        I don't use `git add -p` much, since i commit exclusively with `git gui`. The reason being that `git gui` allows me to stage single lines, or hunks AND allows me to change the granularity of hunks on the fly. Even if that isn't an option for you, i'm sure that `git add -p` has a command to modify hunk granilarity.
      - oyvindn 13y ago
        git add -p, then "s" until it can't split the hunk any more, then "e" to edit the hunk manually?
        6ren 13y ago
        you can do it, but I've found in some cases that modifying patches (including "e") becomes more complex than stating the desired result directly.
      - blktiger 13y ago
        One thing that I've found handy on a few occasions is Atlassian Source Tree. You can stage individual lines, not just individual hunks. Sometimes that makes it much easier to pull apart the changes.
deleted 13y ago
[deleted]
cbhl 13y ago
I spent a depressingly long time using git before understanding how the staging area worked. I think hiding it under a novice/expert flag is a terribad idea, but I'm not sure what the right way to expose the staging area in this interface would be.
FredrikNoren 13y ago
I actually started of having the staging area use git add etc. and being just a reflection of what was staged. But that meant I either had to manually add each file (or have an "add all" button), or automatically stage them. The first option felt wrong because most of the time you just want to commit all the changes, so in most cases it's just more work for the user. The second option felt wrong because I didn't want to change around the git structure "behind your back" (just starting ungit shouldn't mess up your repo); so I went with just having it in the ui and doing the real git work on commit. In general I want it to be as close to git as possible but I hope this trade off made sense with this little explanation :)
- Mithaldu 13y ago
  In the small scale your rationalization is logical, however in the big picture you're going to end up with teaching people to make useless commits. As long as this is true of ungit, it is a project i will have to vehemently recommend against in any circumstance. What ungit should do is the same thing as git gui: When you go to make a commit, you can view diffs of your files and select single lines to be added to your next commit. Edit: I've created an issue for this: https://github.com/FredrikNoren/ungit/issues/98 https://github.com/FredrikNoren/ungit/issues/98
StavrosK 13y ago
I think the staging area is a horrible idea. It greatly complicates the UI ("diff --cached"? Really?) without providing many benefits (if you want to commit just some files, you could simply specify the names at commit time. I really love bzr's UI in this respect, and I understand Mercurial is similar too.
- barrkel 13y ago
  You could use git commit -a, but I've found that seldom does what you want. Usually, you don't want to commit all files, because you've made unrelated changes to configuration, debug logging etc. And sometimes you don't even want to commit all the changes in a single file, and git lets you choose which diff sections ("hunks") to commit with git add -p. I came to git already knowing what a dag was, and after having cobbled together my own patch management system to make up for deficiencies in svn, so I didn't have much difficulty intuiting almost the whole of git after very little time.
  - StavrosK 13y ago
    I came to git from bzr, and I always use commit -a these days. If I want to ignore a file, I just specify the ones I actually want to commit, and it works just fine for my purposes (I don't generally make irrelevant changes). YMMV, of course.
- Nervetattoo 13y ago
  You couldn't run tests only on your staged changes pre-commit without the staging area. Right now my pre-commit hook stashes any non-staged changes, from inside the same files that has staged content, and then runs tests. This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work. The staging area surely adds complexity, but if you do not like it then simply don't use git.
  - StavrosK 13y ago
    > This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work. If I have ongoing work I want to remove, I just stash it, as you said. I don't need a staging area to stash things, and it's pretty rare that I'll have unrelated work anyway. > The staging area surely adds complexity, but if you do not like it then simply don't use git. Ah, the old "your arm hurts? Just cut it off!" solution. Yes, I will just not use git, I will just email my team diffs.
btbuildem 13y ago
Not at all -- you can uncheck some files, and only the checked ones will be committed.

by norswap 13y ago

From the video, it looks like all changes are automatically staged. Ignoring the staging area is not going help users understand git I think. Otherwise, it looks very very cool.

JoshTriplett 13y ago

Agreed; the ability to commit a subset of the changes in your working directory makes it far easier to make a large number of small, focused, single-change commits. Tools like "git add -p" make that even easier. If you ignore the staging area, you become much more tempted to make several unrelated changes in one commit, rather than untangling them.

snogglethorpe 13y ago
I agree. The git UI has some warts, but the staging area isn't one of them. It's an extremely useful feature, and a true improvement over traditional SCM interfaces. It's nice to see people wanting to improve git's interface, but please, don't just dumb it down....
lucian1900 13y ago
The staging area doesn't really help much with that, though. Too often there are unrelated changes to the same file, which are precisely as inconvenient to split up as those in separate files without a staging area.
- Mithaldu 13y ago
  The staging area makes it possible to split them up by selectively adding lines to it with `git add -p` or the much superior `git gui`.
- jdpage 13y ago
  That's exactly what git add -p does, and it's vastly more convenient than when you don't have a staging area.
  - 6ren 13y ago
    I find the problem with git add -p is when you have changes that are overlapping - e.g. you've tried a few variations of implementing something, that have many commonalities - but sadly you didn't commit them as you went along, but now what to, for reference in case they are needed later. git add -p doesn't help tease them apart, because its hunks are based on diffs, and the granularity usually does not coincide with actual changes (nor syntax or semantics of the languages). Which is really expecting a bit too much! Diff's implementation of LCS algorithm is incredibly fast and works amazingly well for changes in different places. So what I do is edit the file to what I want, stage and commit, then undo and continue. This doesn't really use the staging area, and I'm hoping there's a better way to do it... if anyone can think of one?
    - Mithaldu 13y ago
      I don't use `git add -p` much, since i commit exclusively with `git gui`. The reason being that `git gui` allows me to stage single lines, or hunks AND allows me to change the granularity of hunks on the fly. Even if that isn't an option for you, i'm sure that `git add -p` has a command to modify hunk granilarity.
    - oyvindn 13y ago
      git add -p, then "s" until it can't split the hunk any more, then "e" to edit the hunk manually?
      - 6ren 13y ago
        you can do it, but I've found in some cases that modifying patches (including "e") becomes more complex than stating the desired result directly.
    - blktiger 13y ago
      One thing that I've found handy on a few occasions is Atlassian Source Tree. You can stage individual lines, not just individual hunks. Sometimes that makes it much easier to pull apart the changes.

deleted 13y ago

[deleted]

cbhl 13y ago

I spent a depressingly long time using git before understanding how the staging area worked. I think hiding it under a novice/expert flag is a terribad idea, but I'm not sure what the right way to expose the staging area in this interface would be.

FredrikNoren 13y ago

I actually started of having the staging area use git add etc. and being just a reflection of what was staged. But that meant I either had to manually add each file (or have an "add all" button), or automatically stage them. The first option felt wrong because most of the time you just want to commit all the changes, so in most cases it's just more work for the user. The second option felt wrong because I didn't want to change around the git structure "behind your back" (just starting ungit shouldn't mess up your repo); so I went with just having it in the ui and doing the real git work on commit. In general I want it to be as close to git as possible but I hope this trade off made sense with this little explanation :)

Mithaldu 13y ago
In the small scale your rationalization is logical, however in the big picture you're going to end up with teaching people to make useless commits. As long as this is true of ungit, it is a project i will have to vehemently recommend against in any circumstance. What ungit should do is the same thing as git gui: When you go to make a commit, you can view diffs of your files and select single lines to be added to your next commit. Edit: I've created an issue for this: https://github.com/FredrikNoren/ungit/issues/98 https://github.com/FredrikNoren/ungit/issues/98

StavrosK 13y ago

I think the staging area is a horrible idea. It greatly complicates the UI ("diff --cached"? Really?) without providing many benefits (if you want to commit just some files, you could simply specify the names at commit time. I really love bzr's UI in this respect, and I understand Mercurial is similar too.

barrkel 13y ago
You could use git commit -a, but I've found that seldom does what you want. Usually, you don't want to commit all files, because you've made unrelated changes to configuration, debug logging etc. And sometimes you don't even want to commit all the changes in a single file, and git lets you choose which diff sections ("hunks") to commit with git add -p. I came to git already knowing what a dag was, and after having cobbled together my own patch management system to make up for deficiencies in svn, so I didn't have much difficulty intuiting almost the whole of git after very little time.
- StavrosK 13y ago
  I came to git from bzr, and I always use commit -a these days. If I want to ignore a file, I just specify the ones I actually want to commit, and it works just fine for my purposes (I don't generally make irrelevant changes). YMMV, of course.
Nervetattoo 13y ago
You couldn't run tests only on your staged changes pre-commit without the staging area. Right now my pre-commit hook stashes any non-staged changes, from inside the same files that has staged content, and then runs tests. This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work. The staging area surely adds complexity, but if you do not like it then simply don't use git.
- StavrosK 13y ago
  > This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work. If I have ongoing work I want to remove, I just stash it, as you said. I don't need a staging area to stash things, and it's pretty rare that I'll have unrelated work anyway. > The staging area surely adds complexity, but if you do not like it then simply don't use git. Ah, the old "your arm hurts? Just cut it off!" solution. Yes, I will just not use git, I will just email my team diffs.

btbuildem 13y ago

Not at all -- you can uncheck some files, and only the checked ones will be committed.