From: Sergio Callegari <sergio.callegari@gmail.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Possible bug with git status in 1.7.0
Date: Fri, 19 Feb 2010 17:42:35 +0100 [thread overview]
Message-ID: <4B7EBF7B.3090703@gmail.com> (raw)
In-Reply-To: <4B7C5711.8060708@web.de>
Jens Lehmann wrote:
>> The wording of the reminder is a bit unclear, though. Suppose that the
>> problem is with submodule "mod".
>>
>> What you get from git status is a notice that something is modified but
>> not updated, with the following suggestion
>>
>> # Changed but not
>> updated:
>>
>> # (use "git add <file>..." to update what will be committed)
>>
>> and then the notice about what is in fact modified
>>
>> # modified: mod
>>
>>
>> So the first problem is that now git status provides a hint that may be
>> confusing. One gets the idea that he needs to add mod (to store a new
>> commit id in the index) and not to add a file in mod.
>>
>
> That is a very valid point. I am currently working on git status being
> more explicit about the type of modification. I just asked for comments
> on this issue on February 14th in the thread titled "[PATCH/RFC] git
> diff --submodule: Show detailed dirty status of submodules" (Gmane is
> down for me right now, so i am sorry: no link today).
>
> The changes i have in mind for git status would also include giving a
> better hint, as you rightfully pointed out.
>
Missed that, thanks for pointing out
>> As a second issue, note that mod is in fact not really modified being that
>>
>> 1) no tracked file in it has been modified.
>> 2) no new commit has been made
>>
>> and the fact is that from git status I cannot recognize anymore if the
>> module is really changed (the module commit id has changed) or has
>> uncommited changes (some tracked file is changed) or is merely polluted
>> by untracked files, so now I always need to explore the submodule.
>>
>> It is true that this can be solved putting more stuff in .gitignore.
>> However, it might be a matter of taste, but I do not like putting all
>> byproducts in .gitignore because not doing so allows me to
>> differentiate between
>>
>> - files that are just garbage
>> - files that are not tracked but may be still precious
>>
>> and selectively clean either category using the -x or -X options of git
>> clean.
>>
>>
>> So, it would be nice to improve the feedback of git status for this
>> particular case and possibly have an option to avoid status being so
>> wordy about untracked files.
>>
>
> So i assume that my proposal to explicitly state that a submodule has
> new commits, modified files and/or untracked files would solve your
> woes?
>
Yes! My ideal behavior (if I am not asking too much) would be trying to
keep the status as little wordy as possible (1 line per submodule)
e.g. something like
# modified module (commit id): mod1
# modified module (modified files): mod2
# modified module (untracked files): mod3
# modified module (modified files, untracked files): mod4
# modified module (commit id, modified files, untracked files): mod5
and with an option to avoid complaining about untracked files in the
submodules
e.g. if option is not selected, entry about mod3 would not be printed at
all.
And of course it would be useful to modify the suggestions into
something like
# (use "git add <file>/<submodule>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (enter modules that have modified/untracked files to perform actions on them)
Thanks,
Sergio
next prev parent reply other threads:[~2010-02-19 16:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-17 19:14 Possible bug with git status in 1.7.0 Sergio
2010-02-17 19:21 ` Junio C Hamano
2010-02-17 19:52 ` Sergio Callegari
2010-02-17 20:52 ` Jens Lehmann
2010-02-19 16:42 ` Sergio Callegari [this message]
2010-02-19 20:55 ` Jens Lehmann
2010-02-20 11:05 ` Sergio Callegari
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=4B7EBF7B.3090703@gmail.com \
--to=sergio.callegari@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).