In message 528646bc0702261635y51e80d76sd27c4b113eb09820@mail.gmail.com you wrote:
It forces the assumption that you must 'make clean' before you commit.
Well, I don't have to do that.
Maybe my confusion / ignorance comes from the fact that I tend to use cogito rather that raw git commands.
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.
Alternately, the same thing is done with cogito: $ cg-status $ cg-commit
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?
In this work flow, the user is interested primarily in what changes will be made to the repo. As such, git-status is optimized to that specific task. .gitignore files are a feature designed to support that optimization. They are used to omit uninteresting files, where uninteresting is defined as files you don't care about when performing the task of commit.
I always assumed that you have to use "git-add" to explicitely add new files to the idex. Is this assumption wrong?
If not, what do a few extra files hurt when running a commit?
It is absolutely true that git-status can be used in the manor that Wolfgang is using it. It is also absolutely true that absence of .gitfiles does not technically prevent using the established workflow conventions. All the information is still there. However, no .gitignore files means that the output of git-status is unfiltered. Unfiltered output is harder to parse and therefore requires more work to commit changes. I'd even argue that the unfiltered output is verbose enough to be useless. This is not the established workflow used in other projects.
I lost you here. Why do you need the output of git-status to commit changes?
The next question that must be asked is "why does it matter?" If u-boot has it's own convention and the commands all work, then what's the problem? The problem is that it erects an artificial barrier between the developing for u-boot and for other projects, *while adding no significant benefit*. The last part is important. If significant benefit can be shown to differing from the conventions used by other project, then I strongly support such a difference.
You are really persuasive.
Will you nevertheless help me and explain what I'm missing? Why is all this needed?
I second the argument that's already been made the number of people inconvenienced by .gitignore absence is greater than the number inconvenienced by their presence. :-P
So much ado about this ...
You leave me no sane way out but to give in, but at least I want to understand why all this is needed. I don't get it yet.
Best regards,
Wolfgang Denk