[U-Boot-Users] [PATCH] Add .gitignore files

[Grant Likely]

On 2/26/07, Wolfgang Denk <wd at denx.de> wrote:
> In message <45E311C9.4060905 at 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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195