Thread (6 messages) flat view 6 messages, 2 authors, 2016-06-15

Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash

From: Jens Lehmann <hidden>
Date: 2016-06-15 22:48:08
Subsystem: the rest · Maintainer: Linus Torvalds

Possibly related (same subject, not in this thread)

Am 30.01.2010 17:36, schrieb Jonathan del Strother:
On 30 January 2010 14:10, Jens Lehmann [off-list ref] wrote:
quoted
Am 30.01.2010 14:23, schrieb Jonathan del Strother:
quoted
On 30 January 2010 12:31, Jens Lehmann [off-list ref] wrote:
quoted
I assume you have one or more submodules, maybe even with untracked
or yet uncommitted modified files in your tree? If so, what does git
status say in the superproject and in the submodule(s)?
Yep, I have 10 submodules.  However, they're all completely clean with
no tracked or untracked changes shown in git status.  Anything else I
can investigate?
The change in behavior my patch introduced is that "git status" is
called inside each submodule. So i would expect getting the same
errors when using this command:
  git submodule foreach git status -s

It should just show
  Entering '<submodule 1>'
  Entering '<submodule 2>'
  Entering '<submodule 3>'
  Entering '<submodule 4>'
  Entering '<submodule 5>'
  Entering '<submodule 6>'
  Entering '<submodule 7>'
  Entering '<submodule 8>'
  Entering '<submodule 9>'
  Entering '<submodule 10>'
when the submodules are not dirty. What do you get?
Correct - I just get that output.
Hm, so nothing unusual there. I really wonder what is the problem here,
as calling "git status" inside the submodules works fine when issued via
"git submodule foreach", but not when done via run_command()!?

So i would like to ask some more questions:

- Under what operating system and on what filesystem is this happening?

- Is there anything unusual about your repo (e.g. using GIT_WORK_TREE
  or having the object database somewhere else that in .git in the
  superproject or any of the submodules)?

- You are just issuing a "git stash" to stash some changes in the
  superproject when that happens, right?

- The hashes that show up as "unable to find" are reachable via "git
  show" in the superproject, not in the submodules, right?

- Do these hashes have any relation to the contents you are stashing?

- The following patch should suppress (but not solve) this problem when
  applied to a version of git that contains
  4d34477f4c5dbebc55aa1362fd705440590a85f1 (git diff: Don't test
  submodule dirtiness with --ignore-submodules), e.g. current next.
  Could you please verify that?

---8<---
diff --git a/git-stash.sh b/git-stash.sh
index 3a0685f..e9b47b4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -105,7 +105,7 @@ create_stash () {
                w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
                die "Cannot save the current worktree state"

-               git diff-tree -p HEAD $w_tree > "$TMP-patch" &&
+               git diff-tree --ignore-submodules -p HEAD $w_tree > "$TMP-patch"
                test -s "$TMP-patch" ||
                die "No changes selected"
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help