{"thread":{"id":"28906","subject":"Disappearing change on pull rebase","startedAt":"2011-11-10T13:15:31Z","lastAt":"2011-11-11T16:31:49Z","messageCount":8,"participants":["Pitucha, Stanislaw Izaak","Kirill Likhodedov","Johannes Sixt","Philippe Vaucher","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179274","messageId":"3FF1328CB05DB74898F769F1BA17812C3E49B74671@GVW1348EXA.americas.hpqcorp.net","threadId":"28906","inReplyTo":null,"subject":"Disappearing change on pull rebase","fromName":"Pitucha, Stanislaw Izaak","fromEmail":"stanislaw.pitucha@hp.com","sentAt":"2011-11-10T13:15:31Z","receivedAt":"2011-11-10T13:15:31Z","isPatch":false,"sender":{"key":"stanislaw.pitucha@hp.com","avatar":null},"body":"Hi all,\nI'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).\n\nWhat I did is:\n\ncheckout -b feature/....\n(edit files and commit)\ncheckout master\nmerge --no-ff --no-commit feature/...\n(edit some files, change versions, changelog)\ncommit\n\nNow I've got the change committed in the branch and some more changes on the merge commit.\nSo before pushing to the main repo, I'd like to check if any other changes are there:\n\npull --rebase\n\nNow 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.\nThat 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.\n\nRegards,\nStanisław Pitucha\nCloud Services \nHewlett Packard\n\n\n"},{"id":"179276","messageId":"3FF1328CB05DB74898F769F1BA17812C3E49B74699@GVW1348EXA.americas.hpqcorp.net","threadId":"28906","inReplyTo":"B5934593-5EE9-4A9F-96D5-0E36B696EFBD@jetbrains.com","subject":"RE: Disappearing change on pull rebase","fromName":"Pitucha, Stanislaw Izaak","fromEmail":"stanislaw.pitucha@hp.com","sentAt":"2011-11-10T13:35:40Z","receivedAt":"2011-11-10T13:35:40Z","isPatch":false,"sender":{"key":"stanislaw.pitucha@hp.com","avatar":null},"body":"As mentioned in the original mail - the merge commit did have changes. Here's the log of reproducing it. The line containing \"2\" in changelog is gone from master after pull --rebase.\n\n$ git init fake_upstream\nInitialized empty Git repository in /tmp/fake_upstream/.git/\n$ cd fake_upstream/ \nfake_upstream$ echo some_content > test\nfake_upstream$ echo 1 > changelog\nfake_upstream$ git add test changelog \nfake_upstream$ git commit -m 'first commit'\n[master (root-commit) b1b683d] first commit\n 2 files changed, 2 insertions(+), 0 deletions(-)\n create mode 100644 changelog\n create mode 100644 test\nfake_upstream$ cd ..\n\n$ git clone /tmp/fake_upstream/ disappearing_commit\nCloning into disappearing_commit...\ndone.\n$ cd disappearing_commit/\ndisappearing_commit$ git checkout -b some-branch\nSwitched to a new branch 'some-branch'\ndisappearing_commit$ echo blah >> test\ndisappearing_commit$ git commit test -m 'branch modification'\n[some-branch 528f166] branch modification\n 1 files changed, 1 insertions(+), 0 deletions(-)\ndisappearing_commit$ git checkout master\nSwitched to branch 'master'\n\ndisappearing_commit$ git merge --no-ff --no-commit some-branch\nAutomatic merge went well; stopped before committing as requested\ndisappearing_commit$ echo 2 >> changelog \ndisappearing_commit$ git add changelog\ndisappearing_commit$ git commit\n[master e41e4c9] Merge branch 'some-branch'\n\ndisappearing_commit$ git show\ncommit e41e4c963a72528e3b2b5945ca419e19cdba1e4b\nMerge: b1b683d 528f166\nAuthor: Stanislaw Pitucha <stanislaw.pitucha@hp.com>\nDate:   Thu Nov 10 13:30:04 2011 +0000\n\n    Merge branch 'some-branch'\n\ndiff --cc changelog\nindex d00491f,d00491f..1191247\n--- a/changelog\n+++ b/changelog\n@@@ -1,1 -1,1 +1,2 @@@\n  1\n++2\ndisappearing_commit$ git pull --rebase\nFirst, rewinding head to replay your work on top of it...\nApplying: branch modification\ndisappearing_commit$ git show\ncommit ef8f5e40db9fe7efbd4e493ff68b12327acde283\nAuthor: Stanislaw Pitucha <stanislaw.pitucha@hp.com>\nDate:   Thu Nov 10 13:29:33 2011 +0000\n\n    branch modification\n\ndiff --git a/test b/test\nindex 6e099dc..2f3f685 100644\n--- a/test\n+++ b/test\n@@ -1 +1,2 @@\n some_content\n+blah\n\n\nRegards,\nStanisław Pitucha\nCloud Services \nHewlett Packard\n"},{"id":"179275","messageId":"B5934593-5EE9-4A9F-96D5-0E36B696EFBD@jetbrains.com","threadId":"28906","inReplyTo":"3FF1328CB05DB74898F769F1BA17812C3E49B74671@GVW1348EXA.americas.hpqcorp.net","subject":"Re: Disappearing change on pull rebase","fromName":"Kirill Likhodedov","fromEmail":"kirill.likhodedov@jetbrains.com","sentAt":"2011-11-10T14:23:36Z","receivedAt":"2011-11-10T14:23:36Z","isPatch":false,"sender":{"key":"kirill.likhodedov@jetbrains.com","avatar":"https://gravatar.com/avatar/9fd55d2a110e8e96deb3ed7b503d7f3b9b5b1ed5ca9ef6683c15525b11b94e63?d=mp&s=160"},"body":"10.11.2011, в 16:15, Pitucha, Stanislaw Izaak:\n\n> Hi all,\n> 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).\n> \n> What I did is:\n> \n> checkout -b feature/....\n> (edit files and commit)\n> checkout master\n> merge --no-ff --no-commit feature/...\n> (edit some files, change versions, changelog)\n> commit\n> \n> Now I've got the change committed in the branch and some more changes on the merge commit.\n> So before pushing to the main repo, I'd like to check if any other changes are there:\n> \n> pull --rebase\n> \n> 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.\n> 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.\n> \n\nThat is definitely not a bug. \n\"git pull --rebase\" is (almost?) equal to \"git fetch ; git rebase origin/master\"\nWhen 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.\n\nOf 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.\n\nAnd the merge commit \"dissapeared\", because it contained no changes, so the patch was empty, and there was nothing to reapply.\nIf 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.\n\nIf you want to preserve your branch history, you should do \"pull\" without \"rebase\".\n\nKirill.\n"},{"id":"179303","messageId":"4EBCC71D.6000505@viscovery.net","threadId":"28906","inReplyTo":"3FF1328CB05DB74898F769F1BA17812C3E49B74699@GVW1348EXA.americas.hpqcorp.net","subject":"Re: Disappearing change on pull rebase","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-11-11T06:56:29Z","receivedAt":"2011-11-11T06:56:29Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 11/10/2011 14:35, schrieb Pitucha, Stanislaw Izaak:\n> As mentioned in the original mail - the merge commit did have changes.\n> Here's the log of reproducing it. The line containing \"2\" in changelog\n> is gone from master after pull --rebase.\n> ...\n> disappearing_commit$ git merge --no-ff --no-commit some-branch\n> Automatic merge went well; stopped before committing as requested\n> disappearing_commit$ echo 2 >> changelog \n> disappearing_commit$ git add changelog\n> disappearing_commit$ git commit\n> [master e41e4c9] Merge branch 'some-branch'\n\nThis is by design. Rebase does not rebase merge commits because it is\nassumed that merge commits only do what their name implies - to merge\nbranches of a forked history. As such, they do not introduce their own\nchanges. Follow this rule, i.e., make your change in a separate non-merge\ncommit, and you are fine.\n\n-- Hannes\n"},{"id":"179305","messageId":"CAGK7Mr6D6-4aNceTDCYTHabA3vnxh+uvQ=GOeS_3nrL9rjmc9w@mail.gmail.com","threadId":"28906","inReplyTo":"4EBCC71D.6000505@viscovery.net","subject":"Re: Disappearing change on pull rebase","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-11-11T09:50:16Z","receivedAt":"2011-11-11T09:50:16Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> This is by design. Rebase does not rebase merge commits because it is\n> assumed that merge commits only do what their name implies - to merge\n> branches of a forked history. As such, they do not introduce their own\n> changes. Follow this rule, i.e., make your change in a separate non-merge\n> commit, and you are fine.\n\nDoesn't this create a problem if you pull, resolve a conflit but do NOT\npush, then pull --rebase some more commits later on? As I understand\nit, the conflict resolution commit will be a merge commit and will be\nthrown away by the git pull --rebase.\n\nPhilippe\n"},{"id":"179306","messageId":"4EBCF34A.3090908@viscovery.net","threadId":"28906","inReplyTo":"CAGK7Mr6D6-4aNceTDCYTHabA3vnxh+uvQ=GOeS_3nrL9rjmc9w@mail.gmail.com","subject":"Re: Disappearing change on pull rebase","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-11-11T10:04:58Z","receivedAt":"2011-11-11T10:04:58Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 11/11/2011 10:50, schrieb Philippe Vaucher:\n>> This is by design. Rebase does not rebase merge commits because it is\n>> assumed that merge commits only do what their name implies - to merge\n>> branches of a forked history. As such, they do not introduce their own\n>> changes. Follow this rule, i.e., make your change in a separate non-merge\n>> commit, and you are fine.\n> \n> Doesn't this create a problem if you pull, resolve a conflit but do NOT\n> push, then pull --rebase some more commits later on? As I understand\n> it, the conflict resolution commit will be a merge commit and will be\n> thrown away by the git pull --rebase.\n\nYou are correct, but it is not a problem: During the rebase, the same\nconflicts will arise as during the merge, and you will be forced to\nresolve them before you can complete the rebase. Therefore, nothing will\nbe lost.\n\n-- Hannes\n"},{"id":"179307","messageId":"CAGK7Mr6GHNXLCaP94-peUd2TgBn16boLDVKkniPi-=p_WdV7LA@mail.gmail.com","threadId":"28906","inReplyTo":"4EBCF34A.3090908@viscovery.net","subject":"Re: Disappearing change on pull rebase","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-11-11T10:08:16Z","receivedAt":"2011-11-11T10:08:16Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> Doesn't this create a problem if you pull, resolve a conflit but do NOT\n>> push, then pull --rebase some more commits later on? As I understand\n>> it, the conflict resolution commit will be a merge commit and will be\n>> thrown away by the git pull --rebase.\n>\n> You are correct, but it is not a problem: During the rebase, the same\n> conflicts will arise as during the merge, and you will be forced to\n> resolve them before you can complete the rebase. Therefore, nothing will\n> be lost.\n\nDoing the same conflict resolution twice is kinda irritating... but\nok, fair enough.\nI guess when you resolve a conflict you're supposed to push to avoid this :)\n\nPhilippe\n"},{"id":"179319","messageId":"7vzkg2r56y.fsf@alter.siamese.dyndns.org","threadId":"28906","inReplyTo":"4EBCC71D.6000505@viscovery.net","subject":"Re: Disappearing change on pull rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-11T16:31:49Z","receivedAt":"2011-11-11T16:31:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Am 11/10/2011 14:35, schrieb Pitucha, Stanislaw Izaak:\n>> As mentioned in the original mail - the merge commit did have changes.\n>> Here's the log of reproducing it. The line containing \"2\" in changelog\n>> is gone from master after pull --rebase.\n>> ...\n>> disappearing_commit$ git merge --no-ff --no-commit some-branch\n>> Automatic merge went well; stopped before committing as requested\n>> disappearing_commit$ echo 2 >> changelog \n>> disappearing_commit$ git add changelog\n>> disappearing_commit$ git commit\n>> [master e41e4c9] Merge branch 'some-branch'\n>\n> This is by design. Rebase does not rebase merge commits because it is\n> assumed that merge commits only do what their name implies - to merge\n> branches of a forked history. As such, they do not introduce their own\n> changes. Follow this rule, i.e., make your change in a separate non-merge\n> commit, and you are fine.\n\nWhile that may be technically correct, I wonder if we can be a bit more\nhelpful to the users in such a case (upfront I admit that I have a strong\nsuspicion that this is a hard problem in general). One typical use of\n\"rebase\" is to linearize a history that has unfortunate merges that did\nnot have to be there, so refusing \"git rebase A..B\" when there is a merge\nin \"git rev-list --merges A..B\" is not a solution. But would it help if we\nwarned about the merges when we find that there is something _interesting_\ngoing on in them, e.g. an evil merge that adds material that did not exist\nin any of the parents [*1*]? The warning message may diagnose \"you asked\nme to linearize the history by picking commits on the non-merge segments\nand replaying them, but there may be changes made in this merge commit,\nand it does this interesting thing: $(git show -c $that_merge_commit)\" and\nmay further suggest \"if you do not want to linearize but just transplant\nthe history, perhaps you want to run the command with the '-m' option?\".\n\n[Footnote]\n\n*1* This is a hard problem and not just the matter of looking at \"show -c\"\noutput. A \"-s ours\" merge would appear empty in \"show -c\" but it _is_ an\ninteresting event that makes the result of linearizing non-merge segments\nvastly different from the original. Also material that did not exist in\nany of the parents is not necessarily evil (e.g. the side branch may have\nadded one parameter to a function and updated its call sites, while our\nbranch may have added a different parameter to the same function. The\nupdate to the call sites in the merge result should pass two more parameters\nfrom the common ancestor, and different from either of the parents).\n"}]}