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

[Wolfgang Denk]

In message <528646bc0702261635y51e80d76sd27c4b113eb09820 at 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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ninety-Ninety Rule of Project Schedules:
        The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.