From: Johannes Sixt <j6t@kdbg.org>
To: Sergey Organov <sorganov@gmail.com>
Cc: Sebastian Schuberth <sschuberth@gmail.com>, git@vger.kernel.org
Subject: Re: 'git rebase' silently drops changes?
Date: Mon, 09 Feb 2015 20:03:15 +0100 [thread overview]
Message-ID: <54D90473.2090208@kdbg.org> (raw)
In-Reply-To: <87oap38cv1.fsf@osv.gnss.ru>
Am 09.02.2015 um 13:53 schrieb Sergey Organov:
> 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!
--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.
>> 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
next prev parent reply other threads:[~2015-02-09 19:03 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
2015-02-09 19:03 ` Johannes Sixt [this message]
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=54D90473.2090208@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=sorganov@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).