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?

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.

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.

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

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.

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

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.

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

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