There is a strongly established workflow convention use by other git-using projects. The workflow for committing is this: $ git-status # to show what has changed/added/removed $ git-update-index # as needed to update the index $ git-commit # make it real; It should be noted that 'make clean' is not a required step for the commit workflow.
I can do this fine even with uncleanded files. cg-commit will not anny files that have not been added with cg-add.
Is this different with above sequence of git commands?
You don't *have* to use git-status first. If, for instance, you know all the names of the files which need to be committed. But this is typically done to see what files have changed, and to see what files aren't yet tracked by git. However, when there are a few hundred object files also in that list, git-status is useless for seeing the new files.
It's also a bit inconvenient for checking the status, because people who are used to Linux are used to just typing git-status, and seeing the handful of lines of output. In U-Boot, you only get a handful of lines if you've done make clean.
In other words, the forgetful developer like me has this process in U-Boot:
git-status # swear git-status | less # wonder if I added any new files git-status | less # swear. Give up on finding new files make clean git-status # Ah, I forgot about that one git-add # Add/update all files, including the new ones git-commit #commit the changes
I work in an office environment--all that swearing endangers my job! ;)
I always assumed that you have to use "git-add" to explicitely add new files to the idex. Is this assumption wrong?
No, that's right.
If not, what do a few extra files hurt when running a commit?
It's not a few extra files. It's several hundred. And it makes it harder to find the handful of files which are actually relevant.
I lost you here. Why do you need the output of git-status to commit changes?
Just to identify them. It feeds the information to the developer, so we can tell git which files need to be committed.
Andy