Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: 李本超 <libenchao@gmail.com>
Cc: Pranit Bauva <pranit.bauva@gmail.com>, Git List <git@vger.kernel.org>
Subject: Re: bug report
Date: Fri, 13 May 2016 04:10:15 -0400	[thread overview]
Message-ID: <20160513081014.GA18307@sigill.intra.peff.net> (raw)
In-Reply-To: <CABKuJ_RrOhT+FVb9PNKhBs1ATJmLWhD757oyx+AvrCGNvT1nFw@mail.gmail.com>

On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:

> It does not warn me in this case. I replayed it again, below is my process:
> 
> [...setup...]

So after you setup steps you have:

  $ git log --decorate --oneline --raw

  * a3ce3bc (HEAD -> B) modify
  | :100644 100644 94954ab... 23509e0... M        README.md
  * ef702eb add one line too
  | :100644 100644 ce01362... 94954ab... M        README.md
  | * fa8b99e (master, A) add one line
  |/  
  |   :100644 100644 ce01362... 94954ab... M      README.md
  * cf2103b add readme
    :000000 100644 0000000... ce01362... A        README.md

Note that B^ (ef702eb) and A (fa8b99e) introduce the exact same change
(moving README.md from ce01362 to 94954ab). And master is at the same
commit as A (due to your fast-forward merge earlier).

So now when you run:

> $ git rebase master

Git will try to replay the commits on master..B on top of master, in
order.  Those commits are ef702eb and a3ce3bc (your commit names will
differ, because your name and timestamps will differ).

So it replays the first one, and sees that it the patch is a noop[1];
the tree in master already has the same end state. So we skip the patch.
And then we replay the second one, which applies cleanly.

The moment where I think you'd like to be notified is when we skipped
doing anything with patch 1. You'd prefer it to say "woah, the other
side of the rebase did the same thing as us".

But rebase does not do that by default, because the intent of rebase is
that you are rebasing your work on an upstream which might be accepting
part of your work as patches. So it is a feature that rebase says
"already applied upstream -- let's ignore this one".

I don't think there is a way to ask rebase not to ignore such
already-applied patches. But I'm not sure if there should be, for two
reasons:

  1. You should consider just using "git merge" to merge the two
     branches. That preserves more information about what actually
     happened, and would find a conflict in a case like this.

  2. Even with merging, you cannot assume that the end result is sane.
     In your example, there is a textual conflict. But you can easily
     come up with other examples where a merge is textually sound, but
     has some semantic conflict (e.g., you update the signature of a
     function but a colleague adds another call to it using the old
     signature).

     You have to examine and test the results of merges for sanity. And
     likewise with rebases.

-Peff

[1] Actually, rebase does not even try to replay the first patch. When
    it generates the list of commits, it ignores any whose "patch-id" is
    the same as a commit on the other side. But the end effect is the
    same.

  reply	other threads:[~2016-05-13  8:10 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13  5:04 bug report 李本超
2016-05-13  5:23 ` Pranit Bauva
2016-05-13  5:58   ` 李本超
2016-05-13  6:37     ` Pranit Bauva
2016-05-13  6:57       ` 李本超
2016-05-13  7:10         ` Pranit Bauva
2016-05-13  7:41           ` 李本超
2016-05-13  8:10             ` Jeff King [this message]
2016-05-13 12:05               ` 李本超
  -- strict thread matches above, loose matches on Subject: below --
2023-08-28 12:51 Bug report Dexter Pontañeles
2023-06-27 16:02 Bug Report Tiago d'Almeida
2022-12-28  2:43 Bug report Jensen Bean
2022-12-28  5:02 ` Eric Sunshine
2022-12-25 17:26 bug report Eyal Post
2022-12-25 18:12 ` Eric Sunshine
2022-12-08  5:29 Bug Report Jensen Bean
2022-12-08  8:31 ` Bagas Sanjaya
     [not found]   ` <CANqKdC-gHgQHn5DMoOREY52y7PpRLMpNAjX3qeA5iy9z_GXdzw@mail.gmail.com>
2022-12-26  2:15     ` Bagas Sanjaya
2022-11-19 20:20 Jensen Bean
2022-10-03 15:28 Bug report Alastair Douglas
2022-10-03 16:53 ` Junio C Hamano
2022-10-04 10:15   ` Alastair Douglas
2022-10-05  5:46     ` Junio C Hamano
2022-04-20 19:45 Bug Report Daniel Habenicht
2022-04-20 21:30 ` brian m. carlson
2022-04-20 22:34   ` rsbecker
2022-04-21 13:20     ` Daniel Habenicht
2022-04-21 14:39       ` Torsten Bögershausen
     [not found]         ` <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>
2022-04-21 17:52           ` Torsten Bögershausen
2021-12-01 22:31 Josh Rampersad
2021-11-12  4:22 bug report Theodore Li
2021-11-12  4:29 ` Junio C Hamano
2021-11-12  6:59   ` Theodore Li
2021-11-12 14:05     ` Paul Smith
2020-03-27 11:53 Bug Report James Yeoman
2020-03-27 12:59 ` Pratyush Yadav
     [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
2019-04-15 15:18 ` bug report Nick Steinhauser
2017-08-30 21:25 Bug report Aleksandar Pavic
2017-08-31  6:36 ` Kevin Daudt
2017-08-31 14:19   ` Dov Grobgeld
2017-08-31 14:55     ` Aleksandar Pavic
2017-08-31 16:23   ` Stephan Beyer
2017-09-02  8:49 ` Jeff King
2016-04-03  0:25 Bug Report Benjamin Sandeen
2016-04-03  2:20 ` Eric N. Vander Weele
2016-04-03  2:22 ` Jacob Keller
2015-01-27 14:43 bug report Albert Akhriev
2015-01-27 14:50 ` Jeff King
     [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
2013-04-08  5:20 ` Bug Report Kirk Fraser
2012-10-05 10:13 Bug report Муковников Михаил
2012-10-05 10:32 ` Konstantin Khomoutov
2012-10-05 10:47   ` Carlos Martín Nieto
2012-10-05 11:03     ` Муковников Михаил
2012-10-05 10:52   ` Муковников Михаил
2012-10-04  4:35 John Whitney
2012-10-04 14:19 ` Phil Hord
2012-10-04 16:10   ` John Whitney
2012-10-06 13:31     ` Jeff King
2012-10-07  2:23       ` John Whitney
2012-10-07 23:52         ` Jeff King
2012-10-09 17:17           ` John Whitney
2012-10-09 19:00             ` John Whitney
2012-10-04 15:21 ` Andrew Wong
2012-10-04 16:16   ` John Whitney
2012-10-04 16:28     ` John Whitney
2012-10-04 17:01     ` Andrew Wong

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=20160513081014.GA18307@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=libenchao@gmail.com \
    --cc=pranit.bauva@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 read-only IMAP folder(s) and NNTP newsgroup(s).