From: Sergey Organov <sorganov@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Sebastian Schuberth <sschuberth@gmail.com>, git@vger.kernel.org
Subject: Re: 'git rebase' silently drops changes?
Date: Mon, 09 Feb 2015 15:53:54 +0300 [thread overview]
Message-ID: <87oap38cv1.fsf@osv.gnss.ru> (raw)
In-Reply-To: <54D7696B.3060407@kdbg.org> (Johannes Sixt's message of "Sun, 08 Feb 2015 14:49:31 +0100")
Johannes Sixt <j6t@kdbg.org> writes:
> Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:
>> On 06.02.2015 22:28, Sergey Organov wrote:
>>
>>> # 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.
next prev parent reply other threads:[~2015-02-09 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 21:28 'git rebase' silently drops changes? Sergey Organov
2015-02-07 21:32 ` Sebastian Schuberth
2015-02-08 13:49 ` Johannes Sixt
2015-02-09 12:53 ` Sergey Organov [this message]
2015-02-09 19:03 ` Johannes Sixt
2015-02-10 11:46 ` Sergey Organov
2015-02-10 18:26 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oap38cv1.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=sschuberth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.