Väinö Järvelä <v@xxxxxxxxxx> writes: > On Aug 25, 2007, at 01:33, Alex Riesen wrote: > >>> That line will result in duplicate entries, if files are staged, and >>> the output of git-status is neater (but longer) in my opinion. >> >> That is because it _is_ two times different: between working directory >> and the index, and between index and HEAD. git-status _will_ show you >> the same for the same reason. >> >> Besides, why do you want to hide this "duplication"? It shows how the >> matters really are. The whole argument of "two entries are dups" is showing that you might be repeating past mistake of Cogito where hiding the index from the user would make git somehow more user friendly. It was a laudable attempt, but did not really fly well in practice. But the --only-tracked has a bigger issue. Letting the user know about untracked files that should be tracked is really important to avoid mistakes. If the status output is so cluttered for you to want an option like this, it is hard to spot such a file. I do not think disabling the untracked output is a solution to the real problem. You earlier said that you may not be able to add certain untracked files to .gitignore --- can you elaborate? I do not think the reason is you are too lazy to do so, nor you are incompetent to understand the ignore pattern. There is something else, which might show that the current ignore facility needs to become easier to use for _your_ use of _your_ repository. I still do not see in the thread what it is yet. For example, maybe the reason why you do not want to place them in the .gitignore file is because the clutter are your random wip temporary files, whose naming convention is personal to you and does not apply to others. Naturally, you do not want to put such patterns to the tracked .gitignore file, which is for all participants of the project. In such a case, you would want a facility to allow you to specify your personal ignore patterns that is used in addition to the .gitignore file [*1*]. The particular example use case above is covered by an existing facility, but there might be other valid reasons that you cannot express your ignore patterns easily with existing facilities. In which case, we need to know that, so that you and people in similar situation as you are in can express the necessary ignore patterns more easily, in order to reduce the risk of forgetting to add new files. [Footnote] *1* Which already exists. Put them in .git/info/exclude file. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
