On 20/08/2018 11:22, Konstantin Kharlamov wrote:
> So, steps-to-reproduce below rather full of trivia like setting up a
> repo, but the TL;DR is:
>
> Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a
> "hunk" as one commit, and then using `git rebase --continue` so the
> other part of hunk would be left in top commit; git raises a conflict.
I think this is a misleading error message as in your example below
there are no conflicts, just unstaged changes. git-rebase.sh has the
following code
git update-index --ignore-submodules --refresh &&
git diff-files --quiet --ignore-submodules || {
echo "$(gettext "You must edit all merge conflicts and then
mark them as resolved using git add")"
exit 1
I think this pre-dates interactive rebases when the only unstaged
changes could be conflicts.
>
> It's spectacular, that content of one of inserted conflict markers is
> empty, so all you have to do is to remove the markers, and use `git add`
> on the file, and then `git rebase --continue`
>
> Its a lot of unncessary actions, git could just figure that the code it
> sees in the patch is already there, being a part of another commit.
If there are conflict markers where one side is empty it means that some
lines from the merge base (which for a rebase is the parent of the
commit being picked) have been deleted on one side and modified on the
other. Git cannot know if you want to use the deleted version or the
modified version. You can use 'git diff --cc' to see the combined diff
which should show the lines being deleted on both sides and an addition
on the side with the modified lines. You can also set the
merge.conflictStyle config variable to diff3 to see the original text as
well as the text from the merge heads.
Best Wishes
Phillip
>
> Maybe git could issue a warning, or to question a user interactively
> (y/n); but raising a conflict IMO is unnecessary.
>
> # Steps to reproduce
>
> In empty dir execute:
>
> $ git init
> $ touch test
> Initialized empty Git repository in /tmp/test/.git/
> $ git add test
> $ git commit
> [master (root-commit) a7ce543] 1st commit
> 1 file changed, 2 insertions(+)
> create mode 100644 test
> $ echo -e "foo\nbar" > test # content you'll want to break
> $ git add -u && git commit
> [detached HEAD 9e28331] 2-nd commit
> 1 file changed, 2 insertions(+)
> $ git rebase -i --root
> Stopped at a7ce543... 1st commit
> You can amend the commit now, with
>
> git commit --amend
>
> Once you are satisfied with your changes, run
>
> git rebase --continue
>
> Put "edit" for the 2-nd commit
>
> $ git reset HEAD^
> Unstaged changes after reset:
> M test
> $ git add -p
> diff --git a/test b/test
> index e69de29..3bd1f0e 100644
> --- a/test
> +++ b/test
> @@ -0,0 +1,2 @@
> +foo
> +bar
> Stage this hunk [y,n,q,a,d,e,?]? e
>
> ╭─constantine@constantine-N61Ja /tmp/test ‹node-› ‹› (e721fa3*)
> ╰─$ git commit
> [detached HEAD 27b2f63] add foo
> 1 file changed, 1 insertion(+)
> ╭─constantine@constantine-N61Ja /tmp/test ‹node-› ‹› (27b2f63*)
> ╰─$ git rebase --continue
> test: needs update
> You must edit all merge conflicts and then
> mark them as resolved using git add
>
> What happened is that it's obvious that the hunk was broken to multiple
> commits, and git should figure that out, and not to raise a conflict.
>
> Side note: for some reason in the test git didn't insert conflict
> markers. It did in real-world usecase though, and there was simply no
> content inside one of them.
>
