From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Organov Subject: 'git rebase' silently drops changes? Date: Sat, 07 Feb 2015 00:28:00 +0300 Message-ID: <87386ispb3.fsf@osv.gnss.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Feb 06 22:36:04 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJqZH-0004FD-7F for gcvg-git-2@plane.gmane.org; Fri, 06 Feb 2015 22:36:03 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755834AbbBFVf7 (ORCPT ); Fri, 6 Feb 2015 16:35:59 -0500 Received: from mail.javad.com ([54.86.164.124]:53839 "EHLO mail.javad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754731AbbBFVf6 (ORCPT ); Fri, 6 Feb 2015 16:35:58 -0500 X-Greylist: delayed 475 seconds by postgrey-1.27 at vger.kernel.org; Fri, 06 Feb 2015 16:35:58 EST Received: from osv.gnss.ru (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id A440E618A2 for ; Fri, 6 Feb 2015 21:28:02 +0000 (UTC) Received: from osv by osv.gnss.ru with local (Exim 4.72) (envelope-from ) id 1YJqRU-0006Hw-Se for git@vger.kernel.org; Sat, 07 Feb 2015 00:28:00 +0300 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hello, I recently ran into an annoying problem: 'git rebase' apparently silently drops changes in non-conflicting paths of merge commits (git version 1.9.3). Is it a bug or feature? Is there a way to flatten history using rebase, yet preserve manual changes found in merge commits? Here is simplified reproduction of what I've encountered: I.e., the modification marked [!] was silently lost during rebase! -- Sergey. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Schuberth Subject: Re: 'git rebase' silently drops changes? Date: Sat, 07 Feb 2015 22:32:05 +0100 Message-ID: <54D68455.5070305@gmail.com> References: <87386ispb3.fsf@osv.gnss.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Sat Feb 07 22:32:22 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKCzE-0003U1-US for gcvg-git-2@plane.gmane.org; Sat, 07 Feb 2015 22:32:21 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758682AbbBGVcQ (ORCPT ); Sat, 7 Feb 2015 16:32:16 -0500 Received: from plane.gmane.org ([80.91.229.3]:32783 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758672AbbBGVcP (ORCPT ); Sat, 7 Feb 2015 16:32:15 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKCz7-0003Rs-QD for git@vger.kernel.org; Sat, 07 Feb 2015 22:32:13 +0100 Received: from p57a25c1b.dip0.t-ipconnect.de ([87.162.92.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Feb 2015 22:32:13 +0100 Received: from sschuberth by p57a25c1b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Feb 2015 22:32:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p57a25c1b.dip0.t-ipconnect.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 In-Reply-To: <87386ispb3.fsf@osv.gnss.ru> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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 > > > I.e., the modification marked [!] was silently lost during rebase! Just a wild guess: Maybe because you omitted "-p" / "--preserve-merges" from "git rebase"? -- Sebastian Schuberth From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Sixt Subject: Re: 'git rebase' silently drops changes? Date: Sun, 08 Feb 2015 14:49:31 +0100 Message-ID: <54D7696B.3060407@kdbg.org> References: <87386ispb3.fsf@osv.gnss.ru> <54D68455.5070305@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org To: Sebastian Schuberth , Sergey Organov X-From: git-owner@vger.kernel.org Sun Feb 08 14:49:48 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKSF8-0000Ml-8p for gcvg-git-2@plane.gmane.org; Sun, 08 Feb 2015 14:49:46 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752193AbbBHNtg (ORCPT ); Sun, 8 Feb 2015 08:49:36 -0500 Received: from bsmtp7.bon.at ([213.33.87.19]:32761 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751679AbbBHNtf (ORCPT ); Sun, 8 Feb 2015 08:49:35 -0500 Received: from dx.sixt.local (unknown [93.83.142.38]) by bsmtp.bon.at (Postfix) with ESMTPSA id 3kgBYm5wVkz5tlB; Sun, 8 Feb 2015 14:49:32 +0100 (CET) Received: from dx.sixt.local (localhost [IPv6:::1]) by dx.sixt.local (Postfix) with ESMTP id 065CF19F922; Sun, 8 Feb 2015 14:49:31 +0100 (CET) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <54D68455.5070305@gmail.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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 >> >> >> 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. 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. -- Hannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Organov Subject: Re: 'git rebase' silently drops changes? Date: Mon, 09 Feb 2015 15:53:54 +0300 Message-ID: <87oap38cv1.fsf@osv.gnss.ru> References: <87386ispb3.fsf@osv.gnss.ru> <54D68455.5070305@gmail.com> <54D7696B.3060407@kdbg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sebastian Schuberth , git@vger.kernel.org To: Johannes Sixt X-From: git-owner@vger.kernel.org Mon Feb 09 13:54:04 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKnqk-0001bV-3F for gcvg-git-2@plane.gmane.org; Mon, 09 Feb 2015 13:54:02 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932866AbbBIMx6 (ORCPT ); Mon, 9 Feb 2015 07:53:58 -0500 Received: from mail.javad.com ([54.86.164.124]:56019 "EHLO mail.javad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932469AbbBIMx5 (ORCPT ); Mon, 9 Feb 2015 07:53:57 -0500 Received: from osv.gnss.ru (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id 9FED562BF4; Mon, 9 Feb 2015 12:53:56 +0000 (UTC) Received: from osv by osv.gnss.ru with local (Exim 4.72) (envelope-from ) id 1YKnqc-0008Vx-RN; Mon, 09 Feb 2015 15:53:54 +0300 In-Reply-To: <54D7696B.3060407@kdbg.org> (Johannes Sixt's message of "Sun, 08 Feb 2015 14:49:31 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Johannes Sixt 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 >>> >>> >>> 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": -- Sergey. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Sixt Subject: Re: 'git rebase' silently drops changes? Date: Mon, 09 Feb 2015 20:03:15 +0100 Message-ID: <54D90473.2090208@kdbg.org> References: <87386ispb3.fsf@osv.gnss.ru> <54D68455.5070305@gmail.com> <54D7696B.3060407@kdbg.org> <87oap38cv1.fsf@osv.gnss.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Sebastian Schuberth , git@vger.kernel.org To: Sergey Organov X-From: git-owner@vger.kernel.org Mon Feb 09 20:03:29 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKtcE-0006XZ-N9 for gcvg-git-2@plane.gmane.org; Mon, 09 Feb 2015 20:03:27 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933807AbbBITDW (ORCPT ); Mon, 9 Feb 2015 14:03:22 -0500 Received: from bsmtp7.bon.at ([213.33.87.19]:6629 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933756AbbBITDW (ORCPT ); Mon, 9 Feb 2015 14:03:22 -0500 Received: from dx.sixt.local (unknown [93.83.142.38]) by bsmtp.bon.at (Postfix) with ESMTPSA id 3kgxTL4Wryz5tlH; Mon, 9 Feb 2015 20:03:18 +0100 (CET) Received: from dx.sixt.local (localhost [IPv6:::1]) by dx.sixt.local (Postfix) with ESMTP id EDD0C19F925; Mon, 9 Feb 2015 20:03:15 +0100 (CET) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <87oap38cv1.fsf@osv.gnss.ru> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 09.02.2015 um 13:53 schrieb Sergey Organov: > Johannes Sixt 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 >>>> >>>> >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Organov Subject: Re: 'git rebase' silently drops changes? Date: Tue, 10 Feb 2015 14:46:52 +0300 Message-ID: <87pp9ivvir.fsf@osv.gnss.ru> References: <87386ispb3.fsf@osv.gnss.ru> <54D68455.5070305@gmail.com> <54D7696B.3060407@kdbg.org> <87oap38cv1.fsf@osv.gnss.ru> <54D90473.2090208@kdbg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sebastian Schuberth , git@vger.kernel.org To: Johannes Sixt X-From: git-owner@vger.kernel.org Tue Feb 10 12:47:00 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YL9HP-0005dZ-LK for gcvg-git-2@plane.gmane.org; Tue, 10 Feb 2015 12:47:00 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755115AbbBJLq4 (ORCPT ); Tue, 10 Feb 2015 06:46:56 -0500 Received: from mail.javad.com ([54.86.164.124]:43704 "EHLO mail.javad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753145AbbBJLqz (ORCPT ); Tue, 10 Feb 2015 06:46:55 -0500 Received: from osv.gnss.ru (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id 2CCB163680; Tue, 10 Feb 2015 11:46:54 +0000 (UTC) Received: from osv by osv.gnss.ru with local (Exim 4.72) (envelope-from ) id 1YL9HI-0000gx-G8; Tue, 10 Feb 2015 14:46:52 +0300 In-Reply-To: <54D90473.2090208@kdbg.org> (Johannes Sixt's message of "Mon, 09 Feb 2015 20:03:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Johannes Sixt writes: > Am 09.02.2015 um 13:53 schrieb Sergey Organov: [...] > 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 ... Thanks a lot, this sounds promising! I've read the message for this commit and it mentions no drawbacks. Are you aware of any? > Beware, its implementation is incomplete: if the rebase is interrupted, > then 'git rebase --continue' behaves as if --first-parent were not > given. Just never did get round to it, or something more fundamental? To be useful for me, it also needs a support for 'git pull' to pass this flag to 'git rebase', but that I think I can easily fix myself. >>> 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. Nice to hear there are chances to improve this in the future. Thanks again! -- Sergey. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Sixt Subject: Re: 'git rebase' silently drops changes? Date: Tue, 10 Feb 2015 19:26:19 +0100 Message-ID: <54DA4D4B.5010902@kdbg.org> References: <87386ispb3.fsf@osv.gnss.ru> <54D68455.5070305@gmail.com> <54D7696B.3060407@kdbg.org> <87oap38cv1.fsf@osv.gnss.ru> <54D90473.2090208@kdbg.org> <87pp9ivvir.fsf@osv.gnss.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Sebastian Schuberth , git@vger.kernel.org To: Sergey Organov X-From: git-owner@vger.kernel.org Tue Feb 10 19:26:32 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLFW3-00075o-Ks for gcvg-git-2@plane.gmane.org; Tue, 10 Feb 2015 19:26:31 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365AbbBJS00 (ORCPT ); Tue, 10 Feb 2015 13:26:26 -0500 Received: from bsmtp7.bon.at ([213.33.87.19]:46965 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753349AbbBJS00 (ORCPT ); Tue, 10 Feb 2015 13:26:26 -0500 Received: from dx.sixt.local (unknown [93.83.142.38]) by bsmtp.bon.at (Postfix) with ESMTPSA id 3khXcF6mRBz5tlN; Tue, 10 Feb 2015 19:26:21 +0100 (CET) Received: from dx.sixt.local (localhost [IPv6:::1]) by dx.sixt.local (Postfix) with ESMTP id 5480D19F938; Tue, 10 Feb 2015 19:26:20 +0100 (CET) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <87pp9ivvir.fsf@osv.gnss.ru> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 10.02.2015 um 12:46 schrieb Sergey Organov: > Johannes Sixt writes: > >> Am 09.02.2015 um 13:53 schrieb Sergey Organov: > > [...] > >> 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 ... > > Thanks a lot, this sounds promising! I've read the message for this > commit and it mentions no drawbacks. Are you aware of any? Except for this... >> Beware, its implementation is incomplete: if the rebase is interrupted, >> then 'git rebase --continue' behaves as if --first-parent were not >> given. ... not anything that I would care about. Of course, you can't rebase branchy history when this option is specified, but that's the whole point. > Just never did get round to it, or something more fundamental? Nothing fundamental. Just has to store the option in the rebase state like all the other options. -- Hannes