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

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

[Timur Tabi]

Add various .gitignore files for all of the generated targets.  This prevents these files
from being accidentally committed and showing up in git-status.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 .gitignore                        |    5 +++++
 examples/.gitignore               |    4 ++++
 include/.gitignore                |    5 +++++
 include/asm-arm/.gitignore        |    1 +
 include/asm-avr32/.gitignore      |    1 +
 include/asm-blackfin/.gitignore   |    1 +
 include/asm-i386/.gitignore       |    1 +
 include/asm-m68k/.gitignore       |    1 +
 include/asm-microblaze/.gitignore |    1 +
 include/asm-mips/.gitignore       |    1 +
 include/asm-nios/.gitignore       |    1 +
 include/asm-nios2/.gitignore      |    1 +
 include/asm-ppc/.gitignore        |    1 +
 tools/.gitignore                  |    7 +++++++
 14 files changed, 31 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 examples/.gitignore
 create mode 100644 include/.gitignore
 create mode 100644 include/asm-arm/.gitignore
 create mode 100644 include/asm-avr32/.gitignore
 create mode 100644 include/asm-blackfin/.gitignore
 create mode 100644 include/asm-i386/.gitignore
 create mode 100644 include/asm-m68k/.gitignore
 create mode 100644 include/asm-microblaze/.gitignore
 create mode 100644 include/asm-mips/.gitignore
 create mode 100644 include/asm-nios/.gitignore
 create mode 100644 include/asm-nios2/.gitignore
 create mode 100644 include/asm-ppc/.gitignore
 create mode 100644 tools/.gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5883e45
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,5 @@
+.*
+*.o
+*.a
+System.map
+u-boot*
diff --git a/examples/.gitignore b/examples/.gitignore
new file mode 100644
index 0000000..f715e1b
--- /dev/null
+++ b/examples/.gitignore
@@ -0,0 +1,4 @@
+*.bin
+*.srec
+hello_world
+sched
diff --git a/include/.gitignore b/include/.gitignore
new file mode 100644
index 0000000..8d2fb78
--- /dev/null
+++ b/include/.gitignore
@@ -0,0 +1,5 @@
+bmp_logo.h
+config.h
+config.mk
+version_autogenerated.h
+asm
diff --git a/include/asm-arm/.gitignore b/include/asm-arm/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-arm/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-avr32/.gitignore b/include/asm-avr32/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-avr32/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-blackfin/.gitignore b/include/asm-blackfin/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-blackfin/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-i386/.gitignore b/include/asm-i386/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-i386/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-m68k/.gitignore b/include/asm-m68k/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-m68k/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-microblaze/.gitignore b/include/asm-microblaze/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-microblaze/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-mips/.gitignore b/include/asm-mips/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-mips/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-nios/.gitignore b/include/asm-nios/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-nios/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-nios2/.gitignore b/include/asm-nios2/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-nios2/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/include/asm-ppc/.gitignore b/include/asm-ppc/.gitignore
new file mode 100644
index 0000000..1689398
--- /dev/null
+++ b/include/asm-ppc/.gitignore
@@ -0,0 +1 @@
+arch
diff --git a/tools/.gitignore b/tools/.gitignore
new file mode 100644
index 0000000..6ef414a
--- /dev/null
+++ b/tools/.gitignore
@@ -0,0 +1,7 @@
+bmp_logo
+crc32.c
+envcrc
+environment.c
+gen_eth_addr
+img2srec
+mkimage
-- 
1.5.0

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

[Grant Likely]

On 2/20/07, Timur Tabi <timur@freescale.com> wrote:
> Add various .gitignore files for all of the generated targets.  This prevents these files
> from being accidentally committed and showing up in git-status.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

Wolfgang, I know you're not fond of .gitignore files because you use
git-status to get a list of all non-committed files.  However, for
many of us having a nice set of .gitignore files is pretty much a
necessity.  I personally have a .gitignore patch that I need to apply
everytime I fetch the latest mainline.

If an alternative command can be used to do the same thing, would you
consider accepting this patch?  Have you tried: 'git-ls-files
--others'?

Thanks,
g.

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

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

[Wolfgang Denk]

In message <11720139822982-git-send-email-timur@freescale.com> you wrote:
> Add various .gitignore files for all of the generated targets.  This prevents these files
> from being accidentally committed and showing up in git-status.

I don't want to have .gitignore files; see the archive for
explanations.

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
The one who says it cannot be done should never interrupt the one who
is doing it.

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

[Wolfgang Denk]

In message <528646bc0702201547o28480db3g8973c63764fd58ce@mail.gmail.com> you wrote:
>
> Wolfgang, I know you're not fond of .gitignore files because you use
> git-status to get a list of all non-committed files.  However, for

No, it's not about non-committed files. It's  about  files  that  get
forgotten  to be cleaned up because of errors / omissions / dead code
in the Makefiles.

> many of us having a nice set of .gitignore files is pretty much a
> necessity.  I personally have a .gitignore patch that I need to apply
> everytime I fetch the latest mainline.

I never felt the need for a .gitignore file; mayby you can explain
what you need it for?

> If an alternative command can be used to do the same thing, would you
> consider accepting this patch?  Have you tried: 'git-ls-files
> --others'?

It doesn't do what I want. For example:

	-> cg-status
	...
	? LOG/
	? board/amcc/yellowstone/
	-> git-ls-files --others
	LOG/cam5200.ERR
	LOG/cam5200.MAKELOG
	->

The first command shows me that there is a stale (empty) directory
left, the second doesn't.


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
COBOL is for morons.                                 -- E.W. Dijkstra

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

[Timur Tabi]

Wolfgang Denk 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.

Another reason for .gitignore is to avoid accidentally including target files in 
a patch.

> 	-> cg-status
> 	...
> 	? LOG/
> 	? board/amcc/yellowstone/
> 	-> git-ls-files --others
> 	LOG/cam5200.ERR
> 	LOG/cam5200.MAKELOG
> 	->
> 
> The first command shows me that there is a stale (empty) directory
> left, the second doesn't.

Hmmm... git-status doesn't show the LOG directory either.

If git-ls-files were updated to include empty directories, would you be willing 
to have .gitignore files?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Scott Wood]

On Mon, Feb 26, 2007 at 02:15:38PM +0100, Wolfgang Denk wrote:
> In message <528646bc0702201547o28480db3g8973c63764fd58ce@mail.gmail.com> you wrote:
> > If an alternative command can be used to do the same thing, would you
> > consider accepting this patch?  Have you tried: 'git-ls-files
> > --others'?
> 
> It doesn't do what I want. For example:
> 
> 	-> cg-status
> 	...
> 	? LOG/
> 	? board/amcc/yellowstone/
> 	-> git-ls-files --others
> 	LOG/cam5200.ERR
> 	LOG/cam5200.MAKELOG
> 	->
> 
> The first command shows me that there is a stale (empty) directory
> left, the second doesn't.

Try "git ls-files --others --directory".
And for cleaning absolutely everything, "git clean -x -d".

-Scott

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

[Wolfgang Denk]

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?

Also, you could get used to using the O= option and  put  the  builkd
tree  in  a  separate  directory, so you don't even have to run "make
clean".

And as mentioned before, I see the benefit of the  current  situation
that  it clearly shows if "make clean" fails to clean up any files it
should.

> If git-ls-files were updated to include empty directories, would you be willing 
> to have .gitignore files?

Willing...

To be honest: no. My regular working mode is to  use  "cg-status"  to
see what was changed / added etc. before I commit a change. For me it
is  very  convenient  when  I  see  any  stray files at the same time
without need to run any other command.

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 :-)

However, if you have a *good* reason for using .gitignore files, I
will reconsider.

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
Youth doesn't excuse everything.
	-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
	   stardate 5928.5.

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

[Timur Tabi]

Wolfgang Denk wrote:

> 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 think that's a very good summary of the current situation.

However, I would like to point out that, at least according to the current 
discussion, you are the only person who opposes .gitignore files.  Everyone else 
wants this patch applied.  So it's not really just me who is inconvenienced by 
the status quo - it's everyone but you who is inconvenienced.

> However, if you have a *good* reason for using .gitignore files, I
> will reconsider.

I think I have already come up with arguments to use .gitignore files, and these 
are just the normal reasons for using .gitignore files.  I don't have anything 
else to add to this discussion.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Jerry Van Baren]

Timur Tabi wrote:
> Wolfgang Denk wrote:
> 
>> 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 think that's a very good summary of the current situation.
> 
> However, I would like to point out that, at least according to the current 
> discussion, you are the only person who opposes .gitignore files.  Everyone else 
> wants this patch applied.  So it's not really just me who is inconvenienced by 
> the status quo - it's everyone but you who is inconvenienced.

Well, everyone that spoke up spoke up for the patch, but most of the 
developers on the list did not speak up.  Personally, I don't feel 
inconvenienced by Wolfgang's choice and am OK with status quo (inertia 
is the most powerful force in the universe).
<http://thinkexist.com/quotation/the_most_powerful_force_in_the_universe_is/158830.html?
although that is apparently an urban legend:
<http://en.wikipedia.org/wiki/Einstein#Popularity_and_cultural_impact>

I suspect that, for most developers, it's not an itch so they aren't 
scratching it.

Best regards,
gvb

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

[Grant Likely]

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.

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

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

[Andy Fleming]

On 2/26/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 2/26/07, Wolfgang Denk <wd@denx.de> wrote:

> 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 had a wordy email which boiled down to the above argument, so I'll
just agree.  Arguing that we should just go with the flow (rather than
overcome inertia) by leaving out .gitignore files is assuming that
U-Boot is a closed system.  :)

There's a *lot* of momentum behind *using* them, and I know every
single developer I've talked with (with the notable exception of
Wolfgang) has complained on multiple occasions about the uselessness
of git status output in U-Boot.


> > 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

Agreed.  Our inertia is greater than yours!  Join us!  ;)

Andy

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

[Wolfgang Denk]

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

-- 
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.

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

[Andy Fleming]

> > 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

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

[Grant Likely]

On 2/26/07, Wolfgang Denk <wd@denx.de> wrote:
> 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.

Actually, I think you've hit on something here that I wasn't thinking
about.  By default,cg-commit records all changes in the working set.
git-commit requires you to explicitly mark the files for commit (using
one of git-update-index, git-commit <filelist>, or git-commit -a).  So
while the resulting tree is compatible (praise God!), it does
encourage a different usage model.

With cg-commit, you don't really need cg-status.  When you do a
cg-commit, it brings up an editor window and tells you exactly what it
intends to commit, and even gives you the option to change the commit
list before finishing.  cg-status is redundant for this activity.

With git-commit, it's different.  git-status is used multiple times to
determine what state the index is in.  Calls to git-update-index,
git-add and git-rm are used to manipulate the index before finally
calling git-commit.  hollisb would puke on this UI, but some of us
actually like it.  :)

Not having a nice set of .gitignore files doesn't really impact
cg-commit usage, but it severely impacts those of us using git-commit.
 Every time we do a git-status there are a load of uninteresting .o
files interleaved with a (usually) small number interesting changes.
Plus, if you're like me and make many commits 'on the fly', then it
becomes invasive to do a 'make clean' before the output git-status
becomes parseable by mere mortals.

>
> > 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?

No it's not different.  Your right.  New files must always be
explicitly added.  I was also wrong when I wrote the cogito workflow
above; cg-status is redundant.

> 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?

A few extra files (under 10): wouldn't hurt a bit
The 400 .o files that git-status currently reports: Pretty much
cripples git-status for the purpose of preparing the index for a
commit.

>
> I lost you here. Why do you need the output of git-status  to  commit
> changes?

As discussed above, git-commit needs to be explicitly told which files
to commit.  By default, it commits nothing.  (as opposed to the
cg-commit default, which is to commit everything).

>
> > 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.

Thanks!  :-)

> > 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.

Hehehe, I probably owe you like 10 beers to offset some of the debates
I've instigated lately.  Are you going to be able to make it to OLS
this year?

Cheers,
g.

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

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

[Stefan Roese]

On Tuesday 27 February 2007 07:42, Grant Likely wrote:
> > > 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?
>
> No it's not different.  Your right.  New files must always be
> explicitly added.

If I understand it correctly, then the main usage difference between you (core 
git users) and Wolfgang (and me by the way) cogito users, is the handling of 
new files. With git-update-index all new files are added to the index 
automatically (without parameters), right? Using cg-add you have to either 
name the files explicitly you want to add, or use the "-a" option.

Even as cogito user (and I'm thinking again about switching to using the core 
git commands more and more), I vote for adding this .gitignore file, since it 
really seems to be needed in this workflow. And we want to make it as easy 
for most of the people to work on this project.

> > 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.
>
> Hehehe, I probably owe you like 10 beers to offset some of the debates
> I've instigated lately.  Are you going to be able to make it to OLS
> this year?

Could be that I will make it this year. Perhaps I can act here as 
Wolfgangs "substitute"? ;-)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

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

[Grant Likely]

On 2/27/07, Stefan Roese <sr@denx.de> wrote:
> On Tuesday 27 February 2007 07:42, Grant Likely wrote:
> >
> > No it's not different.  Your right.  New files must always be
> > explicitly added.
>
> If I understand it correctly, then the main usage difference between you (core
> git users) and Wolfgang (and me by the way) cogito users, is the handling of
> new files. With git-update-index all new files are added to the index
> automatically (without parameters), right? Using cg-add you have to either
> name the files explicitly you want to add, or use the "-a" option.

Actually, no.  I probably didn't explain well.

Cogito and core git handle new files in exactly the same way:  they
must be added explicitly (with cg-add, git-update-index --add, or
git-add).  It's *changed* files that are handled differently.

By default, cg-commit assumes that you want to commit *all* file
changes, and gives you the option to cull the list.

By default, git-commit assumes that you want to commit *no* file
changes, and gives you the tools to add files to the commit list (with
'git-update-index', or 'git-commit <filelist>').  Hence git-status
gets called a really large number of times.

> Even as cogito user (and I'm thinking again about switching to using the core
> git commands more and more), I vote for adding this .gitignore file, since it
> really seems to be needed in this workflow. And we want to make it as easy
> for most of the people to work on this project.

:-)

> > > 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.
> >
> > Hehehe, I probably owe you like 10 beers to offset some of the debates
> > I've instigated lately.  Are you going to be able to make it to OLS
> > this year?
>
> Could be that I will make it this year. Perhaps I can act here as
> Wolfgangs "substitute"? ;-)

You'll have to fight him for it; but I probably owe you a beer or
three also.  :)

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

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

[Stefan Roese]

On Tuesday 27 February 2007 08:15, Grant Likely wrote:
> > If I understand it correctly, then the main usage difference between you
> > (core git users) and Wolfgang (and me by the way) cogito users, is the
> > handling of new files. With git-update-index all new files are added to
> > the index automatically (without parameters), right? Using cg-add you
> > have to either name the files explicitly you want to add, or use the "-a"
> > option.
>
> Actually, no.  I probably didn't explain well.
>
> Cogito and core git handle new files in exactly the same way:  they
> must be added explicitly (with cg-add, git-update-index --add, or
> git-add).

Just for the record:

git-add without parameters will automatically add all non-ignored files to the 
index. That seems to be the workflow at least Andy is using.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

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

[Grant Likely]

On 2/27/07, Stefan Roese <sr@denx.de> wrote:
> On Tuesday 27 February 2007 08:15, Grant Likely wrote:
> > Cogito and core git handle new files in exactly the same way:  they
> > must be added explicitly (with cg-add, git-update-index --add, or
> > git-add).
>
> Just for the record:
>
> git-add without parameters will automatically add all non-ignored files to the
> index. That seems to be the workflow at least Andy is using.

Yup; I was wrong on this point.

g.

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

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

[Timur Tabi]

Stefan Roese wrote:
> With git-update-index all new files are added to the index 
> automatically (without parameters), right?

No.  You have to manually specify all file names with git-update-index. 
  Fortunately, there's a shortcut:

git-update-index `git-diff-index --name-only -p HEAD`

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

[Kumar Gala]

On Feb 27, 2007, at 8:56 AM, Timur Tabi wrote:

> Stefan Roese wrote:
>> With git-update-index all new files are added to the index
>> automatically (without parameters), right?
>
> No.  You have to manually specify all file names with git-update- 
> index.
>   Fortunately, there's a shortcut:
>
> git-update-index `git-diff-index --name-only -p HEAD`

I think git-add in 1.5 is suppose to clean all this up and be the  
single front end to get items into the index (either new files or  
existing).

- k

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

[Haavard Skinnemoen]

On 2/27/07, Timur Tabi <timur@freescale.com> wrote:
> Stefan Roese wrote:
> > With git-update-index all new files are added to the index
> > automatically (without parameters), right?
>
> No.  You have to manually specify all file names with git-update-index.
>   Fortunately, there's a shortcut:
>
> git-update-index `git-diff-index --name-only -p HEAD`

An even easier shortcut is "git commit -a", which will update the
index for all files before committing.

Haavard

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

[Grant Likely]

From: Grant Likely <grant.likely@secretlab.ca>

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 .gitignore          |   14 ++++++++++++++
 examples/.gitignore |    5 +++++
 include/.gitignore  |    6 ++++++
 tools/.gitignore    |    9 +++++++++
 4 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..9d9f7aa
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,14 @@
+*.rej
+*.orig
+*.a
+*.o
+*.depend
+System.map
+/u-boot
+/u-boot.map
+/u-boot.bin
+/u-boot.srec
+/LOG
+/errlog
+/reloc_off
+
diff --git a/examples/.gitignore b/examples/.gitignore
new file mode 100644
index 0000000..f547024
--- /dev/null
+++ b/examples/.gitignore
@@ -0,0 +1,5 @@
+/hello_world
+/interrupt
+/sched
+*.bin
+*.srec
diff --git a/include/.gitignore b/include/.gitignore
new file mode 100644
index 0000000..d8fda80
--- /dev/null
+++ b/include/.gitignore
@@ -0,0 +1,6 @@
+/asm
+/asm-ppc/arch
+/bmp_logo.h
+/config.h
+/config.mk
+/version_autogenerated.h
diff --git a/tools/.gitignore b/tools/.gitignore
new file mode 100644
index 0000000..c33679a
--- /dev/null
+++ b/tools/.gitignore
@@ -0,0 +1,9 @@
+/bmp_logo
+/crc32.c
+/envcrc
+/environment.c
+/gen_eth_addr
+/img2srec
+/mkimage
+/sha1.c
+/ubsha1