patch, 2 partsRe: [PATCH 1/2] Add "--only-untracked" flag to status commands.

Väinö Järvelä, Thu, Aug 23, 2007 21:58:31 +0200:

"git diff -r --name-status; git diff --cached -r --name-status" is not enough?

On Aug 23, 2007, at 23:32, 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.

""" M Makefile M Makefile """ vs. """ # On branch entity_class # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: Makefile # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: Makefile # # Untracked files were filtered by "--only-tracked" """

Sure you could remove duplicate entries with "sort|uniq", or something, but just running "git status --only-tracked", is cleaner, and more user friendly.

The way I see the flag used is: A user runs "git status", sees that there is too much untracked files and not enough scrollback, so he runs "git status --only-tracked" to filter the results.

-- Väinö

Väinö Järvelä wrote:

I like it.

Jakub Narebski wrote:

Ack on that. It's happened to me a bunch of times, usually followed by <identical command> | sed '/Untracked/,$d'

Väinö Järvelä <v@pp.inet.fi> writes:

Why?

Just set up .gitignore once then (1) you do not have to worry about them ever again, and (2) you _will_ still be able to notice if you accidentally added more cruft, or more importantly, if you forgot to tell an important file to git.

I think the latter is more important point. If you train a naive user to use --only-tracked to ignore "Untracked" list, you are doing him or her a great disservice. Mistake to forget "git add" a new file before commiting will bound to happen.

On Aug 24, 2007, at 10:46, Junio C Hamano wrote:

I also think that maintaining a proper .gitignore is imporant, and more productive than using --only-tracked instead. But when I have cruft that can't be put in .gitignore, or it would ignore files that are supposed to be shown and tracked, I use --only-tracked.

It's true though, that the user might forget to add a file if he always uses --only-tracked, that's why I added the note in the status that the untracked files were filtered out. The flag is supposed to be a helper for situations where .gitignore wouldn't work, not a way to work always. Maybe if this flag is accepted, the manual should say that in most cases it's better to use .gitignore.

-- Väinö

Hi,

On Fri, 24 Aug 2007, V?in? J?rvel wrote:

Would it not be better to imitate the "-x" and "-X" options of ls-files, then? You could achieve the effect you desire by "git status -x \*" then.

Ciao, Dscho

On Aug 24, 2007, at 12:55, Johannes Schindelin wrote:

I haven't used that option, do I understand correctly, that with that option, you should provide another exclusion file? That would remove the dynamic ability of --only-tracked.

-- Väinö

Hi,

On Fri, 24 Aug 2007, V?in? J?rvel wrote:

-X takes a filename, -x a pattern.

Hth, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

That's equivalent feature-wise, but a bit slower performance-wise (the proposed patch skips file listing totally). But since the use-case for it is not the common case, it probably doesn't matter (and in case, it's possible to hardcode an optimisation if the pattern is "*").

Junio C Hamano wrote:

If it won't acquire short version, nor tab completion, mosts users when confronted with such a mothful of option-name wouldn't use it unless necessary, I think...

Jakub Narebski <jnareb@gmail.com> writes:

Yeah, but if we accept that --only-tracked patch, I know from the past experience that people would send a "shorter synonym" patch, arguing that the capability is already there.

I really think we should resist temptation to add misfeatures that would encourage bad workflows and new user mistakes.

On Aug 25, 2007, at 02:06, Junio C Hamano wrote:

I really do think that there is a use case for this patch. But this assumes that the testing is done in the source tree, but maybe that in itself can be considered a bad workflow.

An example would be in game development, where I have a directory full of images, and I wish to try out different images in the place of one. I usually create different versions of the images with different names, filling up the image directory under VCS. This usually results in tens of images that will not be tracked (unless they replace the original images), but because of my bad habit of creating the files inside the source tree, which results in a little bit faster workflow for me. With all these untracked files, git- status will obscure the actual contents of the status I wish to see.

I cannot put those files inside .gitignore, as there would have to be some kind of exclusion pattern for them that won't match the tracked files. Sure I could prefix all of my test images with 'test_' or something similiar. Or I could just add '*' to .gitignore, and force adds. The latter seems like a bad habit for me, the other seems to include a lot of manual labor, especially when someone else sends test files for me.

So the end result for me is, that it's easier to use --only-tracked

Fringe case? Maybe. Workflow could be better, sure. But --only- tracked even works for the less technical folk, which might be scared of forcing the changes, or annoyed by having to name the files with a magic prefix.

-- Väinö

Hi,

On Sat, 25 Aug 2007, V?in? J?rvel wrote:

I have a similar use case, funnily enough also with images. I created a tmp/ directory and put the images there, cp'ing or ln -s'ing the current one into the cwd. Then, "/tmp/" is put into .gitignore and all is well.

Especially the fact that I no longer forget to check in the images that I _do_ want to track.

Ciao, Dscho

Väinö Järvelä, Fri, Aug 24, 2007 08:35:13 +0200:

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.

Besides, it looks like you are using "friendly" where you actually wanted to say "I consider you too dumb to know what happens". Someone may feel offended

On Aug 25, 2007, at 01:33, Alex Riesen wrote:

git status --only-tracked, does not hide the fact that there are files staged for commit, and modified files relative to the index. The difference is, that it shows them in a clean way. Sure you could make a script like:

echo "Changes to be committed:"; git diff --cached -r --name-status; echo "Changed but not updates:"; git diff -r --name-status

But that is quite long, for a quick look at the state, without any untracked files.

I don't see where I consider users dumb, but hey, I'm sorry if I made someone feel offended.

-- Väinö

Väinö Järvelä <v@pp.inet.fi> writes:

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.