"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
