Re: Handling rebasing better

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

 



On Wed, Oct 26, 2022 at 9:49 AM <djvortex@xxxxxxx> wrote:
>
> > > Perhaps git could even support the "reset-to-the-remote-history and then cherry-pick your new local commits" directly, to help the developer in this task (so that you don't need to write down any hashes and do all that manually). But even if this isn't really feasible, at least detecting the situation and the clearer messages would help enormously.
>
> > Are you aware of
> > git pull --rebase
> > ?
>
> I don't see how that helps anything. That *does* a rebase, it doesn't help dealing with a rebase someone else has done and pushed onto the remote

Actually, what it does is exactly the feature you asked for. It
attempts to cherry-pick your local changes on top of the changes on
remote. Rebase is essentially cherry-pick but with more bells and
whistles

> (which now conflicts with your local old history)

In case of conflict, those will naturally need to be resolved.



[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