On Thu, May 11, 2023 at 11:02:44AM -0700, Dan Stromberg wrote: > I put together this little script to show what I'm seeing. > > The comments pretty much say what's going on. But in summary, how can I > get the merge conflict to go away? I'm surprised that the > add+commit+rebase --continue isn't enough to deal with that file.
Hi, Dan! I cannot reproduce it on Linux/amd64 with Git 2.39.2 - I have run the following commands in a freshly initialized repo: ----------------8<---------------- $ echo aaa > aaa.txt $ git add aaa.txt $ git commit -m 'aaa' [master (root-commit) 6928baf] aaa 1 file changed, 1 insertion(+) create mode 100644 aaa.txt $ git checkout -b foo Switched to a new branch 'foo' $ echo bbb > aaa.txt $ git add aaa.txt $ git commit -m bbb [foo b38fda8] bbb 1 file changed, 1 insertion(+), 1 deletion(-) $ git checkout - Switched to branch 'master' $ echo xyzzy > aaa.txt $ git add aaa.txt $ git commit -m xyzzy [master a819c04] xyzzy 1 file changed, 1 insertion(+), 1 deletion(-) $ git checkout - Switched to branch 'foo' $ git rebase master Auto-merging aaa.txt CONFLICT (content): Merge conflict in aaa.txt error: could not apply b38fda8... bbb hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply b38fda8... bbb $ git add aaa.txt $ git commit -m conflict [detached HEAD 59649d5] conflict 1 file changed, 4 insertions(+) $ git rebase --continue; echo $? Successfully rebased and updated refs/heads/foo. 0 $ ----------------8<---------------- Notice that `git rebase --continue` returned 0, so if that were your script, `set -e` wouldn't make the script fail. Hence I'm inclined to think you're either observing a bug pertaining to your particular version of Git (or its flavor - I would not be too much surprized if, say, Git for Windows version X.Y.Z has slight quirks compared to "vanilla" Git X.Y.Z, - or even to your platform) or it's something more local to your case like, maybe, more files actually being in conflicting state. The original script is kept for reference: > #!/bin/bash > > set -eux > set -o pipefail > > if [ -f vars ] > then > # This just sets repo_name, my_url and upstream_url to real life values. > source ./vars > else > repo_name='example-repo-name' > my_url="g...@ghosthub.example.com:dstromberg/$repo_name.git" > upstream_url="g...@ghosthub.example.com:shared/$repo_name.git" > fi > > rm -rf "$repo_name" > > git clone "$my_url" "$repo_name" > cd "$repo_name" > git config --add checkout.defaultRemote origin > git remote add upstream "$upstream_url" > > git checkout develop # already there, actually. > git fetch upstream > # This consistently gives a conflict in docker/requirements.txt.m4 > git rebase upstream/develop develop || true > cp /tmp/requirements.txt.m4 docker/. # Normally I'd edit this to fix the > conflicts, but that got old quick :) > git add docker/requirements.txt.m4 > git commit -m 'Dealt with merge conflicts' docker/requirements.txt.m4 > # This also consistently gives the same conflict again in > docker/requirements.txt.m4 > git rebase --continue > # We never get to this point, because of the set -e > git push --force origin develop -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230515181729.hlp53dujfks3ns7f%40carbon.
