{"thread":{"id":"55373","subject":"Query on managing the order of commits in git merge","startedAt":"2021-03-23T18:35:43Z","lastAt":"2021-03-23T19:05:09Z","messageCount":2,"participants":["Linu Cherian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"420054","messageId":"CAAHhmWjLAO7EBEvcizFd1otDJDq8yesaA3FyDEYPWpuSLuy=Kw@mail.gmail.com","threadId":"55373","inReplyTo":null,"subject":"Query on managing the order of commits in git merge","fromName":"Linu Cherian","fromEmail":"linuc.decode@gmail.com","sentAt":"2021-03-23T18:34:49Z","receivedAt":"2021-03-23T18:35:43Z","isPatch":false,"sender":{"key":"linuc.decode@gmail.com","avatar":null},"body":"Hi,\n\nHad a query related to the order of commits in the command, git merge.\n\nLets say, we have a local branch(say A) tracking a remote upstream branch,.\n\nA has the following commits,\nA ---> 1---2---3--4\n\nWe do have another branch B, which is forked out of A and our\nfeatures/fixes has been added\non top of A.\nB ---->1 --2--3--4--5--6\n\n\nAt a later stage, we sync branch A to the remote upstream branch\nand it becomes,\nA --> 1--2--3--4--7--8\n\nNow, when we merge A to B, the order in which the commits are merged\ninto can be different based on date of commit. CMIIW\n\nLike, case 1:\n\nB --> 1--2--3--4--5--6--7--8--M\n\ncase 2:\n\nB-->1--2--3--4--7--8--5--6--M\n\nwhere M is the merge commit.\n\nThe query is, do we have control over in what order the patches gets\nmerged into B.\nTo be specific, is it possible to ensure that the local changes 5 & 6\nis always on top of A,\nwithout affecting the commit ids(ie. case 2 above).\n\nWe are not considering the option of git rebase, since it alters the commit ids.\nAppreciate your thoughts on this.\n\nThanks.\n"},{"id":"420056","messageId":"xmqqft0l3d5j.fsf@gitster.g","threadId":"55373","inReplyTo":"CAAHhmWjLAO7EBEvcizFd1otDJDq8yesaA3FyDEYPWpuSLuy=Kw@mail.gmail.com","subject":"Re: Query on managing the order of commits in git merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-03-23T19:04:08Z","receivedAt":"2021-03-23T19:05:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linu Cherian <linuc.decode@gmail.com> writes:\n\n> A has the following commits,\n> A ---> 1---2---3--4\n>\n> We do have another branch B, which is forked out of A and our\n> features/fixes has been added\n> on top of A.\n> B ---->1 --2--3--4--5--6\n>\n>\n> At a later stage, we sync branch A to the remote upstream branch\n> and it becomes,\n> A --> 1--2--3--4--7--8\n>\n> Now, when we merge A to B, the order in which the commits are merged\n> into can be different based on date of commit. CMIIW\n>\n> Like, case 1:\n>\n> B --> 1--2--3--4--5--6--7--8--M\n>\n> case 2:\n>\n> B-->1--2--3--4--7--8--5--6--M\n>\n> where M is the merge commit.\n\nNeither is showing you made a merge.  If you try gitk (or \"git log\n--oneline --graph\"), you'll see that a merge does not result in a\nsingle strand of pearls like the above.\n\nI think your merge is working perfectly correctly, without\nbutchering the order each branch had its commits, and adding a\nsingle merge commit 'M' that is a child of the commits at the tip of\nthese two branches.  It's just the order of commits you see when you\ntell the tool to show them linearly (e.g. \"log\" without \"--graph\").\n\nThere are \"--topo-order\" etc. options that you can influence the\ndisplay order of the \"log\" output.\n\n\n"}]}