git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Handling rebasing better

From
EEErik Cervin Edin <erik@cervined.in>
Date
Oct 26, 2022, 08:31 UTC
Message-ID
<CA+JQ7M-UxvhC4jvYdqv1i2267KV5yjc2Xxp0ShHz+=j=W0s2pQ@mail.gmail.com>
In-Reply-To
<trinity-1b24da2a-4ee4-420b-9cef-e88a8bbcb385-1666770562213@3c-app-mailcom-bs12>
On Wed, Oct 26, 2022 at 9:49 AM <djvortex@gmx.com> wrote:
Show 8 quoted lines
>
> > > 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.
Previous: Erik Cervin Edin
Message 4 of 4 in “Handling rebasing better”
  1. djvortex@gmx.comSep 22, 2022
  2. Philip OakleyOct 19, 2022
  3. Erik Cervin EdinOct 19, 2022
  4. Erik Cervin EdinOct 26, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.