>>92482187> In general, I think git makes it easier to manipulate history than most> alternatives. I believe this is a good thing, because the commit log is going to> be read many times in the future, so it's best to get it right. (This is why> "reverse merges" are frowned up in git). Fossil SCM takes the completely> opposite approach of recording the actual history of the project (no matter how> messy it is), as opposed to a constructed one. Where would your VCS stand on> this issue?Complete revisionism, the commit history should look exactly how you intend.
> The staging area is there so that you could do partial commits. It's for those> moments when you're working on a new feature, and notice a bug in a different> part of the code base.While I have used git in that exact manor, I'd suppose the same idea could be
achieved by simply "toggling" off the file, and committing the rest without
further action. This would be the 'you are more correct than incorrect' approach.
Though I do understand the use of a stage and a stash, and it would be a very
useful feature, I'll surely add it at some point with the same or optional
toggle inductance (toggle the file in add subset to a stage commit).
I suppose you could write it down like this,
stage model:
- Real staging - the stage includes effective file difference, effectively a stash ready to be pushed.
- Fake staging - filenames and their current hash, reducing filesize greatly (GENERALLY)
commit model:
- As-Is - commit all changes, without asking
- Specify-Each - specify commit each change every time
something between these two would likely be what most developers would want.
But real staging seems to work with either commit model, so it doesn't hurt.
the commit model could be seperated to a per-file basis, which leads to git add.
I suppose it's the choice of the user with the default being Specify-Each.
