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

Re: rebase problems

From
Junio C Hamano <junkio@cox.net>
Date
Nov 28, 2005, 20:19 UTC
Message-ID
<7v4q5wttib.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20051128145814.GW8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
Show 37 quoted lines
> Recently, rebasing has stopped working for me.
> Here is an example:
>
> bash-3.00$ git-show-branch origin HEAD
> ! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
>  ! [HEAD] propagate LinearizationType typo fix.
> --
>  + [HEAD] propagate LinearizationType typo fix.
>  + [HEAD^] LinearizationType: typo
>  + [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
>  + [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
>  + [HEAD~4] Use proper class for LinearizationType.
>  + [HEAD~5] espam/../DecomposeChannels: partial implementation.
>  + [HEAD~6] espam: add flag for channel decomposition.
> +  [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
> ++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
> bash-3.00$ git rebase origin
>
> Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'
>
> error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 ->  -> 32da8b1de4205c4adb0da50648a0a00d60b67582
> fatal: merge program failed
> Failed to merge in the changes.
> Patch failed at 0007.
> 0001-espam-add-flag-for-channel-decomposition.txt
>
>
> I'm not sure what rebase is doing here, but the only change in origin
> modified a file untouched by the changes in HEAD, so there shouldn't
> be any conflict whatsoever.
> Apparently it's trying to apply the change in HEAD~2 without having
> applied the earlier changes (which and the file named above).

What it should be doing (although I have not seen this kind of breakage myself, there could be a bug that makes rebase not to do what it should be doing) is:

 - save the original HEAD to .git/ORIG_HEAD
 - reset the tree to origin without switching branches
 - prepare patches for changes ~6, ~5, ... brings in
 - feed that to git-am, which saves the 7 patches in
   .dotest/0001 through .dotest/0007 and starts applying them.

As the first thing to do after you see something like this, please stash away ORIG_HEAD, like this:

	$ git branch before-rebase-precious ORIG_HEAD

After this, if you choose not to rebase for whatever reason, including "rebase is broken X-<", you could do

	$ git-reset --hard before-rebase-precious
to come back to the state before trying rebase.

The output seems very inconsistent I am not sure why the first message says "Applying HEAD~2", not HEAD~6. What patches do you see in .dotest/ directory, and are they numbered in the right order? HEAD~6 should be numbered 0001 and that should be the first one that was applied.

Previous: Sven VerdoolaegeNext: Sven Verdoolaege
Message 2 of 4 in “rebase problems”
  1. Sven VerdoolaegeNov 28, 2005
  2. Junio C HamanoNov 28, 2005
  3. Sven VerdoolaegeNov 28, 2005
  4. Junio C HamanoNov 28, 2005

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.