{"thread":{"id":"50050","subject":"Can git tell me which uncommitted files clash with the incoming changes?","startedAt":"2018-12-17T13:09:04Z","lastAt":"2018-12-18T15:51:53Z","messageCount":10,"participants":["Mark Kharitonov","Jeff King","Duy Nguyen","Elijah Newren","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"365477","messageId":"CAG2YSPzmN5u1uAPVbjsqC3LzVVinFR21-_6wfrkBHdPWhOfMfQ@mail.gmail.com","threadId":"50050","inReplyTo":null,"subject":"Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Mark Kharitonov","fromEmail":"mark.kharitonov@gmail.com","sentAt":"2018-12-17T13:08:49Z","receivedAt":"2018-12-17T13:09:04Z","isPatch":false,"sender":{"key":"mark.kharitonov@gmail.com","avatar":"https://gravatar.com/avatar/ebee0a786b7cfc7a49e9d93b057b6fc3f62c01f916755f2c26e67ec8c2b2652c?d=mp&s=160"},"body":"Hi,\nI have asked this question on SO\n(https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)\nand usually there are tons of responses on Git questions, but not on\nthis one.\n\nAllow me to quote it now.\n\nPlease, observe:\n\n C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n error: Your local changes to the following files would be\noverwritten by merge:\n 2.txt\n Please commit your changes or stash them before you merge.\n Aborting\n Updating 2dc8bd0..ea343f8\n C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n\nDoes git have a command that can tell me which uncommitted files cause\nthe this error? I can see them displayed by git pull, but I really do\nnot want to parse git pull output.\n\nI am fully aware of `pull.rebase` and `rebase.autostash` config\noptions, please do not bring them up.\n\n**EDIT 1**\n\nIt is OK to execute `git pull` first. In fact, the logic to identify\nthe problematic files will be done after `git pull` fails with this\nreason. The way I recognize it in Powershell is:\n\n git pull\n # Possible exit codes:\n # 1 - either local changes or pull merge conflict (but the merge\nhas not been started yet)\n # 128 - a merge is in progress\n if ($LASTEXITCODE)\n {\n git merge HEAD 2> $null # Disambiguate\nthe exit code\n if ($LASTEXITCODE -eq 128)\n {\n # Two options:\n # - pull merge conflict\n # - a merge is in progress\n git mergetool\n }\n else\n {\n throw \"Cannot pull due to uncommitted changes\"\n }\n }\n\nSo, instead of aborting I would like to identify the problematic files\nand essentially replicate the `rebase.autostash`, but without\n`rebase`.\n\n**EDIT 2**\n\nI used to think that git pull outputs something like this in case of\nclashes with uncommitted changes:\n\n C:\\xyz\\test [master ↓4 ↑1 +0 ~3 -0 !]> git pull\n error: Your local changes to the following files would be\noverwritten by merge:\n 2.txt\n a.txt\n Please commit your changes or stash them before you merge.\n Aborting\n C:\\xyz\\test [master ↓4 ↑1 +0 ~3 -0 !]>\n\nWhich is easy to parse. But today, I got something different:\n\n C:\\xyz\\test [master ↓4 ↑1 +0 ~2 -0 | +0 ~1 -0 !]> git pull\n error: Your local changes to the following files would be\noverwritten by merge:\n 1.txt a.txt\n C:\\xyz\\test [master ↓4 ↑1 +0 ~2 -0 | +0 ~1 -0 !]>\n\nI do not know if this has something to do with my Powershell console\nhaving gotten botched somehow or with some recent git update, which I\nhad installed automatically without noticing it.\n\n-- \nBe well and prosper.\n==============================\n\"There are two kinds of people.Those whose guns are loaded and those who dig.\"\n (\"The good, the bad and the ugly\")\nSo let us drink for our guns always be loaded.\n"},{"id":"365484","messageId":"20181217162108.GB914@sigill.intra.peff.net","threadId":"50050","inReplyTo":"CAG2YSPzmN5u1uAPVbjsqC3LzVVinFR21-_6wfrkBHdPWhOfMfQ@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-17T16:21:08Z","receivedAt":"2018-12-17T16:21:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2018 at 08:08:49AM -0500, Mark Kharitonov wrote:\n\n> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n> error: Your local changes to the following files would be\n> overwritten by merge:\n> 2.txt\n> Please commit your changes or stash them before you merge.\n> Aborting\n> Updating 2dc8bd0..ea343f8\n> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n> \n> Does git have a command that can tell me which uncommitted files cause\n> the this error? I can see them displayed by git pull, but I really do\n> not want to parse git pull output.\n\nThat message is generated by merge-recursive, I believe after it's\nfigured out which files would need to be touched.\n\nI don't offhand know of a way to get that _exact_ answer from another\nplumbing command. But in practice it would probably be reasonable to ask\nfor the diff between your current branch and what you plan to merge, and\ncross-reference that with the list of files with local changes.\n\nSomething like:\n\n git pull ;# this fails, but FETCH_HEAD is left over\n\n git diff-tree -z --name-only HEAD FETCH_HEAD >one\n git diff-index -z --name-only HEAD >two\n comm -z -12 one two\n\nwould work on Linux, but \"comm -z\" is not portable (and I suspect you\nmay not have comm at all on Windows). You can probably find a way to\nshow the common elements of the two lists using the scripting language\nof your choice.\n\nThe answer that gives will be overly broad (e.g., in a case where our\nlocal branch had touched file \"foo\" but other side had not, we'd\nconsider \"foo\" as a difference the two-point diff-tree, whereas a real\n3-way merge would realize that we'd keep our version of \"foo\"). But it\nmight be good enough for your purposes.\n\n-Peff\n"},{"id":"365485","messageId":"CACsJy8ANoiWfmLkmO9ACab5H+m2c2y5uhKBJzGNwwxcs9zV0wA@mail.gmail.com","threadId":"50050","inReplyTo":"CAG2YSPzmN5u1uAPVbjsqC3LzVVinFR21-_6wfrkBHdPWhOfMfQ@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-12-17T16:24:24Z","receivedAt":"2018-12-17T16:24:54Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov\n wrote:\n>\n> Hi,\n> I have asked this question on SO\n> (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)\n> and usually there are tons of responses on Git questions, but not on\n> this one.\n>\n> Allow me to quote it now.\n>\n> Please, observe:\n>\n> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n> error: Your local changes to the following files would be\n> overwritten by merge:\n> 2.txt\n> Please commit your changes or stash them before you merge.\n> Aborting\n> Updating 2dc8bd0..ea343f8\n> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n>\n> Does git have a command that can tell me which uncommitted files cause\n> the this error? I can see them displayed by git pull, but I really do\n> not want to parse git pull output.\n\nAssume that you have done \"git fetch origin\" (or whatever master's\nupstream is). Do\n\ngit diff --name-only HEAD origin/master\n\nYou get the list of files that will need to be updated. Do\n\ngit diff --name-only\n\nto get the list of files that have local changes. If this list shares\nsome paths with the first list, these paths will very likely cause\n\"git pull\" to abort.\n\nFor a better check, I think you need to do \"git read-tree -m\" by\nyourself (to a temporary index file with --index-output) then you can\nexamine that file and determine what file has changed compared to HEAD\n(and if the same file has local changes, git-pull will be aborted).\nYou may need to read more in read-tree man page.\n\nIdeally though, git-read-tree should be able to tell what paths are\nupdated in \"--dry-run -u\" mode. But I don't think it's supported yet.\n-- \nDuy\n"},{"id":"365487","messageId":"CABPp-BE9+qqVfccwzofD0qFecTGo2EjighNSu0vh-rF_8F5PoA@mail.gmail.com","threadId":"50050","inReplyTo":"CACsJy8ANoiWfmLkmO9ACab5H+m2c2y5uhKBJzGNwwxcs9zV0wA@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-12-17T17:17:46Z","receivedAt":"2018-12-17T17:18:01Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:\n>\n> On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov\n> wrote:\n> >\n> > Hi,\n> > I have asked this question on SO\n> > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)\n> > and usually there are tons of responses on Git questions, but not on\n> > this one.\n> >\n> > Allow me to quote it now.\n> >\n> > Please, observe:\n> >\n> > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n> > error: Your local changes to the following files would be\n> > overwritten by merge:\n> > 2.txt\n> > Please commit your changes or stash them before you merge.\n> > Aborting\n> > Updating 2dc8bd0..ea343f8\n> > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n> >\n> > Does git have a command that can tell me which uncommitted files cause\n> > the this error? I can see them displayed by git pull, but I really do\n> > not want to parse git pull output.\n>\n> Assume that you have done \"git fetch origin\" (or whatever master's\n> upstream is). Do\n>\n> git diff --name-only HEAD origin/master\n>\n> You get the list of files that will need to be updated. Do\n>\n> git diff --name-only\n\nAre you assuming that `git diff --cached --name-only` is empty? If it\nisn't, that alone will trigger a failure (unless using an esoteric\nmerge strategy or an older version of git), so this assumption is\nfairly reasonable to make. But it may be worth being explicit about\nfor external readers.\n\n> to get the list of files that have local changes. If this list shares\n> some paths with the first list, these paths will very likely cause\n> \"git pull\" to abort.\n>\n> For a better check, I think you need to do \"git read-tree -m\" by\n> yourself (to a temporary index file with --index-output) then you can\n> examine that file and determine what file has changed compared to HEAD\n> (and if the same file has local changes, git-pull will be aborted).\n> You may need to read more in read-tree man page.\n>\n> Ideally though, git-read-tree should be able to tell what paths are\n> updated in \"--dry-run -u\" mode. But I don't think it's supported yet.\n\nmerge-recursive currently uses unpack_trees to do this \"files would be\noverwritten by merge\" checking, so the suggestion of read-tree (which\nalso uses unpack_trees) makes sense. BUT ... the error checking in\nunpack_trees has both false positives and false negatives due to not\nunderstanding renames, and it is somewhat of a nightmarish mess. See\n[1] for details. Further, I think it warns in cases that shouldn't be\nneeded (both sides of history modified the same file, with the\nmodifications on HEAD's side being a superset of the changes on the\nother side, in such a way that 3-way content merge happens to match\nwhat is in HEAD already). So, while the suggestions made so far give\nsome useful approximations, it's an approximation that will get worse\nover time. I don't have a better approximation to provide at this\ntime, though.\n\n\nElijah\n\n[1] https://public-inbox.org/git/20171124195901.2581-1-newren@gmail.com/\n, starting at \"Note that unpack_trees() doesn't understand renames\"\nand running until \"4-way merges simply cause the complexity to\nincrease with every new capability.\"\n"},{"id":"365488","messageId":"877eg80z1f.fsf@evledraar.gmail.com","threadId":"50050","inReplyTo":"20181217162108.GB914@sigill.intra.peff.net","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-17T18:49:00Z","receivedAt":"2018-12-17T18:49:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Dec 17 2018, Jeff King wrote:\n\n> On Mon, Dec 17, 2018 at 08:08:49AM -0500, Mark Kharitonov wrote:\n>\n>> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n>> error: Your local changes to the following files would be\n>> overwritten by merge:\n>> 2.txt\n>> Please commit your changes or stash them before you merge.\n>> Aborting\n>> Updating 2dc8bd0..ea343f8\n>> C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n>>\n>> Does git have a command that can tell me which uncommitted files cause\n>> the this error? I can see them displayed by git pull, but I really do\n>> not want to parse git pull output.\n>\n> That message is generated by merge-recursive, I believe after it's\n> figured out which files would need to be touched.\n>\n> I don't offhand know of a way to get that _exact_ answer from another\n> plumbing command. But in practice it would probably be reasonable to ask\n> for the diff between your current branch and what you plan to merge, and\n> cross-reference that with the list of files with local changes.\n>\n> Something like:\n>\n> git pull ;# this fails, but FETCH_HEAD is left over\n>\n> git diff-tree -z --name-only HEAD FETCH_HEAD >one\n> git diff-index -z --name-only HEAD >two\n> comm -z -12 one two\n>\n> would work on Linux, but \"comm -z\" is not portable (and I suspect you\n> may not have comm at all on Windows). You can probably find a way to\n> show the common elements of the two lists using the scripting language\n> of your choice.\n>\n> The answer that gives will be overly broad (e.g., in a case where our\n> local branch had touched file \"foo\" but other side had not, we'd\n> consider \"foo\" as a difference the two-point diff-tree, whereas a real\n> 3-way merge would realize that we'd keep our version of \"foo\"). But it\n> might be good enough for your purposes.\n\nIsn't this done more simply with just running the merge with\ngit-merge-tree? Maybe I'm missing something. E.g. earlier I had a\nconflict between a WIP series of mine in next in\nparse-options-cb.c. Just using git-merge-tree and grepping for conflict\nmarkers gives me what conflicted:\n\n $ git merge-tree origin/master unconditional-abbrev-2 origin/next|grep -E -e '^(merged|changed in both| (base|our|their|result))' -e '^\\+======='\n [...]\n merged\n result 100644 d70c6d9afb94c77c285fe8ee3237f7a40867157a packfile.h\n our 100644 6c4037605d0dfee59a084c440506f1af11708d63 packfile.h\n changed in both\n base 100644 8c9edce52f63bcb1085b119b3a2264a97b1fb374 parse-options-cb.c\n our 100644 1afc11a9901dba25dc0f6151e5d9a7654b6e3192 parse-options-cb.c\n their 100644 e2f3eaed072f77d63890ec814d810199f57248d5 parse-options-cb.c\n +=======\n [...]\n\nOr more simply, you can \"grep -q\" for '^\\+=======' to ask \"does this\nconflict?\".\n"},{"id":"365489","messageId":"20181217193514.GB9853@sigill.intra.peff.net","threadId":"50050","inReplyTo":"877eg80z1f.fsf@evledraar.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-17T19:35:14Z","receivedAt":"2018-12-17T19:35:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2018 at 07:49:00PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> > The answer that gives will be overly broad (e.g., in a case where our\n> > local branch had touched file \"foo\" but other side had not, we'd\n> > consider \"foo\" as a difference the two-point diff-tree, whereas a real\n> > 3-way merge would realize that we'd keep our version of \"foo\"). But it\n> > might be good enough for your purposes.\n> \n> Isn't this done more simply with just running the merge with\n> git-merge-tree? Maybe I'm missing something. E.g. earlier I had a\n> conflict between a WIP series of mine in next in\n> parse-options-cb.c. Just using git-merge-tree and grepping for conflict\n> markers gives me what conflicted:\n\nI forgot about the existence of merge-tree (though TBH I don't have a\nhuge amount of faith in antique plumbing tools like that that very few\npeople actually run these days).\n\nIt won't look at the working tree at all, but it could be used instead\nof diff-tree to find the set of touched paths, and then that can be\ncorrelated with the diff-files output. We'd want to see all paths, not\njust conflicted ones, so you'd have to be a little fancy with the\nparsing.\n\nIt's also not _quite_ the same as what git-pull is doing to merge, since\nmerge-recursive does fancy stuff like renames. But the distinction would\nprobably be OK for casual use.\n\n-Peff\n"},{"id":"365490","messageId":"CACsJy8BFoK4hoXrSUi+P3xB1LumevvFe6XWAM2fLUq-UGNUs8A@mail.gmail.com","threadId":"50050","inReplyTo":"CABPp-BE9+qqVfccwzofD0qFecTGo2EjighNSu0vh-rF_8F5PoA@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-12-17T19:37:06Z","receivedAt":"2018-12-17T19:37:35Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren wrote:\n>\n> On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:\n> >\n> > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov\n> > wrote:\n> > >\n> > > Hi,\n> > > I have asked this question on SO\n> > > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)\n> > > and usually there are tons of responses on Git questions, but not on\n> > > this one.\n> > >\n> > > Allow me to quote it now.\n> > >\n> > > Please, observe:\n> > >\n> > > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n> > > error: Your local changes to the following files would be\n> > > overwritten by merge:\n> > > 2.txt\n> > > Please commit your changes or stash them before you merge.\n> > > Aborting\n> > > Updating 2dc8bd0..ea343f8\n> > > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n> > >\n> > > Does git have a command that can tell me which uncommitted files cause\n> > > the this error? I can see them displayed by git pull, but I really do\n> > > not want to parse git pull output.\n> >\n> > Assume that you have done \"git fetch origin\" (or whatever master's\n> > upstream is). Do\n> >\n> > git diff --name-only HEAD origin/master\n> >\n> > You get the list of files that will need to be updated. Do\n> >\n> > git diff --name-only\n>\n> Are you assuming that `git diff --cached --name-only` is empty? If it\n> isn't, that alone will trigger a failure (unless using an esoteric\n> merge strategy or an older version of git), so this assumption is\n> fairly reasonable to make. But it may be worth being explicit about\n> for external readers.\n\nActually I think Jeff's suggestion may be better since he compares\nworktree with HEAD and should catch everything.\n\n> > to get the list of files that have local changes. If this list shares\n> > some paths with the first list, these paths will very likely cause\n> > \"git pull\" to abort.\n> >\n> > For a better check, I think you need to do \"git read-tree -m\" by\n> > yourself (to a temporary index file with --index-output) then you can\n> > examine that file and determine what file has changed compared to HEAD\n> > (and if the same file has local changes, git-pull will be aborted).\n> > You may need to read more in read-tree man page.\n> >\n> > Ideally though, git-read-tree should be able to tell what paths are\n> > updated in \"--dry-run -u\" mode. But I don't think it's supported yet.\n>\n> merge-recursive currently uses unpack_trees to do this \"files would be\n> overwritten by merge\" checking, so the suggestion of read-tree (which\n> also uses unpack_trees) makes sense. BUT ... the error checking in\n> unpack_trees has both false positives and false negatives due to not\n> understanding renames, and it is somewhat of a nightmarish mess. See\n> [1] for details. Further, I think it warns in cases that shouldn't be\n> needed (both sides of history modified the same file, with the\n> modifications on HEAD's side being a superset of the changes on the\n> other side, in such a way that 3-way content merge happens to match\n> what is in HEAD already). So, while the suggestions made so far give\n> some useful approximations, it's an approximation that will get worse\n> over time.\n\nAh.. dang. I guess we need \"git merge --dry-run\" then :)\n\n> I don't have a better approximation to provide at this\n> time, though.\n>\n>\n> Elijah\n>\n> [1] https://public-inbox.org/git/20171124195901.2581-1-newren@gmail.com/\n> , starting at \"Note that unpack_trees() doesn't understand renames\"\n> and running until \"4-way merges simply cause the complexity to\n> increase with every new capability.\"\n\n\n\n-- \nDuy\n"},{"id":"365507","messageId":"CAG2YSPy85YtAv6m5WR4ZrsZ4TRzgcyrC4DNZnOONtFD6MsH=YQ@mail.gmail.com","threadId":"50050","inReplyTo":"CACsJy8BFoK4hoXrSUi+P3xB1LumevvFe6XWAM2fLUq-UGNUs8A@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Mark Kharitonov","fromEmail":"mark.kharitonov@gmail.com","sentAt":"2018-12-17T22:50:31Z","receivedAt":"2018-12-17T22:50:45Z","isPatch":false,"sender":{"key":"mark.kharitonov@gmail.com","avatar":"https://gravatar.com/avatar/ebee0a786b7cfc7a49e9d93b057b6fc3f62c01f916755f2c26e67ec8c2b2652c?d=mp&s=160"},"body":"Guys, having git merge --dry-run would be great, but I am OK with git\nmerge for real as long as its output is parseable.\n\nHowever, somewhere in between git 2.18 and git 2.20 the output of\nmerge changed and now I do not know how to parse it.\nit used to be something like that:\n\nbla bla bla\nfile name 1\nfile name 2\n...\nbla bla bla\n\nBut now, the files are output in one line and given that some files\nmay have spaces in the name I do not see how this can be parsed. If we\ncould have easily parseable output of merge, it would be enough for\nme.\n\n\nLe lun. 17 déc. 2018 à 14:37, Duy Nguyen a écrit :\n>\n> On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren wrote:\n> >\n> > On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:\n> > >\n> > > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov\n> > > wrote:\n> > > >\n> > > > Hi,\n> > > > I have asked this question on SO\n> > > > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)\n> > > > and usually there are tons of responses on Git questions, but not on\n> > > > this one.\n> > > >\n> > > > Allow me to quote it now.\n> > > >\n> > > > Please, observe:\n> > > >\n> > > > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]> git pull\n> > > > error: Your local changes to the following files would be\n> > > > overwritten by merge:\n> > > > 2.txt\n> > > > Please commit your changes or stash them before you merge.\n> > > > Aborting\n> > > > Updating 2dc8bd0..ea343f8\n> > > > C:\\Dayforce\\test [master ↓2 +0 ~2 -0 !]>\n> > > >\n> > > > Does git have a command that can tell me which uncommitted files cause\n> > > > the this error? I can see them displayed by git pull, but I really do\n> > > > not want to parse git pull output.\n> > >\n> > > Assume that you have done \"git fetch origin\" (or whatever master's\n> > > upstream is). Do\n> > >\n> > > git diff --name-only HEAD origin/master\n> > >\n> > > You get the list of files that will need to be updated. Do\n> > >\n> > > git diff --name-only\n> >\n> > Are you assuming that `git diff --cached --name-only` is empty? If it\n> > isn't, that alone will trigger a failure (unless using an esoteric\n> > merge strategy or an older version of git), so this assumption is\n> > fairly reasonable to make. But it may be worth being explicit about\n> > for external readers.\n>\n> Actually I think Jeff's suggestion may be better since he compares\n> worktree with HEAD and should catch everything.\n>\n> > > to get the list of files that have local changes. If this list shares\n> > > some paths with the first list, these paths will very likely cause\n> > > \"git pull\" to abort.\n> > >\n> > > For a better check, I think you need to do \"git read-tree -m\" by\n> > > yourself (to a temporary index file with --index-output) then you can\n> > > examine that file and determine what file has changed compared to HEAD\n> > > (and if the same file has local changes, git-pull will be aborted).\n> > > You may need to read more in read-tree man page.\n> > >\n> > > Ideally though, git-read-tree should be able to tell what paths are\n> > > updated in \"--dry-run -u\" mode. But I don't think it's supported yet.\n> >\n> > merge-recursive currently uses unpack_trees to do this \"files would be\n> > overwritten by merge\" checking, so the suggestion of read-tree (which\n> > also uses unpack_trees) makes sense. BUT ... the error checking in\n> > unpack_trees has both false positives and false negatives due to not\n> > understanding renames, and it is somewhat of a nightmarish mess. See\n> > [1] for details. Further, I think it warns in cases that shouldn't be\n> > needed (both sides of history modified the same file, with the\n> > modifications on HEAD's side being a superset of the changes on the\n> > other side, in such a way that 3-way content merge happens to match\n> > what is in HEAD already). So, while the suggestions made so far give\n> > some useful approximations, it's an approximation that will get worse\n> > over time.\n>\n> Ah.. dang. I guess we need \"git merge --dry-run\" then :)\n>\n> > I don't have a better approximation to provide at this\n> > time, though.\n> >\n> >\n> > Elijah\n> >\n> > [1] https://public-inbox.org/git/20171124195901.2581-1-newren@gmail.com/\n> > , starting at \"Note that unpack_trees() doesn't understand renames\"\n> > and running until \"4-way merges simply cause the complexity to\n> > increase with every new capability.\"\n>\n>\n>\n> --\n> Duy\n\n\n\n-- \nBe well and prosper.\n==============================\n\"There are two kinds of people.Those whose guns are loaded and those who dig.\"\n (\"The good, the bad and the ugly\")\nSo let us drink for our guns always be loaded.\n"},{"id":"365532","messageId":"20181218131429.GE30471@sigill.intra.peff.net","threadId":"50050","inReplyTo":"CAG2YSPy85YtAv6m5WR4ZrsZ4TRzgcyrC4DNZnOONtFD6MsH=YQ@mail.gmail.com","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-18T13:14:29Z","receivedAt":"2018-12-18T13:14:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:\n\n> Guys, having git merge --dry-run would be great, but I am OK with git\n> merge for real as long as its output is parseable.\n> \n> However, somewhere in between git 2.18 and git 2.20 the output of\n> merge changed and now I do not know how to parse it.\n> it used to be something like that:\n> \n> bla bla bla\n> file name 1\n> file name 2\n> ...\n> bla bla bla\n> \n> But now, the files are output in one line and given that some files\n> may have spaces in the name I do not see how this can be parsed. If we\n> could have easily parseable output of merge, it would be enough for\n> me.\n\nInteresting. I don't see that behavior at all. E.g., running this:\n\n-- >8 --\ngit init repo\ncd repo\n\necho base >base; git add base; git commit -m base\nfor i in one two three; do\n\techo $i >$i\ndone\ngit add .\ngit commit -m master\n\ngit checkout -b other HEAD^\necho other >other; git add other; git commit -m other\n\nfor i in one two three; do\n\techo working-tree >$i\ndone\n\ngit pull . master\n-- 8< --\n\nI see:\n\n error: The following untracked working tree files would be overwritten by merge:\n \tone\n \tthree\n \ttwo\n Please move or remove them before you merge.\n\nI wonder if it has to do with Windows.\n\nIf you can reproduce it at will, can you try bisecting between v2.18 and\nv2.20 to see which commit introduced the change?\n\n-Peff\n"},{"id":"365537","messageId":"CABPp-BG0Urp7aRfcsTAhmpWOR-8K5xuZc=5fGjpowgKw1C8X6Q@mail.gmail.com","threadId":"50050","inReplyTo":"20181218131429.GE30471@sigill.intra.peff.net","subject":"Re: Can git tell me which uncommitted files clash with the incoming changes?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-12-18T15:51:39Z","receivedAt":"2018-12-18T15:51:53Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Dec 18, 2018 at 5:14 AM Jeff King wrote:\n>\n> On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:\n>\n> > Guys, having git merge --dry-run would be great, but I am OK with git\n> > merge for real as long as its output is parseable.\n\nDon't rely on that. merge output has changed occasionally and will\nlikely change again in the future multiple times. The other solutions\nprovided by Peff and Duy are much better. If we need to add more\noptions to provide you with what you need, then that's a route we can\ntake, but I'll make no guarantees about merge output being stable and\nparseable.\n\nAll that said...\n\n> > However, somewhere in between git 2.18 and git 2.20 the output of\n> > merge changed and now I do not know how to parse it.\n> > it used to be something like that:\n> >\n> > bla bla bla\n> > file name 1\n> > file name 2\n> > ...\n> > bla bla bla\n> >\n> > But now, the files are output in one line and given that some files\n> > may have spaces in the name I do not see how this can be parsed. If we\n> > could have easily parseable output of merge, it would be enough for\n> > me.\n>\n> Interesting. I don't see that behavior at all. E.g., running this:\n>\n...\n> I see:\n>\n> error: The following untracked working tree files would be overwritten by merge:\n> one\n> three\n> two\n> Please move or remove them before you merge.\n>\n> I wonder if it has to do with Windows.\n>\n> If you can reproduce it at will, can you try bisecting between v2.18 and\n> v2.20 to see which commit introduced the change?\n>\n> -Peff\n\nI see the same as Peff, and I see no changes to\nunpack_trees.c:display_error_msgs() since git 2.11 (not even in a\nclone of git-for-windows), and as far as I can tell that function is\nthe place that prints all the files and adds the newlines, so I'm kind\nof perplexed how you're seeing things print multiple files on a line.\nBisecting as Peff suggests would help but I'm curious if there's\nsomething special about your setup needed to reproduce and which\nchanged since you were using 2.18 (e.g. always forcing output through\na pager and having a pager that doesn't understand LF and requires\nCRLF to display things correctly??)\n"}]}