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

Re: Disappearing change on pull rebase

From
Kirill Likhodedov <kirill.likhodedov@jetbrains.com>
Date
Nov 10, 2011, 14:23 UTC
Message-ID
<B5934593-5EE9-4A9F-96D5-0E36B696EFBD@jetbrains.com>
In-Reply-To
<3FF1328CB05DB74898F769F1BA17812C3E49B74671@GVW1348EXA.americas.hpqcorp.net>
10.11.2011, в 16:15, Pitucha, Stanislaw Izaak:
Show 20 quoted lines
> Hi all,
> I've got an issue with some operations. It seems like git eats one of my commits (it's still in reflog, but in normal tree, it's unavailable).
> 
> What I did is:
> 
> checkout -b feature/....
> (edit files and commit)
> checkout master
> merge --no-ff --no-commit feature/...
> (edit some files, change versions, changelog)
> commit
> 
> Now I've got the change committed in the branch and some more changes on the merge commit.
> So before pushing to the main repo, I'd like to check if any other changes are there:
> 
> pull --rebase
> 
> Now my merge commit disappears completely along with the changes without any warning. I get the branch commits duplicated on top of master and the branch stays as it was.
> That looks like a data loss bug to me since I can only recover a committed change from reflog and there are no warnings before that change goes away (using 1.7.4.1). Actually no changes were done in upstream in the meantime, so the rebase was not even needed.
> 

That is definitely not a bug. "git pull --rebase" is (almost?) equal to "git fetch ; git rebase origin/master" When you perform a rebase, at first your HEAD is rolled back to the commit before your changes, then it is fast-forwared to the remote HEAD (in your case, no fast-forward was made, because there were no remote changes); then your commits are applied one by one.

Of couse, when your commits are applied, they are applied like patches. That mean, that they are different from the original commits (at least, by the commit time). That causes the duplication.

And the merge commit "dissapeared", because it contained no changes, so the patch was empty, and there was nothing to reapply. If the merge commit contained some changes, and it really was not applied during rebase, it is a bug, but more details will be needed, I think.

If you want to preserve your branch history, you should do "pull" without "rebase".
Kirill.
Previous: Pitucha, Stanislaw IzaakNext: Pitucha, Stanislaw Izaak
Message 2 of 8 in “Disappearing change on pull rebase”
  1. Pitucha, Stanislaw IzaakNov 10, 2011
  2. Kirill LikhodedovNov 10, 2011
  3. Pitucha, Stanislaw IzaakNov 10, 2011
  4. Johannes SixtNov 11, 2011
  5. Philippe VaucherNov 11, 2011
  6. Johannes SixtNov 11, 2011
  7. Philippe VaucherNov 11, 2011
  8. Junio C HamanoNov 11, 2011

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.