{"thread":{"id":"6180","subject":"[RFC/PATCH] fail pull/merge early in the middle of conflicted merge","startedAt":"2007-01-01T07:21:50Z","lastAt":"2007-01-04T15:37:56Z","messageCount":4,"participants":["Junio C Hamano","Shawn O. Pearce","Andreas Ericsson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"30610","messageId":"7vwt478b5d.fsf@assigned-by-dhcp.cox.net","threadId":"6180","inReplyTo":null,"subject":"[RFC/PATCH] fail pull/merge early in the middle of conflicted merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T07:21:50Z","receivedAt":"2007-01-01T07:21:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"After a pull that results in a conflicted merge, a new user\noften tries another \"git pull\" in desperation. When the index\nis unmerged, merge backends correctly bail out without touching\neither index nor the working tree, so this does not make the\nwound any worse.\n\nThe user will however see several lines of messsages during this\nprocess, such as \"filename: needs merge\", \"you need to resolve\nyour current index first\", \"Merging...\", and \"Entry ... would be\noverwritten by merge. Cannot merge.\". They are unnecessarily\nalarming, and makes useful conflict messages from the first pull\nscroll off the top of the terminal.\n\nThis changes pull and merge to run \"git-ls-files -u\" upfront and\nstop them much earlier than we currently do.\n\nOld timers may know better and would not to try pulling again\nbefore cleaning things up; this change adds extra overhead that\nis unnecessary for them. But this would be worth paying for to\nsave new people from needless confusion.\n\nSigned-off-by: Junio C Hamano \n---\n\n * I've seen some people on #git channel got totally confused\n after a conflicted merge at least three times, and they paste\n the diagnostics from the second and subsequent pull, assuming\n that the messages would help diagnosing the situation in any\n way (unfortunately they typically don't). But it is not the\n user's fault not to know it. With this what they can give us\n when asking for help will only be from the first pull. In a\n sense, the real motivation of this patch is to make life\n easier for people who want to help these new people.\n\n git-merge.sh | 3 +++\n git-pull.sh | 3 +++\n 2 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex ba42260..f43fa69 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -8,6 +8,9 @@ USAGE='[-n] [--no-commit] [--squash] [-s ] [-m=] Old timers may know better and would not to try pulling again\n> before cleaning things up; this change adds extra overhead that\n> is unnecessary for them. But this would be worth paying for to\n> save new people from needless confusion.\n\nThis penalty isn't very high though; its just a single pass through\nthe index to look for an unmerged entry. I think that small\npenalty is worth the better error message here, and that's the guy\nwho just submitted patches to remove other penalties in pull and\nmerge talking. :-)\n\n-- \nShawn.\n"},{"id":"30689","messageId":"7vmz51usqf.fsf@assigned-by-dhcp.cox.net","threadId":"6180","inReplyTo":"20070101204354.GA26687@spearce.org","subject":"Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T19:35:36Z","receivedAt":"2007-01-02T19:35:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Junio C Hamano wrote:\n>> After a pull that results in a conflicted merge, a new user\n>> often tries another \"git pull\" in desperation. When the index\n>> is unmerged, merge backends correctly bail out without touching\n>> either index nor the working tree, so this does not make the\n>> wound any worse.\n>\n> I've seen this many times too. I don't understand why users cannot\n> read output messages and realize the current command failed, but\n> they don't. *sigh*\n\nThat is not user's fault. Tools should not make things worse\nwhen run more than once after they failed, and we do not either,\nso it is not a stupid behaviour on the user's part to do that.\n\nWe just need to make sure that it is more clear to the user that\npull after a conflicted pull is futile, which is what this patch\ndoes.\n"},{"id":"30817","messageId":"459D1F54.1060709@op5.se","threadId":"6180","inReplyTo":"7vmz51usqf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-04T15:37:56Z","receivedAt":"2007-01-04T15:37:56Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n>> Junio C Hamano wrote:\n>>> After a pull that results in a conflicted merge, a new user\n>>> often tries another \"git pull\" in desperation. When the index\n>>> is unmerged, merge backends correctly bail out without touching\n>>> either index nor the working tree, so this does not make the\n>>> wound any worse.\n>> I've seen this many times too. I don't understand why users cannot\n>> read output messages and realize the current command failed, but\n>> they don't. *sigh*\n> \n> That is not user's fault. Tools should not make things worse\n> when run more than once after they failed, and we do not either,\n> so it is not a stupid behaviour on the user's part to do that.\n> \n> We just need to make sure that it is more clear to the user that\n> pull after a conflicted pull is futile, which is what this patch\n> does.\n> \n\n\"Pulling is futile. Nothing will be assimilated\" ?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}