"sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
I'm seeing what might be a bug that was introduced in git 1.7.12 (also observed in 1.8.1.2). If not a bug, it's a changed behavior from previous versions that I don't understand. Here's the scenario: * I have a remote repo containing a pointer to a submodule. * Developer A and Developer B clone this repo, and both make a commit to first the submodule, and then the parent repo, changing some files and also the submodule pointer at the same time. * Developer A pushes his changes to both the submodule and the parent module to the shared remote * Developer B either does a "git pull --rebase" or a "git fetch && git rebase origin/master" Results: When applying Developer B's changes on top of origin/master, the following messages are observed: "fatal: sha1 information is lacking or useless (sub). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge." Furthermore, an immediate "git status" reports "all conflicts fixed", does not report the submodule pointer as unmerged, and the changes to the other files in the parent module made by Developer B are not applied. Expected Results: Similar to how 1.7.12.1 behaves. No mention of sha1 information or blobs being lacking. "git status" should report the submodule pointer and any other changed files as being unmerged. Conflicting changes should not be lost. I'm witnessing this behavior on OS X 10.8.2 with git versions 1.7.12, 1.7.12.1, and 1.8.1.2, installed via homebrew. I do not see this behavior in 1.7.11.5 or any of the 8 previous versions I've tried back to 1.7.4.1. Workaround: Using an interactive rebase ("git fetch && git rebase -i origin/master") with no changes made to the commit list seems to sidestep this behavior. Thanks in advance for any help with this. Reproduce script: Execute the following, then "cd local-b; git pull --rebase" #!/bin/sh set -e -v BASEDIR=`pwd` # Make bare remote repos mkdir remotes pushd remotes git init --bare super.git git init --bare sub.git popd # Initialize the submodule repo git clone --no-hardlinks remotes/sub.git sub pushd sub echo subfile > subfile git add subfile git commit -m initial-submodule git push origin master popd rm -Rf sub # Clone into local-a and initialize supermodule repo git clone --no-hardlinks remotes/super.git local-a pushd local-a git submodule add $BASEDIR/remotes/sub.git sub echo file > file git add sub file git commit -m initial git push origin master popd # Clone into local-b git clone --no-hardlinks remotes/super.git local-b pushd local-b git submodule init && git submodule update popd # Make a change to supermodule file and submodule pointer from local-a and push to remote pushd local-a cd sub echo subfile changed from local-a > subfile git add subfile git commit -m subfile-changed-from-local-a git push cd .. echo file changed from local-a > file git add sub file git commit -m change-from-local-a git push popd # Make a conflicting change to both supermodule file and submodule pointer from local-b pushd local-b cd sub echo subfile changed from local-b > subfile git add subfile git commit -m subfile-changed-from-local-b cd .. echo file changed from local-b > file git add sub file git commit -m change-from-local-b popd -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
Hi, On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: > I'm seeing what might be a bug that was introduced in git 1.7.12 (also > observed in 1.8.1.2). If not a bug, it's a changed behavior from > previous versions that I don't understand. > > Here's the scenario: > * I have a remote repo containing a pointer to a submodule. > * Developer A and Developer B clone this repo, and both make a commit > to first the submodule, and then the parent repo, changing some files > and also the submodule pointer at the same time. > * Developer A pushes his changes to both the submodule and the parent > module to the shared remote > * Developer B either does a "git pull --rebase" or a "git fetch && git > rebase origin/master" Thanks for the detailed bug report and the demo script. I can reproduce the behavior here and will have a look into it. The submodule should be marked as conflict. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
Heiko Voigt writes: > Maybe Martin or Junio immediately see whats going wrong here? I would > need to further dig into the git-am code to find out how to fix it. "am -3" has never worked on a patch that describes changes to any non-blobs; the underlyihng "apply --fake-ancestor" is not prepared to see anything other than blobs. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
Heiko Voigt writes: > Maybe Martin or Junio immediately see whats going wrong here? I would > need to further dig into the git-am code to find out how to fix it. Thanks. I think the minimum fix is this, but there are some nits to pick around this area as well. diff --git b/git-am.sh a/git-am.sh index b4d95f5..202130f 100755 --- b/git-am.sh +++ a/git-am.sh @@ -664,7 +664,7 @@ do sed -e '1,/^$/d' >"$dotest/msg-clean" echo "$commit" >"$dotest/original-commit" get_author_ident_from_commit "$commit" >"$dotest/author-script" - git diff-tree --root --binary "$commit" >"$dotest/patch" + git diff-tree --root --binary --full-index "$commit" >"$dotest/patch" else git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \ <"$dotest/$msgnum" >"$dotest/info" || -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
Hi, On Wed, Jan 30, 2013 at 10:56:15PM +0100, Heiko Voigt wrote: > On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: > > I'm seeing what might be a bug that was introduced in git 1.7.12 (also > > observed in 1.8.1.2). If not a bug, it's a changed behavior from > > previous versions that I don't understand. > > > > Here's the scenario: > > * I have a remote repo containing a pointer to a submodule. > > * Developer A and Developer B clone this repo, and both make a commit > > to first the submodule, and then the parent repo, changing some files > > and also the submodule pointer at the same time. > > * Developer A pushes his changes to both the submodule and the parent > > module to the shared remote > > * Developer B either does a "git pull --rebase" or a "git fetch && git > > rebase origin/master" > > Thanks for the detailed bug report and the demo script. I can reproduce > the behavior here and will have a look into it. The submodule should be > marked as conflict. Bisect identified the following commit: commit a230949409f4a650c6a1a9a5879e2a8b993ba695 (HEAD) Author: Martin von Zweigbergk Date: Tue Jun 26 07:51:56 2012 -0700 am --rebasing: get patch body from commit, not from mailbox Rebasing a commit that contains a diff in the commit message results in a failure with output such as First, rewinding head to replay your work on top of it... Applying: My cool patch. fatal: sha1 information is lacking or useless (app/controllers/settings_controller.rb). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 My cool patch. The reason is that 'git rebase' without -p/-i/-m internally calls 'git format-patch' and pipes the output to 'git am --rebasing', which has no way of knowing what is a real patch and what is a commit message that contains a patch. Make 'git am' while in --rebasing mode get the patch body from the commit object instead of extracting it from the mailbox. Patch by Junio, test case and commit log message by Martin. Reported-by: anikey Helped-by: Junio C Hamano Signed-off-by: Martin von Zweigbergk Signed-off-by: Junio C Hamano Maybe Martin or Junio immediately see whats going wrong here? I would need to further dig into the git-am code to find out how to fix it. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html