{"thread":{"id":"55497","subject":"Why isn't 'jch' based on 'next'?","startedAt":"2021-04-15T09:12:08Z","lastAt":"2021-04-15T19:46:41Z","messageCount":3,"participants":["Denton Liu","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422013","messageId":"YHgDYl3cMx9+Hqa7@generichostname","threadId":"55497","inReplyTo":null,"subject":"Why isn't 'jch' based on 'next'?","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2021-04-15T09:12:02Z","receivedAt":"2021-04-15T09:12:08Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Junio,\n\nOut of curiosity, why is 'jch' not based on 'next' but instead, it\nrecreates the same merge commits on top of 'master'. What is the\nadvantage of this?\n\nThanks,\nDenton\n"},{"id":"422044","messageId":"xmqqlf9jqucm.fsf@gitster.g","threadId":"55497","inReplyTo":"YHgDYl3cMx9+Hqa7@generichostname","subject":"Re: Why isn't 'jch' based on 'next'?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-15T18:24:25Z","receivedAt":"2021-04-15T18:24:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu <liu.denton@gmail.com> writes:\n\n> Out of curiosity, why is 'jch' not based on 'next' but instead, it\n> recreates the same merge commits on top of 'master'. What is the\n> advantage of this?\n\nThe 'jch' point is merely a convenient \"I personally have no problem\nusing this tree\" point on 'seen', so I'll talk about 'seen'.\n\nIt is the second or third time I answer this exact question, and we\nshould add the answer to Documentation/howto/maintain-git.txt (or\nMaintNotes on the todo branch), perhaps.\n\nThe history of 'next' can become quite messy due to many reasons:\n\n - A topic that has already been merged to 'next' but not graduated\n   to 'master' may need some fix-up, in which case, 'next' will have\n   another merge of the same topic into it.\n\n - A mismerge of a topic into 'next' may be discovered long after it\n   happened, and a single-parent commit is made directly on 'next'\n   to correct it.\n\n - When 'master' advances, it is merged back to 'next'.\n\n - A topic that looked promising may turn out to be a bad idea and\n   the merge of the topic into 'next' get reverted out of 'next'.\n\n - A topic that looked nice may want to do a wholesale replacement,\n   not an incremental refinement, and a merge of the topic into\n   'next' get reverted and then the newer iteration of the topic\n   gets merged to 'next' (this last case is rare, but it sometimes\n   happens, like once every few cycles).\n\nBut we know which topic must be in 'next' all the time.  You can ask\n'seen' which ones they are:\n\n   $ git log --oneline --first-parent 'master..seen^{/^### match next}'\n\nSo if we reset 'seen' at 'master' and merge the tip of these topics\ninto it, the tree of the empty commit that is marked with \"### match\nnext\" marker should match the tree of 'next', or something is still\nwrong (most likely, a mismerge).  Also, the order topics are merged\ninto 'next' may not be necessarily the order they appear in 'seen'.\nEvery time I rebuild 'seen' from 'master', I have a chance to reorder\nthese topics so that the ones that are expected to graduate sooner\ncome near the bottom.\n\nBy ensuring \"### match next\" and 'next' matches, even though they\ncame to their trees in different route, I can spot a mismerge that\nis waiting to happen soon when a topic graduates to 'master'.\n"},{"id":"422051","messageId":"xmqq35vrqqjt.fsf@gitster.g","threadId":"55497","inReplyTo":"xmqqlf9jqucm.fsf@gitster.g","subject":"Re: Why isn't 'jch' based on 'next'?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-15T19:46:30Z","receivedAt":"2021-04-15T19:46:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> So if we reset 'seen' at 'master' and merge the tip of these topics\n> into it, the tree of the empty commit that is marked with \"### match\n> next\" marker should match the tree of 'next', or something is still\n> wrong (most likely, a mismerge).  Also, the order topics are merged\n> into 'next' may not be necessarily the order they appear in 'seen'.\n> Every time I rebuild 'seen' from 'master', I have a chance to reorder\n> these topics so that the ones that are expected to graduate sooner\n> come near the bottom.\n\nThis is so that I can \"git checkout seen~40\" (or whereever point\nthat has all the topics scheduled to be in 'master' and nothing\nelse) and run tests, to simulate what happens if these topics\ngraduate to 'master'.\n\n> By ensuring \"### match next\" and 'next' matches, even though they\n> came to their trees in different route, I can spot a mismerge that\n> is waiting to happen soon when a topic graduates to 'master'.\n"}]}