{"thread":{"id":"43480","subject":"RE: [PATCH] git-explain","startedAt":"2006-12-05T03:55:49Z","lastAt":"2006-12-05T21:00:10Z","messageCount":7,"participants":["Raimund Bauer","Junio C Hamano","Nicolas Pitre","J. Bruce Fields","Jeff King","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"296136","messageId":"Pine.LNX.4.64.0612042253250.2630@xanadu.home","threadId":"43480","inReplyTo":"7vwt57j94c.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-explain","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-05T03:55:49Z","receivedAt":"2006-12-05T03:55:49Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 4 Dec 2006, Junio C Hamano wrote:\n\n> [PATCH] git-explain\n> \n> This patch adds \"git-explain\" script that notices various clues\n> other commands can leave the working tree and repository in and\n> intended to guide the end user out of the confused mess.\n\nWhat about calling it git-whatsup instead?\n\n\n"},{"id":"296701","messageId":"20061205035721.GA26735@fieldses.org","threadId":"43480","inReplyTo":"Pine.LNX.4.64.0612042253250.2630@xanadu.home","subject":"Re: [PATCH] git-explain","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-05T03:57:21Z","receivedAt":"2006-12-05T03:57:21Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:\n> On Mon, 4 Dec 2006, Junio C Hamano wrote:\n> \n> > [PATCH] git-explain\n> > \n> > This patch adds \"git-explain\" script that notices various clues\n> > other commands can leave the working tree and repository in and\n> > intended to guide the end user out of the confused mess.\n> \n> What about calling it git-whatsup instead?\n\nNo, clearly it should be git-wtf.\n\n"},{"id":"295834","messageId":"7v1wnekh6a.fsf@assigned-by-dhcp.cox.net","threadId":"43480","inReplyTo":"20061205035721.GA26735@fieldses.org","subject":"Re: [PATCH] git-explain","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T06:09:17Z","receivedAt":"2006-12-05T06:09:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:\n>> ...\n>> > [PATCH] git-explain\n>> > ...\n>> \n>> What about calling it git-whatsup instead?\n>\n> No, clearly it should be git-wtf.\n\nShould I take these responses to mean that you two are negative\nabout the approach of spending extra cycles to commands that can\nleave the working tree in a \"in the middle of doing something\"\nstate to help having a unified command to explain what the\nsituation is and suggest the user possible exits, or are you\nsaying that it might be a good idea but \"git explain\" is a bad\nname?\n\nAn issue with this approach is that this can be the beginning of\nhardwiring the official \"right way of doing things\" in the set\nof tools. Pursuing this approach would enhance the set of state\nmarkers like \"FAILED_MERGE\" in the example, which means:\n\n - more commands would actively record what they were attempting\n to do, obviously;\n\n - over time \"git explain\" will learn about these state markers,\n and we would hardwire the \"best current practice\" exits from\n various states in the help messages;\n\n - also commands other than \"git explain\" would learn about the\n state markers of other commands, and change their behaviour.\n For example, \"git am\" might learn to refuse running while a\n merge in progress much earlier than with the current\n implementation.\n\nThe last point can easily become a double-edged sword.\n\nHardwiring the recommended workflow in the tools would reduce\nchances of mistakes, but it could rob the flexibility from them\nif we are not careful and forget to take into account some\nuseful combination of tools when adding such safety valves.\n"},{"id":"296855","messageId":"20061205072622.GA21839@coredump.intra.peff.net","threadId":"43480","inReplyTo":"7v1wnekh6a.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-explain","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-12-05T07:26:22Z","receivedAt":"2006-12-05T07:26:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 04, 2006 at 10:09:17PM -0800, Junio C Hamano wrote:\n\n> Should I take these responses to mean that you two are negative\n> about the approach of spending extra cycles to commands that can\n> leave the working tree in a \"in the middle of doing something\"\n> state to help having a unified command to explain what the\n> situation is and suggest the user possible exits, or are you\n> saying that it might be a good idea but \"git explain\" is a bad\n> name?\n\nIt seems like the point of this command is to show some state\ninformation which would otherwise be hard to see. I think of 'git\nstatus' as the way to look at the repository state. Perhaps we should\nenhance the output of 'git status' to note things such as failed merges,\nwhether we're bisecting, in the middle of applying a patch series, etc.\nThere could be an optional verbosity switch to give \"full explanations\"\nincluding recommended ways to deal with the situation.\n\n> Hardwiring the recommended workflow in the tools would reduce\n> chances of mistakes, but it could rob the flexibility from them\n> if we are not careful and forget to take into account some\n> useful combination of tools when adding such safety valves.\n\nAs long as the safety valves don't come up _routinely_ in certain\nworkflows, it seems OK to bypass them with a '-f' force switch. I\nsuspect the best way to figure out if such workflows are in use is to\nput in the safety valves and see who complains; otherwise we're stuck\nwith brainstorming workflows and deciding whether they make sense.\n\n"},{"id":"298325","messageId":"Pine.LNX.4.63.0612050950450.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43480","inReplyTo":"7v1wnekh6a.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-explain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T08:58:25Z","receivedAt":"2006-12-05T08:58:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Dec 2006, Junio C Hamano wrote:\n\n> \"J. Bruce Fields\" writes:\n> \n> > On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:\n> >> ...\n> >> > [PATCH] git-explain\n> >> > ...\n> >> \n> >> What about calling it git-whatsup instead?\n> >\n> > No, clearly it should be git-wtf.\n> \n> Should I take these responses to mean that you two are negative\n> about the approach [...]\n\nI think they just were in the mood for some slashdot style \nunimportant-aspects-in-a-funny-way discussion.\n\n> An issue with this approach is that this can be the beginning of\n> hardwiring the official \"right way of doing things\" in the set\n> of tools. Pursuing this approach would enhance the set of state\n> markers like \"FAILED_MERGE\" in the example, which means:\n> \n> - more commands would actively record what they were attempting\n> to do, obviously;\n\n... which is a good thing.\n\n> - over time \"git explain\" will learn about these state markers,\n> and we would hardwire the \"best current practice\" exits from\n> various states in the help messages;\n\n... which is also a good thing.\n\n> - also commands other than \"git explain\" would learn about the\n> state markers of other commands, and change their behaviour.\n> For example, \"git am\" might learn to refuse running while a\n> merge in progress much earlier than with the current\n> implementation.\n\nIf the other commands are outside of git, it will be a problem.\n\n> The last point [git-am refusing to run during a merge] can easily become \n> a double-edged sword.\n\nThis particular behaviour seems like a good thing, too!\n\n> Hardwiring the recommended workflow in the tools would reduce chances of \n> mistakes, but it could rob the flexibility from them if we are not \n> careful and forget to take into account some useful combination of tools \n> when adding such safety valves.\n\nAs has been the case not at all long ago, a saftey valve which no longer \nmade sense was just removed.\n\nAs for the inflexibility of a recommended workflow: by now, long-time \ngitsters have had enough time to fiddle around with git and to develop a \nworkflow which Just Works. It is just a nice gesture of old-time users \ntowards new-time users to pass that knowledge. And new-time users are \noften not in the least interested in learning the ropes the hard way.\n\nBesides, the recommended workflow(s) can be changed/replaced by other \nporcelainish commands, because only those will contain the safety valves, \nright?\n\nCiao,\nDscho\n"},{"id":"295021","messageId":"001b01c7184d$5d142c20$0b0aa8c0@abf.local","threadId":"43480","inReplyTo":"7v1wnekh6a.fsf@assigned-by-dhcp.cox.net","subject":"RE: [PATCH] git-explain","fromName":"Raimund Bauer","fromEmail":"ray@softwarelandschaft.com","sentAt":"2006-12-05T09:11:30Z","receivedAt":"2006-12-05T09:11:30Z","isPatch":true,"sender":{"key":"ray@softwarelandschaft.com","avatar":null},"body":"> An issue with this approach is that this can be the beginning \n> of hardwiring the official \"right way of doing things\" in the \n> set of tools. Pursuing this approach would enhance the set \n> of state markers like \"FAILED_MERGE\" in the example, which means:\n\nWouldn't it be better to create some kind of action-log (that's\ncleared at the end of the command if everything was all right)\ninstead of creating special markers for different commands?\n\nThat way there would be only 1 place to check for what happened ...\n\n-- \nbest regards\n\n Ray\n"},{"id":"298449","messageId":"20061205210010.GF26702@fieldses.org","threadId":"43480","inReplyTo":"Pine.LNX.4.63.0612050950450.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-explain","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-05T21:00:10Z","receivedAt":"2006-12-05T21:00:10Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Dec 05, 2006 at 09:58:25AM +0100, Johannes Schindelin wrote:\n> On Mon, 4 Dec 2006, Junio C Hamano wrote:\n> > \"J. Bruce Fields\" writes:\n> > \n> > > On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:\n> > >> ...\n> > >> > [PATCH] git-explain\n> > >> > ...\n> > >> \n> > >> What about calling it git-whatsup instead?\n> > >\n> > > No, clearly it should be git-wtf.\n> > \n> > Should I take these responses to mean that you two are negative\n> > about the approach [...]\n> \n> I think they just were in the mood for some slashdot style \n> unimportant-aspects-in-a-funny-way discussion.\n\nYeah, I was just being silly, apologies.\n\n"}]}