{"thread":{"id":"47458","subject":"Usability issue with rebase fork-point option","startedAt":"2017-12-18T15:48:02Z","lastAt":"2017-12-18T18:54:57Z","messageCount":2,"participants":["Robert Dailey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"334968","messageId":"CAHd499BwrEAxoGX++xRJz_p-_7Uh7vm=+FstRbCv1+wqeCiYbw@mail.gmail.com","threadId":"47458","inReplyTo":null,"subject":"Usability issue with rebase fork-point option","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-12-18T15:47:54Z","receivedAt":"2017-12-18T15:48:02Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"When upstream is not specified for the rebase command (e.g. I just do\n`git rebase`), `--fork-point` is assumed which results in commits\nregenerating SHA1 even if the merge-base would otherwise be identical.\n\nHere's my scenario:\n\nI set my remote tracking branch to my parent branch:\n\n$ git branch -u origin\n\nI do a status to see that I'm 1 ahead:\n\n$ git status -sb\n## feature/foo...origin/master [ahead 1]\n\nI then execute `git rebase`:\n\n$ git rebase\nFirst, rewinding head to replay your work on top of it...\nApplying: Fix state machine hang after integrity checking\n\nSince my merge-base is already the tip of `origin/master`, I expected\nit to say it was up-to-date, as it would if I disabled fork point:\n\n$ git rebase --no-fork-point\nCurrent branch feature/foo is up to date.\n\n\nThe expected behavior is that if merge-base does not change, even with\n--fork-point enabled, that SHA1's do not get rewritten.\n\nAs a workaround, I've created an alias that always assumes --no-fork-point:\n\n[alias]\n    rb = rebase --no-fork-point\n\n\nPossible long term solutions I'd be happy with:\n\n1. A config option to disable fork point completely, something like\n`rebase.forkPoint` and I can set it to `false`.\n2. Change rebase to always assume `--no-fork-point` as a default,\nwhich is opposite of the current behavior.\n3. Assuming the behavior I'm observing is a bug, put more priority on\na matching merge-base instead of the reflogs, not sure of the\ninternals of how this fork-point behavior is implemented, but this\nfeels like the issue to me. The most ideal outcome is that this is a\nbug and no interface or config changes are needed.\n\nWould love to get feedback from the Git community on this. Thanks for reading!!\n"},{"id":"334985","messageId":"xmqqbmivyih1.fsf@gitster.mtv.corp.google.com","threadId":"47458","inReplyTo":"CAHd499BwrEAxoGX++xRJz_p-_7Uh7vm=+FstRbCv1+wqeCiYbw@mail.gmail.com","subject":"Re: Usability issue with rebase fork-point option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-18T18:54:50Z","receivedAt":"2017-12-18T18:54:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Dailey <rcdailey.lists@gmail.com> writes:\n\n> $ git rebase\n> First, rewinding head to replay your work on top of it...\n> Applying: Fix state machine hang after integrity checking\n>\n> Since my merge-base is already the tip of `origin/master`, I expected\n> it to say it was up-to-date, as it would if I disabled fork point:\n>\n> $ git rebase --no-fork-point\n> Current branch feature/foo is up to date.\n\nI haven't studied the symptom deeply enough but I have a feeling\nthat hunk @@ -572,7 +573,7 @@ in 1e0dacdb (\"rebase: omit\npatch-identical commits with --fork-point\", 2014-07-16) may be what\ngoes wrong.  I do not offhand see why the \"already up to date\" check\nneed to be bypassed when fork-point mode is in use, and the log\nmessage of the commit does not explain the reason behind that\nchange, either.\n\nI wonder what happens if we simply enabled the \"avoid unnecessary\nrebase if we are already up to date\" check even when $restrict_revision\nis not empty.\n"}]}