threads / rfc / 3344

[RFC] So... are people happy with commit/status -v?

Subject: [RFC] So... are people happy with commit/status -v?

## tl;dr

2 messages between Feb 15, 2006 and Feb 19, 2006.

replies: 1people: 2as markdown or json

Junio C Hamano· Feb 15, 2006, 09:41 UTC · lore

I usually never do commits from a subdirectory, also I rarely do partial commits, so this is not a big issue to me, but are people happy with the current commit/status?

Regardless of where you started, status is a preview of the next commit with the same set of flags and arguments, so inherently that is a whole-tree operation.

One thing that _might_ be better, however, is to shorten certain parts of the status output when deliberately doing a partial commit. No matter where you are, "Updated but not checked in -- will commit" section should stay whole-tree, because it is _the_ preview of the next commit. However, "Changed but not updated" and "Untracked" section are different story.

When committing from a subdirectory with "git commit paths...", It is likely a user forgets about paths that are changed in the directory and forgets to list them on the command line, so the same directory and below should be listed, but it might not be needed to show files outside the current directory. "Untracked" files outside the current directory are even less interesting.

Even when committing from a subdirectory with "git commit", which is "commit the current index contents", the story is the same. The user could have forgot to add files in the same directory or below, but it is less likely that things outside current directory need to draw attention to prevent mistakes. "Untracked" outside are less interesting in this case as well.

In either partial or whole commit case, however, "Changed but not updated" part can be argued important and should be kept whole-tree (myself, I am slightly in favor of keeping this part whole-tree). After all, the user has changed files in the directory she happens to be in and outside, and reminding she has something outstanding while previewing the next commit would help prevent mistakes, whether that modified files are in the current directory or outside.

So, I'm wondering. I have a feeling that we might be better of limiting "Untracked" part to the current directory and below, while keeping "Updated -- will commit" and "Changed but not updated" part whole-tree. OTOH, I do not have strong need _myself_ to change the current setup.

Comments?  Opinions?
Christian Biesinger· Feb 19, 2006, 15:18 UTC · re: Junio C Hamano · lore

Re: [RFC] So... are people happy with commit/status -v?

Junio C Hamano wrote:
> I usually never do commits from a subdirectory, also I rarely do
> partial commits, so this is not a big issue to me, but are
> people happy with the current commit/status?

The part that annoyed me most was that "git-status --only ." completely ignores the specified path and tells me about the whole tree, rather than just the current directory and subdirectories. While I think I'd prefer it if the commands limited themselves to the current directory by default, I don't mind the current behaviour, as long as I still have the possibility to limit to the subdirectory.

← back to recent threads