{"thread":{"id":"31248","subject":"What should mergetool do with --no-prompt?","startedAt":"2012-08-14T07:07:26Z","lastAt":"2012-08-14T19:15:28Z","messageCount":6,"participants":["David Aguilar","Charles Bailey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196959","messageId":"CAJDDKr5TK910n603jcmoq6WoaLL9DX9hgwF3Y+MmjngMpAXPQw@mail.gmail.com","threadId":"31248","inReplyTo":null,"subject":"What should mergetool do with --no-prompt?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-08-14T07:07:26Z","receivedAt":"2012-08-14T07:07:26Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"Right now there are two code paths, resolving deletion conflicts\nand resolving symlink conflicts, in git-mergetool that do not\nhonor --no-prompt. They force user-interaction with the shell\neven though the caller (such as a program) said that they do\nnot want to be prompted.\n\nThis was an oversight from when this option was first added.\n\nI think a simple and sensible thing to do would be for mergetool\nto skip over these entries when --no-prompt is supplied.\n\nDoes this sound like a good idea?\n-- \nDavid\n"},{"id":"196960","messageId":"20120814071823.GA21031@hashpling.org","threadId":"31248","inReplyTo":"CAJDDKr5TK910n603jcmoq6WoaLL9DX9hgwF3Y+MmjngMpAXPQw@mail.gmail.com","subject":"Re: What should mergetool do with --no-prompt?","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2012-08-14T07:18:23Z","receivedAt":"2012-08-14T07:18:23Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:\n> Right now there are two code paths, resolving deletion conflicts\n> and resolving symlink conflicts, in git-mergetool that do not\n> honor --no-prompt. They force user-interaction with the shell\n> even though the caller (such as a program) said that they do\n> not want to be prompted.\n> \n> This was an oversight from when this option was first added.\n> \n> I think a simple and sensible thing to do would be for mergetool\n> to skip over these entries when --no-prompt is supplied.\n> \n> Does this sound like a good idea?\n\n--no-prompt is designed to remove the prompt before launching a\nmergetool. This is because it is mostly pointless but does provide a\nconvenient point to interrupt (C-c) a large multifile conflict\nresolution.\n\nIt was never supposed to be a batch mode switch. By it's very nature\nmergetool is interactive so I don't see any advantage to pretending\notherwise.\n\nIf the documentation indicates otherwise then it's my opinion that\nthis is what needs to be fixed.\n\nCharles.\n"},{"id":"196975","messageId":"7vehn98qcv.fsf@alter.siamese.dyndns.org","threadId":"31248","inReplyTo":"20120814071823.GA21031@hashpling.org","subject":"Re: What should mergetool do with --no-prompt?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-14T15:06:56Z","receivedAt":"2012-08-14T15:06:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Charles Bailey writes:\n\n> On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:\n>> Right now there are two code paths, resolving deletion conflicts\n>> and resolving symlink conflicts, in git-mergetool that do not\n>> honor --no-prompt. They force user-interaction with the shell\n>> even though the caller (such as a program) said that they do\n>> not want to be prompted.\n>> \n>> This was an oversight from when this option was first added.\n>> \n>> I think a simple and sensible thing to do would be for mergetool\n>> to skip over these entries when --no-prompt is supplied.\n>> \n>> Does this sound like a good idea?\n>\n> --no-prompt is designed to remove the prompt before launching a\n> mergetool. This is because it is mostly pointless but does provide a\n> convenient point to interrupt (C-c) a large multifile conflict\n> resolution.\n>\n> It was never supposed to be a batch mode switch. By it's very nature\n> mergetool is interactive so I don't see any advantage to pretending\n> otherwise.\n\nCould it be that the calling user or script does not even have a\nterminal but still can spawn the chosen mergetool backend and\ninteract with the user via its GUI? Or it may have a terminal that\nis hard for the user to interact with, and the prompt and \"read ans\"\nmay get stuck.\n\nIn such an environment, the ideal behaviour for the \"git mergetool\"\nfrontend may be not to interact via the terminal at all and instead\nrun its interaction to choose the resolution using a matching GUI\ninterface. I see when \"read ans\" fails (e.g. the standard input to\nthe mergetool is closed), resolve_{symlink,deleted}_merge will not\nget stuck but instead fail, so perhaps David's issue could be solved\nby running \"git mergetool --tool=... \n> Could it be that the calling user or script does not even have a\n> terminal but still can spawn the chosen mergetool backend and\n> interact with the user via its GUI? Or it may have a terminal that\n> is hard for the user to interact with, and the prompt and \"read ans\"\n> may get stuck.\n\nIt could be, although this certainly wasn't considered in the original\ndesign. I know that we removed explicit references to /dev/tty and\nreplaced them with exec n>&m juggling which made things generally more\nrobust and allowed some basic shell tests to work more reliably. I\ndon't object to handling non-interactive mode better but it feels\nunsatisfactory to only be able to resolve some types of conflict and\nhave to skip others.\n\n> In such an environment, the ideal behaviour for the \"git mergetool\"\n> frontend may be not to interact via the terminal at all and instead\n> run its interaction to choose the resolution using a matching GUI\n> interface. I see when \"read ans\" fails (e.g. the standard input to\n> the mergetool is closed), resolve_{symlink,deleted}_merge will not\n> get stuck but instead fail, so perhaps David's issue could be solved\n> by running \"git mergetool --tool=... writes:\n\n> On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:\n>> \n>> Could it be that the calling user or script does not even have a\n>> terminal but still can spawn the chosen mergetool backend and\n>> interact with the user via its GUI? Or it may have a terminal that\n>> is hard for the user to interact with, and the prompt and \"read ans\"\n>> may get stuck.\n>\n> It could be, although this certainly wasn't considered in the original\n> design. I know that we removed explicit references to /dev/tty and\n> replaced them with exec n>&m juggling which made things generally more\n> robust and allowed some basic shell tests to work more reliably. I\n> don't object to handling non-interactive mode better but it feels\n> unsatisfactory to only be able to resolve some types of conflict and\n> have to skip others.\n\nExactly. The mention of \"a matching GUI\" below you quoted was a\nsuggestion to improve that \"only resolve some but not others\"\nproblem. The usual mergetool backend, e.g. meld, may not be capable\nof resolving symlink conflicts, but \"git mergetool\" could run a GUI\ndialog that gives the user \"ours/theirs/fail\" choice (or better yet\n\"merge result value\" textbox in addition) for such a path. The same\nfor delete/modify conflicts.\n\n>> In such an environment, the ideal behaviour for the \"git mergetool\"\n>> frontend may be not to interact via the terminal at all and instead\n>> run its interaction to choose the resolution using a matching GUI\n>> interface.\n"},{"id":"196993","messageId":"CAJDDKr7C1dNFZZap9duKc7QgvSRjAhHB+B2GpBc1h7spwpNRqg@mail.gmail.com","threadId":"31248","inReplyTo":"7v1uj9bd5d.fsf@alter.siamese.dyndns.org","subject":"Re: What should mergetool do with --no-prompt?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-08-14T19:15:28Z","receivedAt":"2012-08-14T19:15:28Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Aug 14, 2012 at 10:23 AM, Junio C Hamano wrote:\n> Charles Bailey writes:\n>\n>> On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:\n>>>\n>>> Could it be that the calling user or script does not even have a\n>>> terminal but still can spawn the chosen mergetool backend and\n>>> interact with the user via its GUI? Or it may have a terminal that\n>>> is hard for the user to interact with, and the prompt and \"read ans\"\n>>> may get stuck.\n>>\n>> It could be, although this certainly wasn't considered in the original\n>> design. I know that we removed explicit references to /dev/tty and\n>> replaced them with exec n>&m juggling which made things generally more\n>> robust and allowed some basic shell tests to work more reliably. I\n>> don't object to handling non-interactive mode better but it feels\n>> unsatisfactory to only be able to resolve some types of conflict and\n>> have to skip others.\n>\n> Exactly. The mention of \"a matching GUI\" below you quoted was a\n> suggestion to improve that \"only resolve some but not others\"\n> problem. The usual mergetool backend, e.g. meld, may not be capable\n> of resolving symlink conflicts, but \"git mergetool\" could run a GUI\n> dialog that gives the user \"ours/theirs/fail\" choice (or better yet\n> \"merge result value\" textbox in addition) for such a path. The same\n> for delete/modify conflicts.\n>\n>>> In such an environment, the ideal behaviour for the \"git mergetool\"\n>>> frontend may be not to interact via the terminal at all and instead\n>>> run its interaction to choose the resolution using a matching GUI\n>>> interface.\n\nThat makes sense. Perhaps a tcl/tk dialog could be used for these\nwhen a special flag, e.g. \"--interactive-gui\" or something, is\nsupplied. I think that would be nice, and I can look into this when\nI have some more tcl/tk hacking time.\n\nI did have a real-world example -- a GUI that runs git-mergetool\non the user's behalf that (wrongly) assumed that \"git mergetool -y\"\nwould not block waiting for input. This is not a problem with the\ndocumentation or with the implementation -- it was simply an oversight\non my part.\n\nDue to backwards-compatibility concerns, the only way to do\nthis (and work across as many git versions as possible) is to\ndetect these special cases -- submodules, symlinks, and deletions\n-- and handle it in the calling app instead of delegating to mergetool.\n\n\nThere is a part of me that thinks that \"--no-prompt\" should\nreally not prompt, and that the various choices could be supplied\non the command-line, e.g. \"git mergetool --theirs --no-prompt \".\n\nFlags like --ours and --theirs would be heavy hammers when run\nwithout pathspecs. Nonetheless, would it would be helpful to have\nthese? I seems like it would be helpful when resolving these\nspecial-case merge scenarios.\n\nSo I think I'll take the advice that the calling app should\nspecial-case these for existing git versions, and then later\nallow them to fall through to mergetool once we've had a chance\nto add a matching GUI interface.\n\nThanks for the sanity check,\n-- \nDavid\n"}]}