3 ms·

Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote br

Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..

throwawayboise 5y ago
Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.
- emodendroket 5y ago
  It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
- strictfp 5y ago
  I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
  - jeffbee 5y ago
    > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
    - brigandish 5y ago
      Because it’s file based, and that’s obviously behind a lot of the criticism coming from the author of Fossil.
    - mlyle 5y ago
      > simply cannot do it, unless I clone the entire repo for every change Note that you can have multiple working copies from one clone for a few years now. git worktree add <path> <branch>
  - plorkyeran 5y ago
    When I am working on assembling multiple commits at once, I make a large number of small commits with commit messages that indicate which commit they're going to end up in, and then do an interactive rebase at the end. The workflow looks something like: # At the point I realize I have two commits git add -p git commit -m 'first' git commit -am 'second' # Do some more editing git add -p; git commit -m 'debug' # commit the debug stuff so that I don't have to keep skipping it git add -p; git commit -m 'first' git add -p; git commit -m 'second' # After repeating the above a few times git rebase -i origin/master # Remove the debug commits, move the first/second/etc. commits together, squash the runs of first/second/etc. into one commit each, and then go back and write commit messages for each of them

throwawayboise 5y ago

Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.

emodendroket 5y ago
It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
strictfp 5y ago
I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
- jeffbee 5y ago
  > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
  - brigandish 5y ago
    Because it’s file based, and that’s obviously behind a lot of the criticism coming from the author of Fossil.
  - mlyle 5y ago
    > simply cannot do it, unless I clone the entire repo for every change Note that you can have multiple working copies from one clone for a few years now. git worktree add <path> <branch>
- plorkyeran 5y ago
  When I am working on assembling multiple commits at once, I make a large number of small commits with commit messages that indicate which commit they're going to end up in, and then do an interactive rebase at the end. The workflow looks something like: # At the point I realize I have two commits git add -p git commit -m 'first' git commit -am 'second' # Do some more editing git add -p; git commit -m 'debug' # commit the debug stuff so that I don't have to keep skipping it git add -p; git commit -m 'first' git add -p; git commit -m 'second' # After repeating the above a few times git rebase -i origin/master # Remove the debug commits, move the first/second/etc. commits together, squash the runs of first/second/etc. into one commit each, and then go back and write commit messages for each of them