3 ms·

Why is that? I work regularly with Mercurial and Git. The stage isn’t a huge problem or anything, but it’s super annoying and gives me zero value. TBH I think

Why is that? I work regularly with Mercurial and Git. The stage isn’t a huge problem or anything, but it’s super annoying and gives me zero value. TBH I think the stage is kinda dirty. Because it means you’re making a commit that has never actually existed on your machine and thus can’t have possibly been tested.

Izkata 3y ago
Two things: To review the changes piece by piece before commit (git add -p) in case there's something temporary in there I forgot, and to easily exclude any such thing I never intended to commit (usually todo-style comments, sometimes hardcoding a value to trigger a bug or a popup, etc) I remember a decade ago trying mercurial and git at the same time when subversion was all I knew, and that there was something about mercurial that I found really confusing. It's long enough ago I don't remember what it was, and it may be better now, but git clicked immediately. I wouldn't be surprised if it was the way they handle commits instead of having a staging area. Also compared to subversion, the staging area is an explicit form of something that half-exists in how it tracks files for committing.
- forrestthewoods 3y ago
  Interesting. I use Mercurial in my day job and use Araxis Merge. Before pushing to CI I use Araxis to diff every file. Can make changes to the file in the tool if needed. Often reverting temp changes or spurious whitespace. This generates new changes which I then amend.
adastra22 3y ago
The work around is that I stash after commit and then test the newly made patch before pushing to the repo. That describes git in a nutshell. It lives up to its name by providing stupid roundabout ways to get things done, but otherwise mostly doesn’t get in your way. Pijul is in theory better, but GitHub prevents any competition from being serious.

3 ms·

Why is that? I work regularly with Mercurial and Git. The stage isn’t a huge problem or anything, but it’s super annoying and gives me zero value. TBH I think

by forrestthewoods 3y ago

Izkata 3y ago
Two things: To review the changes piece by piece before commit (git add -p) in case there's something temporary in there I forgot, and to easily exclude any such thing I never intended to commit (usually todo-style comments, sometimes hardcoding a value to trigger a bug or a popup, etc) I remember a decade ago trying mercurial and git at the same time when subversion was all I knew, and that there was something about mercurial that I found really confusing. It's long enough ago I don't remember what it was, and it may be better now, but git clicked immediately. I wouldn't be surprised if it was the way they handle commits instead of having a staging area. Also compared to subversion, the staging area is an explicit form of something that half-exists in how it tracks files for committing.
- forrestthewoods 3y ago
  Interesting. I use Mercurial in my day job and use Araxis Merge. Before pushing to CI I use Araxis to diff every file. Can make changes to the file in the tool if needed. Often reverting temp changes or spurious whitespace. This generates new changes which I then amend.
adastra22 3y ago
The work around is that I stash after commit and then test the newly made patch before pushing to the repo. That describes git in a nutshell. It lives up to its name by providing stupid roundabout ways to get things done, but otherwise mostly doesn’t get in your way. Pijul is in theory better, but GitHub prevents any competition from being serious.