Re: 'git rebase' silently drops changes?

Johannes Sixt [off-list ref] writes:

Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:

quoted

On 06.02.2015 22:28, Sergey Organov wrote:

quoted

# Now rebase my work.
git rebase -f HEAD~1

# What? Where is my "Precious" change in "a"???
cat a
</SCRIPT>

I.e., the modification marked [!] was silently lost during rebase!

Just a wild guess: Maybe because you omitted "-p" / "--preserve-merges"
from "git rebase"?

No, that would not help. --preserve-merges repeats the merge, but does
not apply the amendment.

Really? Why? Here the valid concern you gave below doesn't even apply!

Check... yes, git silently drops amend even with --preserve-merges
(script to reproduce at the end[1])! How comes?

It's just how rebase works: It omits merge commits when it linearizes
history.

Sergey, it is impossible for git rebase to decide to which rebased
commit the amendement applies. It doesn't even try to guess. It's the
responsibility of the user to apply the amendment to the correct
commit.

Yeah, this sounds reasonable, /except/ git even gives no warning when it
drops amendments. Shouldn't 'git rebase' rather consider merge amendment
a kind of conflict?


[1] To reproduce amend drop by "git rebase --preserve-merges":

<SCRIPT>
git init t
cd t
git config rerere.enabled false # doesn't actually matter either way.

echo "I" > a; git add a
echo "I" > b; git add b
git commit -aqm "I"
git tag start

git checkout -b test

echo "B" >> b; git commit -m "B" -a

git checkout master

echo "A" >> a
git commit -aqm "A"

git merge --no-edit test
git branch -d test

# Clean merge, but result didn't compile, so I fixed it and
# amended the merge:
echo "Precious!" >> a # [!] This is modification that gets lost
git commit --amend --no-edit -aq
cat a

# Make a change earlier in history, to rebase my work on top of it.
git co -q start
git co -b test
echo "C" > c; git add c
git commit -aqm "C"

# Now rebase my work.
git co master
git rebase --preserve-merges --no-fork-point test

# What? Where is my "Precious" change in "a"???
cat a

</SCRIPT>

-- Sergey.

Am 09.02.2015 um 13:53 schrieb Sergey Organov:

Johannes Sixt [off-list ref] writes:

quoted

Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:

quoted

On 06.02.2015 22:28, Sergey Organov wrote:

quoted

# Now rebase my work.
git rebase -f HEAD~1

# What? Where is my "Precious" change in "a"???
cat a
</SCRIPT>

I.e., the modification marked [!] was silently lost during rebase!

Just a wild guess: Maybe because you omitted "-p" / "--preserve-merges"
from "git rebase"?

No, that would not help. --preserve-merges repeats the merge, but does
not apply the amendment.

Really? Why? Here the valid concern you gave below doesn't even apply!

--preserve-merges was bolted on to git-rebase. The first implementation
just re-computed the merge, and rebase would be interrupted if the merge
was not clean. This was good enough for many.

Later --preserve-merges was abused to replay not only integration
branches, but branchy history in general. At that time, the feature was
deemed wide spread enough that changing its behavior was a no-go.

There you have it.

If you want a version of --preserve-merges that does what *you* need,
consider this commit:

  git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent

Use it like this:

  git rebase -i -p --first-parent ...

Beware, its implementation is incomplete: if the rebase is interrupted,
then 'git rebase --continue' behaves as if --first-parent were not given.

quoted

it is impossible for git rebase to decide to which rebased
commit the amendement applies. It doesn't even try to guess. It's the
responsibility of the user to apply the amendment to the correct
commit.

Yeah, this sounds reasonable, /except/ git even gives no warning when it
drops amendments. Shouldn't 'git rebase' rather consider merge amendment
a kind of conflict?

There is work in progress where a merge is computed entirely in-memory
(without relying on files in the worktree). It could be used to detect
whether there are any changes beyond the automatic merge results, and
they could be warned about.

-- Hannes