{"thread":{"id":"55161","subject":"Considering merge --dry-run to foresee conflicts ahead of time","startedAt":"2021-02-17T17:23:25Z","lastAt":"2021-02-20T00:00:43Z","messageCount":4,"participants":["Alireza","Konstantin Tokarev","brian m. carlson","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"417163","messageId":"CAD9n_qiN+qXqR79z_4d+_8_mxa9eTFB42sTUT8CTF8=oQArQaA@mail.gmail.com","threadId":"55161","inReplyTo":null,"subject":"Considering merge --dry-run to foresee conflicts ahead of time","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2021-02-17T17:21:45Z","receivedAt":"2021-02-17T17:23:25Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"I have a half baked alias for this and it proved to be extremely\nuseful even in this state.\n\n```\ncheck = \"!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git\nmerge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n\n\\\"/+<<<<<<< .our/,/+>>>>>>> .their/p\\\"; }; f\"\n```\n\nOf course with large conflicts it gets less useful. Getting only file\nnames from the patch isn't straightforward either.\n\nSo my question is what are the downsides to introducing a `merge\n--dry-run` option and what would it look like?\n"},{"id":"417171","messageId":"526751613587054@mail.yandex.ru","threadId":"55161","inReplyTo":"CAD9n_qiN+qXqR79z_4d+_8_mxa9eTFB42sTUT8CTF8=oQArQaA@mail.gmail.com","subject":"Re: Considering merge --dry-run to foresee conflicts ahead of time","fromName":"Konstantin Tokarev","fromEmail":"annulen@yandex.ru","sentAt":"2021-02-17T18:39:47Z","receivedAt":"2021-02-17T18:42:26Z","isPatch":false,"sender":{"key":"annulen@yandex.ru","avatar":null},"body":"\n\n17.02.2021, 20:25, \"Alireza\" :\n> I have a half baked alias for this and it proved to be extremely\n> useful even in this state.\n>\n> ```\n> check = \"!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git\n> merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n\n> \\\"/+<<<<<<< .our/,/+>>>>>>> .their/p\\\"; }; f\"\n> ```\n>\n> Of course with large conflicts it gets less useful. Getting only file\n> names from the patch isn't straightforward either.\n>\n> So my question is what are the downsides to introducing a `merge\n> --dry-run` option and what would it look like?\n\nAs a git user, I would very much welcome this addition, and similar for cherry-pick,\nprovided they don't modify any files in working copy.\n\n\n-- \nRegards,\nKonstantin\n"},{"id":"417421","messageId":"YDA6+vm6GPQL3Jec@camp.crustytoothpaste.net","threadId":"55161","inReplyTo":"CAD9n_qiN+qXqR79z_4d+_8_mxa9eTFB42sTUT8CTF8=oQArQaA@mail.gmail.com","subject":"Re: Considering merge --dry-run to foresee conflicts ahead of time","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-02-19T22:26:02Z","receivedAt":"2021-02-19T22:27:37Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-02-17 at 17:21:45, Alireza wrote:\n> I have a half baked alias for this and it proved to be extremely\n> useful even in this state.\n> \n> ```\n> check = \"!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git\n> merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n\n> \\\"/+<<<<<<< .our/,/+>>>>>>> .their/p\\\"; }; f\"\n> ```\n> \n> Of course with large conflicts it gets less useful. Getting only file\n> names from the patch isn't straightforward either.\n> \n> So my question is what are the downsides to introducing a `merge\n> --dry-run` option and what would it look like?\n\nThere aren't really any, but the current implementation of the merge\ncode makes it non-trivial, since it writes directly into the working\ntree. The new merge-ort code that Elijah Newren (CC'd) is working on\nshould at least support writing conflicts only into the index, and if\nyou didn't want to dirty the existing index, you could create a\ntemporary one with GIT_INDEX_FILE and write to that. It may also\nsupport a dry-run mode natively, but I'm not following it closely enough\nto say. Hopefully Elijah can say a little bit more about things.\n\nIn the mean time, since this is a frequently requested feature, I have a\nRust-based tool called git test-merge[0] that runs a test merge between\ntwo arbitrary trees and determines whether it succeeds or fails. It\nuses libgit2 under the hood.\n\n[0] https://github.com/bk2204/scutiger\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"417423","messageId":"CABPp-BH4F5zHmrX9C=CsnAKhcDr=KS1Rco4EXR-RSOfEnbFjQQ@mail.gmail.com","threadId":"55161","inReplyTo":"YDA6+vm6GPQL3Jec@camp.crustytoothpaste.net","subject":"Re: Considering merge --dry-run to foresee conflicts ahead of time","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-02-19T23:59:33Z","receivedAt":"2021-02-20T00:00:43Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Feb 19, 2021 at 2:26 PM brian m. carlson\n wrote:\n>\n> On 2021-02-17 at 17:21:45, Alireza wrote:\n> > I have a half baked alias for this and it proved to be extremely\n> > useful even in this state.\n> >\n> > ```\n> > check = \"!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git\n> > merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n\n> > \\\"/+<<<<<<< .our/,/+>>>>>>> .their/p\\\"; }; f\"\n> > ```\n> >\n> > Of course with large conflicts it gets less useful. Getting only file\n> > names from the patch isn't straightforward either.\n> >\n> > So my question is what are the downsides to introducing a `merge\n> > --dry-run` option and what would it look like?\n>\n> There aren't really any, but the current implementation of the merge\n> code makes it non-trivial, since it writes directly into the working\n> tree. The new merge-ort code that Elijah Newren (CC'd) is working on\n> should at least support writing conflicts only into the index, and if\n> you didn't want to dirty the existing index, you could create a\n> temporary one with GIT_INDEX_FILE and write to that. It may also\n> support a dry-run mode natively, but I'm not following it closely enough\n> to say. Hopefully Elijah can say a little bit more about things.\n>\n> In the mean time, since this is a frequently requested feature, I have a\n> Rust-based tool called git test-merge[0] that runs a test merge between\n> two arbitrary trees and determines whether it succeeds or fails. It\n> uses libgit2 under the hood.\n\nI don't have that exact feature implemented, but I've got something\nthat could easily be reused to provide this functionality. In my\nremerge-diff branch, I've got a --remerge-diff option for log (and\nshow), that for any merge commit will redo the merge in-memory (not\ntouching the working copy or index), and then show the diff between\nthat result (possibly including conflict markers) and what was\nactually recorded in the merge. If the merge was clean and the user\ndidn't amend any changes into the merge commit, then the diff will be\nempty. If the user moved around files, added changes, or just ripped\nout conflict markers, then you see all that in the diff.\n\nOne could use the same logic to make a merge --dry-run option that\nwould show the diff between the commit before merging and the\nauto-merged state. It probably wouldn't even be all that much code;\nmay half a day's worth of work.\n\nBut, it does rely on getting merge-ort reviewed and merged. We're 6\nmonths into that process so far. I was hoping we'd finish it before\ngit-2.32 is released (note that git-2.31 isn't released yet either),\nbut right now git-2.33 is looking more probable. See\nhttps://lore.kernel.org/git/pull.844.git.1613289544.gitgitgadget@gmail.com/\nand https://github.com/gitgitgadget/git/pulls?q=is%3Apr+author%3Anewren+Optimization+batch\nif you'd like to help review and/or test the portions that are ready\nfor review. (Or try the 'ort' or 'remerge-diff' branches of\nhttps://github.com/newren/git if you want to try out the full set of\nchanges, including bits that haven't been nicely broken up in\npreparation for upstream review.)\n"}]}