3 ms·
I work on a huge codebase using Git together with thousands of other developers. The staging area is a very welcome tool, because often I have to do little chan
by exDM69 13y ago
I work on a huge codebase using Git together with thousands of other developers. The staging area is a very welcome tool, because often I have to do little changes that I do not want to commit, most often working around some little mistakes by another developer on the other side of the world.
Fixing a small problem in a Makefile, adding a few debug prints somewhere, disabling an unrelated failing assert, and little unrelated fixes like that. It does not make sense to fix and commit them because that would be a distraction and duplicate work because someone is most likely working on it already. But I do need to make my builds pass and my tests run to get on with my work, using little fixes I do not want to include in my commit.
The staging are may be confusing to newbies but it is very useful in large projects with a big team.
- chmike 13y agoI'm not an expert Git user, but I'm impressed by gitless after reading this document. The use case you refer to is one I frequently have. But I don't think staging is the right solution for that. For one it's limite to file granularity, for two your local changes can be lost by a reset. So it seems preferable if we could store our local changes as commits in a branch. In this way we can easily identify these local changes and add new one. When we commit we should be able to specify if the commit is just a local change to fix something for a test or a change to be published. I think git has the tools to do it with cherry pick, but maybe there is a simpler way.