From: Jon Loeliger <jdl@jdl.com>
To: git@vger.kernel.org
Subject: [RFC] Silent File Mods Being Committed
Date: Wed, 22 Mar 2006 22:04:32 -0600 [thread overview]
Message-ID: <E1FMH3o-0001B5-Dw@jdl.com> (raw)
Folks,
I sort of got blindsided by committing (accidental) mode
changes on a file that was also textually changed. Because
it was textually changed, I happily expected 'git status'
to show it as modified and subsequently 'git commit'-ed it.
Only after I 'git diff'-ed it later did I see that there
was also a mode change on the file! Argh!
Secondarily, I think that the invisible file changes like
this caused an eariler (yesterday-ish) confusion where an
index looked clean, but was dirty due to stat issues and
poor users (me) couldn't quite see why.
Originally, I was going to propose that git-ls-files be modified
such that the mode and stat changes that ce_modified() correctly
identifies as changing are somehow translated into output that
"git status" shows the user per-file _in_addition_ to the normal
"is modified" header. So I did this mod:
diff --git a/ls-files.c b/ls-files.c
index df25c8c..3e7e55d 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -450,7 +450,7 @@ static void show_killed_files(void)
}
}
-static void show_ce_entry(const char *tag, struct cache_entry *ce)
+static void show_ce_entry(const char *tag, struct cache_entry *ce, int changed)
{
int len = prefix_len;
int offset = prefix_offset;
@@ -482,6 +482,14 @@ static void show_ce_entry(const char *ta
fputs(tag, stdout);
write_name_quoted("", 0, ce->name + offset,
line_terminator, stdout);
+ if (changed & (MTIME_CHANGED | CTIME_CHANGED)) {
+ putchar(' ');
+ putchar('T');
+ }
+ if (changed & MODE_CHANGED) {
+ putchar(' ');
+ putchar('M');
+ }
putchar(line_terminator);
}
else {
@@ -541,7 +549,7 @@ static void show_files(void)
continue;
if (show_unmerged && !ce_stage(ce))
continue;
- show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, ce);
+ show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, ce, 0);
}
}
if (show_deleted | show_modified) {
@@ -553,9 +561,13 @@ static void show_files(void)
continue;
err = lstat(ce->name, &st);
if (show_deleted && err)
- show_ce_entry(tag_removed, ce);
- if (show_modified && ce_modified(ce, &st, 0))
- show_ce_entry(tag_modified, ce);
+ show_ce_entry(tag_removed, ce, 0);
+ if (show_modified) {
+ int changed = ce_modified(ce, &st, 0);
+ if (changed)
+ show_ce_entry(tag_modified,
+ ce, changed);
+ }
}
}
}
And with that, "git ls-file -m" showed a trailing T or M to
indicate a "time" or a "mode" change happened on each file.
However, 'git status' didn't show that output....
And that is because it is driven by the diffcore instead!
So I _think_ diff_resolve_rename_copy() has to be consulted
to get that DIFF_STATUS_MODIFIED indicator. Except that it is
shared with the SHA1 compare too:
else if (memcmp(p->one->sha1, p->two->sha1, 20) ||
p->one->mode != p->two->mode)
p->status = DIFF_STATUS_MODIFIED;
But I haven't tracked it back to see how to propagate that
status back up to show_modified() in diff-files.c yet...
Maybe there is an easier way...?
jdl
next reply other threads:[~2006-03-23 4:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 4:04 Jon Loeliger [this message]
2006-03-23 5:13 ` [RFC] Silent File Mods Being Committed Junio C Hamano
2006-03-23 21:47 ` Petr Baudis
2006-03-23 23:32 ` Junio C Hamano
2006-03-23 23:32 ` Junio C Hamano
2006-03-24 1:12 ` Petr Baudis
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=E1FMH3o-0001B5-Dw@jdl.com \
--to=jdl@jdl.com \
--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).