Re: will git rebase has side effect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2017-10-01 22:17 GMT+08:00 Kevin Daudt <me@xxxxxxxxx>:
> Forgot to cc the mailing list.
>
> On Sun, Oct 01, 2017 at 09:23:23PM +0800, Yubin Ruan wrote:
>> Suppose that I have such a history of commit locally:
>>
>> A --> B --> C --> D
>>
>> If I then add a few more commits locally
>>
>> A --> B --> C --> D --> E --> F --> G
>>
>> And then I do a rebase and squash F and G into one single commit H.
>> What side effect will this rebase have? How will this affect "git push
>> origin master"?
>>
>> Yubin
>
> Hello Yubin,
>
> So the situation is this:
>
>             [origin/master]
>                   |
> A --> B --> C --> D --> E --> F --> G
>                                     |
>                                  [master]
>
> Then you squash (F' is the result of squashing F and G):
>
>             [origin/master]
>                   |
> A --> B --> C --> D --> E --> F'
>                               |
>                            [master]
>
> When you want to push now, it's just as if you just created just two
> commits in the first place, and you can just push normally (assuming no
> one else has pushed in the mean time.

Hmm..You mean, if I do a squash, it will only affects those commits
that has been squashed, not any other commits, and their parent-child
relations remain the same?

Yubin

> The situation is different when you have pushed already:
>
>                               [origin/master]
>                                     |
> A --> B --> C --> D --> E --> F --> G
>                                     |
>                                  [master]
>
> Then after you squash, the history would look as follows:
>
>                               [origin/master]
>                                     |
> A --> B --> C --> D --> E --> F --> G
>                          \
>                           --> F'
>                               |
>                            [master]
>
> This sitation would look to git like you created F', and someone else
> had pushed F and G. It will reject the push, saying you would need to
> merge these changes first (but you don't want this, because you are
> merging the same changes together).
>
> To solve this, you can use git push --force-with-lease=master origin,
> which will force the push, overwriting the history the remote already
> had.
>
> Hope this helps, Kevin.
>
> nb. --force-with-lease is a safer version of just (-f|--force), because
> it will prevent you from overwriting history you don't have locally, for
> example when someone else did push already.
>
>



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux