[PATCH] refresh-index: fix bitmask assignment

Subsystems: the rest

DORMANTno replies

6 messages, 4 authors, 2016-06-15 · open the first message on its own page

[PATCH] refresh-index: fix bitmask assignment

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:58

5fdeacb (Teach update-index about --ignore-submodules, 2008-05-14) added a
new refresh option flag but did not assign a unique bit for it correctly,
and broke "update-index --ignore-missing".

This should fix it.

Signed-off-by: Junio C Hamano <redacted>
---
 * The fact that it took this long for anybody to notice the breakage
   probably means that the "--ignore-missing" option in particular but the
   ability for plumbing to allow scripting in general is not utilized by
   as many people as the design initially envisioned.

 cache.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index ca382d4..9735b66 100644
--- a/cache.h
+++ b/cache.h
@@ -396,7 +396,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
 #define REFRESH_UNMERGED	0x0002	/* allow unmerged */
 #define REFRESH_QUIET		0x0004	/* be quiet about it */
 #define REFRESH_IGNORE_MISSING	0x0008	/* ignore non-existent */
-#define REFRESH_IGNORE_SUBMODULES	0x0008	/* ignore submodules */
+#define REFRESH_IGNORE_SUBMODULES	0x0010	/* ignore submodules */
 extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
 
 struct lock_file {
-- 
1.5.6.4.570.g052e6

[RFC variant 1 of 2] "needs update" considered harmful

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:58

"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.

Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal.  After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.

I prepared two alternatives to solve this.  Both aim to reword the message
to more neutral "locally modified".

This patch is a more intrusive variant that changes the message for only
Porcelain commands ("add" and "reset") while keeping the plumbing
"update-index" intact.

Signed-off-by: Junio C Hamano <redacted>
---
 builtin-add.c    |    3 ++-
 builtin-reset.c  |    2 +-
 cache.h          |    1 +
 read-cache.c     |    5 ++++-
 t/t7102-reset.sh |    2 +-
 5 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 9930cf5..5ffe4da 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -142,7 +142,8 @@ static void refresh(int verbose, const char **pathspec)
 	seen = xcalloc(specs, 1);
 	if (read_cache() < 0)
 		die("index file corrupt");
-	refresh_index(&the_index, verbose ? 0 : REFRESH_QUIET, pathspec, seen);
+	refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
+		      pathspec, seen);
 	for (i = 0; i < specs; i++) {
 		if (!seen[i])
 			die("pathspec '%s' did not match any files", pathspec[i]);
diff --git a/builtin-reset.c b/builtin-reset.c
index a032169..98dbe1c 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -96,7 +96,7 @@ static int update_index_refresh(int fd, struct lock_file *index_lock)
 
 	if (read_cache() < 0)
 		return error("Could not read index");
-	result = refresh_cache(0) ? 1 : 0;
+	result = refresh_cache(REFRESH_SAY_CHANGED) ? 1 : 0;
 	if (write_cache(fd, active_cache, active_nr) ||
 			commit_locked_index(index_lock))
 		return error ("Could not refresh index");
diff --git a/cache.h b/cache.h
index 9735b66..da87c72 100644
--- a/cache.h
+++ b/cache.h
@@ -397,6 +397,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
 #define REFRESH_QUIET		0x0004	/* be quiet about it */
 #define REFRESH_IGNORE_MISSING	0x0008	/* ignore non-existent */
 #define REFRESH_IGNORE_SUBMODULES	0x0010	/* ignore submodules */
+#define REFRESH_SAY_CHANGED	0x0020	/* say "changed" not "needs update" */
 extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
 
 struct lock_file {
diff --git a/read-cache.c b/read-cache.c
index f83de8c..9839362 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -980,7 +980,10 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 	int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
 	int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
 	unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
+	const char *needs_update_message;
 
+	needs_update_message = ((flags & REFRESH_SAY_CHANGED)
+				? "locally modified" : "needs update");
 	for (i = 0; i < istate->cache_nr; i++) {
 		struct cache_entry *ce, *new;
 		int cache_errno = 0;
@@ -1019,7 +1022,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 			}
 			if (quiet)
 				continue;
-			printf("%s: needs update\n", ce->name);
+			printf("%s: %s\n", ce->name, needs_update_message);
 			has_errors = 1;
 			continue;
 		}
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 96d1508..da4b142 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -419,7 +419,7 @@ test_expect_success 'resetting an unmodified path is a no-op' '
 '
 
 cat > expect << EOF
-file2: needs update
+file2: locally modified
 EOF
 
 test_expect_success '--mixed refreshes the index' '

[RFC variant 2 of 2] "needs update" considered harmful

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:58

"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.

Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal.  After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.

I prepared two alternatives to solve this.  Both aim to reword the message
to more neutral "locally modified".

This patch is a more straightforward variant that changes the message not
only for Porcelain commands ("add" and "reset") but also changes the
output from the plumbing command "update-index".

Signed-off-by: Junio C Hamano <redacted>
---
 read-cache.c                           |    2 +-
 t/t2103-update-index-ignore-missing.sh |    2 +-
 t/t7102-reset.sh                       |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index f83de8c..d37aec0 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1019,7 +1019,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 			}
 			if (quiet)
 				continue;
-			printf("%s: needs update\n", ce->name);
+			printf("%s: locally modified\n", ce->name);
 			has_errors = 1;
 			continue;
 		}
diff --git a/t/t2103-update-index-ignore-missing.sh b/t/t2103-update-index-ignore-missing.sh
index 4fbf855..f775acb 100755
--- a/t/t2103-update-index-ignore-missing.sh
+++ b/t/t2103-update-index-ignore-missing.sh
@@ -62,7 +62,7 @@ test_expect_success '--unmerged --refresh' '
 	test_must_fail git update-index --refresh &&
 	git update-index --unmerged --refresh &&
 	echo 2 >two &&
-	echo "two: needs update" >expect &&
+	echo "two: locally modified" >expect &&
 	test_must_fail git update-index --unmerged --refresh >actual &&
 	test_cmp expect actual
 '
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 96d1508..da4b142 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -419,7 +419,7 @@ test_expect_success 'resetting an unmodified path is a no-op' '
 '
 
 cat > expect << EOF
-file2: needs update
+file2: locally modified
 EOF
 
 test_expect_success '--mixed refreshes the index' '
-- 
1.5.6.4.570.g052e6

Re: [RFC variant 2 of 2] "needs update" considered harmful

From: Petr Baudis <hidden>
Date: 2016-06-15 22:44:58

On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.

Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal.  After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.

I prepared two alternatives to solve this.  Both aim to reword the message
to more neutral "locally modified".

This patch is a more straightforward variant that changes the message not
only for Porcelain commands ("add" and "reset") but also changes the
output from the plumbing command "update-index".

Signed-off-by: Junio C Hamano <redacted>
I believe this is a good thing. Scripts need to be modified for the
reorganization anyway, and I'm not sure if there are any actually
depening on this particular string. I think having inconsistent error
messaging is worse in long term.

FWIW, looking at Cogito,

	cg-Xlib: git-update-index --refresh | sed 's/needs update$/locally modified/'

is the only reference to this. ;-)

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

Re: [RFC variant 2 of 2] "needs update" considered harmful

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:44:58

Hi,

On Sun, 20 Jul 2008, Petr Baudis wrote:
Scripts need to be modified for the reorganization anyway,
No.  They do not, if the 1st variant is applied.
and I'm not sure if there are any actually depening on this particular 
string.
That is the question, isn't it?  You would never know.  Many people, 
strange as it sounds, do not write to this list when they encounter 
problems with Git.  They vent on their blogs, not giving us a chance, and 
other people comment "Me too"s.

One of the most important features of Git used to be its scriptability, 
and I think that many hackers just love Git for it, even new hackers.

So it is probably not unheard of that someone wrote an update hook or a 
cronjob using the output of "update-index --refresh".

But those people are probably not on this list, or not following every 
thread, or they even forgot how/that they implemented such a hook/cronjob.

Ergo: we would not know if scripts break.  Until it is too late.

Ciao,
Dscho

Re: [RFC variant 2 of 2] "needs update" considered harmful

From: André Goddard Rosa <hidden>
Date: 2016-06-15 22:44:58

On Sun, Jul 20, 2008 at 8:29 AM, Petr Baudis [off-list ref] wrote:
On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
quoted
"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.

Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal.  After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.

I prepared two alternatives to solve this.  Both aim to reword the message
to more neutral "locally modified".

This patch is a more straightforward variant that changes the message not
only for Porcelain commands ("add" and "reset") but also changes the
output from the plumbing command "update-index".

Signed-off-by: Junio C Hamano <redacted>
I believe this is a good thing. Scripts need to be modified for the
Thanks for doing that. I hope this goes mainline soon.

-- 
[]s,
André Goddard
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help