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

On 29 January 2010 17:44, Junio C Hamano [off-list ref] wrote:

Jonathan del Strother [off-list ref] writes:

quoted

Heya,

git-stash in v1.7.0-rc0 gives me several hundred lines of :
The previous build I was using -
5b15950ac414a8a2d4f5eb480712abcc9fe176d2 from Jan 19th - didn't show
this problem.  Want me to try and bisect further?

Yes, please.

ee6fc514f2df821c2719cc49499a56ef2fb136b0 (Show submodules as modified
when they contain a dirty work tree) seems to be the first bad commit.

Am 30.01.2010 01:46, schrieb Jonathan del Strother:

On 29 January 2010 17:44, Junio C Hamano [off-list ref] wrote:

quoted

Jonathan del Strother [off-list ref] writes:

quoted

Heya,

git-stash in v1.7.0-rc0 gives me several hundred lines of :
The previous build I was using -
5b15950ac414a8a2d4f5eb480712abcc9fe176d2 from Jan 19th - didn't show
this problem.  Want me to try and bisect further?

Yes, please.

ee6fc514f2df821c2719cc49499a56ef2fb136b0 (Show submodules as modified
when they contain a dirty work tree) seems to be the first bad commit.

Thanks for pinning that down.

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)?

(If you want to keep some information off the list, you can mail me
privately)

On 30 January 2010 12:31, Jens Lehmann [off-list ref] wrote:

Am 30.01.2010 01:46, schrieb Jonathan del Strother:

quoted

On 29 January 2010 17:44, Junio C Hamano [off-list ref] wrote:

quoted

Jonathan del Strother [off-list ref] writes:

quoted

Heya,

git-stash in v1.7.0-rc0 gives me several hundred lines of :
The previous build I was using -
5b15950ac414a8a2d4f5eb480712abcc9fe176d2 from Jan 19th - didn't show
this problem.  Want me to try and bisect further?

Yes, please.

ee6fc514f2df821c2719cc49499a56ef2fb136b0 (Show submodules as modified
when they contain a dirty work tree) seems to be the first bad commit.

Thanks for pinning that down.

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?

Am 30.01.2010 14:23, schrieb Jonathan del Strother:

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?


The error message "error: unable to find <sha1>" is only generated in
sha1_loose_object_info() when map_sha1_file() fails. Its single caller
being sha1_object_info(), which is called by many git commands. Does
that ring a bell for somebody?

On 30 January 2010 14:10, Jens Lehmann [off-list ref] wrote:

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.

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"