From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: [RFC] So... are people happy with commit/status -v?
Date: Wed, 15 Feb 2006 01:41:11 -0800 [thread overview]
Message-ID: <7vvevhj6x4.fsf@assigned-by-dhcp.cox.net> (raw)
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?
next reply other threads:[~2006-02-15 9:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 9:41 Junio C Hamano [this message]
2006-02-19 15:18 ` [RFC] So... are people happy with commit/status -v? Christian Biesinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vvevhj6x4.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).