On 2/26/07, Wolfgang Denk wd@denx.de wrote:
In message 45E311C9.4060905@freescale.com you wrote:
I never felt the need for a .gitignore file; mayby you can explain what you need it for?
To keep the output of git-status clean. I need to do a "make clean" in order for git-status to give me meaningful results.
That's what I do, too. What's the problem with that?
It forces the assumption that you must 'make clean' before you commit.
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
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.
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.
There is another command specifically designed for the task of seeing *all* files not included in the repo.
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.
Note: There absolutely are convention differences between u-boot and other projects. It would be silly to go down the path of trying to unify all conventions; it's a waste of time and it wouldn't work anyway. Implicit choices to diverge happen all the time. It's part of engineering. We don't even think about those sorts of things. However, if an explicit choice is made to diverge from conventions used by another project (like choosing to not use .gitignore files), then there better be a good reason for doing so. (assuming non-trivial differences).
Is the convenience of one developer worth breaking the established convention at the inconvenience of other developers.
But I'm willing to listen to arguments. At the moment it's that either I have to run an additional command I didn't need to use before, or you have to run "make clean" or use "O=". I don't see any significant difference of added inconvenience between these two. So I tend to shift the inconvenience to you :-)
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
g.