<div dir="ltr"><div>Dear folks</div><div><br></div><div>Recently, Alex has been suggesting that commits in a feature branch (such as NFD management refactor, NDNLP implementation, etc) should not be merged until all commits are ready, and developers may start working on an unmerged parent commit.</div><div>This would require the developer to rebase their commits, if the parent commit changes.</div><div>I’m reluctant to do that, but prefers to wait for the parent commit to be merged before starting the next commit, because I had a lot of trouble in rebasing.</div><div><br></div><div>Specifically, my trouble starts with this situation:</div><div><ul><li>commit1 is already merged.<br></li><li>commit2a is an unmerged commit on Gerrit, which is based on commit1.<br></li><li>commit3 is the commit that I’m working on, which is based on commit2a.<br></li><li>Now commit2a is modified, and the new patchset is commit2b, whose parent is still commit1.<br></li><li>I want to rebase commit3 on top of commit2b.</li></ul></div><div>The situation can be re-created with the following git commands:</div><div><font face="monospace, monospace">git init</font></div><div><font face="monospace, monospace">touch file1</font></div><div><font face="monospace, monospace">git add file1</font></div><div><font face="monospace, monospace">git commit -m "commit1"</font></div><div><font face="monospace, monospace">git checkout -b branch2</font></div><div><font face="monospace, monospace">touch file2a</font></div><div><font face="monospace, monospace">git add file2a</font></div><div><font face="monospace, monospace">git commit -m "commit2a"</font></div><div><font face="monospace, monospace">git checkout -b branch3</font></div><div><font face="monospace, monospace">touch file3</font></div><div><font face="monospace, monospace">git add file3</font></div><div><font face="monospace, monospace">git commit -m "commit3"</font></div><div><font face="monospace, monospace">git checkout branch2</font></div><div><font face="monospace, monospace">git rm file2a</font></div><div><font face="monospace, monospace">touch file2b</font></div><div><font face="monospace, monospace">git add file2b</font></div><div><font face="monospace, monospace">git commit -a --amend -m "commit2b"</font></div><div><font face="monospace, monospace">git checkout branch3</font></div><div><font face="monospace, monospace">git rebase branch2</font></div><div><br></div><div>Expected: `git log branch3` shows commit1-commit2b-commit3</div><div>Actual: `git log branch3` shows commit1-commit2b-commit2a-commit3</div><div><br></div><div>git doesn't seem to recognize that commit2b is a replacement of commit2a, and therefore keeps both.<br></div><div><div>This happens only if there's no conflict between commit2a and commit2b.</div><div>When there's a conflict, git would tell me to run `git rebase --skip` which would give the correct results.</div></div><div><br></div><div>If Alex or another git guru can help me solve this problem, I would be happy to start using unmerged parent commits.</div><div><br></div><div>Yours, Junxiao</div></div>