{"thread":{"id":"4739","subject":"qgit idea: interface for cherry-picking","startedAt":"2006-07-02T19:01:10Z","lastAt":"2006-07-04T18:38:46Z","messageCount":18,"participants":["Jakub Narebski","Marco Costalba","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23042","messageId":"e8954u$srh$1@sea.gmane.org","threadId":"4739","inReplyTo":null,"subject":"qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-02T19:01:10Z","receivedAt":"2006-07-02T19:01:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Currently in qgit one can git-format-patch a commit. It woul be nice if one\nwould be able to git-cherry-pick and git-cherry-pick -n a commit (denoting\nthe head, i.e. where cherry pick would be applied to). It would be very\nusefull in reordering patches (cleaning up history).  \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23052","messageId":"e5bfff550607021433l1987c32apf4453b52fc2f3e63@mail.gmail.com","threadId":"4739","inReplyTo":"e8954u$srh$1@sea.gmane.org","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-02T21:33:55Z","receivedAt":"2006-07-02T21:33:55Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Currently in qgit one can git-format-patch a commit. It woul be nice if one\n> would be able to git-cherry-pick and git-cherry-pick -n a commit (denoting\n> the head, i.e. where cherry pick would be applied to). It would be very\n> usefull in reordering patches (cleaning up history).\n>\n> --\n\nCurrently in qgit you can git-format-patch a commit series and git-am\na given patch file series.\nThis can be done transparently with a drag & drop mechanic:\n\n1) Open the source repository\n2) Then open a new qgit instance (File->Open in a new window...)\n3) Open the destination repository in the new qgit window\n4) Drag & drop selected commits (multi selection in supported) from\nsource to destination.\n\nI normally use this instead of git-cherry-pick  that, I admit, I don't\nknow very well, so please I need some more hints on how to upgrade\nthis behaviour introducing git.cherry-pick support.\n\n    Marco\n"},{"id":"23055","messageId":"e89eqj$npu$1@sea.gmane.org","threadId":"4739","inReplyTo":"e5bfff550607021433l1987c32apf4453b52fc2f3e63@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-02T21:46:20Z","receivedAt":"2006-07-02T21:46:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n>> Currently in qgit one can git-format-patch a commit. It woul be nice \n>> if one would be able to git-cherry-pick and git-cherry-pick -n a commit\n>> (denoting the head, i.e. where cherry pick would be applied to). It would\n>> be very usefull in reordering patches (cleaning up history).   \n> \n> Currently in qgit you can git-format-patch a commit series and git-am\n> a given patch file series.\n> This can be done transparently with a drag & drop mechanic:\n> \n> 1) Open the source repository\n> 2) Then open a new qgit instance (File->Open in a new window...)\n> 3) Open the destination repository in the new qgit window\n> 4) Drag & drop selected commits (multi selection in supported) from\n> source to destination.\n\nDoes multi selection commits all selected commits as one merged commit?\n\n> I normally use this instead of git-cherry-pick  that, I admit, I don't\n> know very well, so please I need some more hints on how to upgrade\n> this behaviour introducing git.cherry-pick support.\n\nI use git-cherry-pick -n to join few patches into one, or with editing the\nresult to split one patch/commit into few smaller.\n\ngit-cherry-pick [-n] <commit> picks up a commit and drops it on top of\ncurrent branch. I'd like to see it in context menu for current commit,\ni.e. \"cherry-pick to <head>\", where <head> will be replaced by current\nbranch name, or/and \"cherry-pick -n to <head>\". \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23058","messageId":"e5bfff550607021504l6e7fc8b8ja61f20f630c0f3f@mail.gmail.com","threadId":"4739","inReplyTo":"e89eqj$npu$1@sea.gmane.org","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-02T22:04:07Z","receivedAt":"2006-07-02T22:04:07Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Marco Costalba wrote:\n>\n> > On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> >> Currently in qgit one can git-format-patch a commit. It woul be nice\n> >> if one would be able to git-cherry-pick and git-cherry-pick -n a commit\n> >> (denoting the head, i.e. where cherry pick would be applied to). It would\n> >> be very usefull in reordering patches (cleaning up history).\n> >\n> > Currently in qgit you can git-format-patch a commit series and git-am\n> > a given patch file series.\n> > This can be done transparently with a drag & drop mechanic:\n> >\n> > 1) Open the source repository\n> > 2) Then open a new qgit instance (File->Open in a new window...)\n> > 3) Open the destination repository in the new qgit window\n> > 4) Drag & drop selected commits (multi selection in supported) from\n> > source to destination.\n>\n> Does multi selection commits all selected commits as one merged commit?\n>\n\nNo.  Currently it's just a shortcut for git-format-patch --> git-am\n\n> > I normally use this instead of git-cherry-pick  that, I admit, I don't\n> > know very well, so please I need some more hints on how to upgrade\n> > this behaviour introducing git.cherry-pick support.\n>\n> I use git-cherry-pick -n to join few patches into one, or with editing the\n> result to split one patch/commit into few smaller.\n>\n> git-cherry-pick [-n] <commit> picks up a commit and drops it on top of\n> current branch. I'd like to see it in context menu for current commit,\n> i.e. \"cherry-pick to <head>\", where <head> will be replaced by current\n> branch name, or/and \"cherry-pick -n to <head>\".\n>\n>\n\n>From the git-cherry-pick documentation I see -n option \"applies the\nchange necessary to cherry-pick the named commit to your working tree,\nbut does not make the commit\"\n\nWhat do you think about this:\n\nWhen dropping the selected commits, instead of creating new commits,\nappears a message box with something like \"Do you want to apply the\ncommits on top of your current branch or on your working directory?\"\n\nSounds good for you? Or you still prefer the context menu?\nIn the latter case, if I have understood correctly, you are limited to\ncherry-pick among branches and/or working directory of the _same_\nrepository.\n\n    Marco\n"},{"id":"23062","messageId":"e89iql$42a$1@sea.gmane.org","threadId":"4739","inReplyTo":"e5bfff550607021504l6e7fc8b8ja61f20f630c0f3f@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-02T22:54:39Z","receivedAt":"2006-07-02T22:54:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> What do you think about this:\n> \n> When dropping the selected commits, instead of creating new commits,\n> appears a message box with something like \"Do you want to apply the\n> commits on top of your current branch or on your working directory?\"\n> \n> Sounds good for you? Or you still prefer the context menu?\n> In the latter case, if I have understood correctly, you are limited to\n> cherry-pick among branches and/or working directory of the _same_\n> repository.\n\nYes, git-cherry-pick works only between commits in the same repository,\nas it use merge (first \"simple\", i.e. git-read-tree -m -u --aggresive, if\nfails tries \"automatic\" i.e. git-merge-index -o git-merge-one-file -a, then\ngit-write-tree), as opposed to git-format-patch and git-am or git-apply,\nwhich can work across repositories.\n\nWhat I really want is \"no-commit\" of drag'n'dropped, or exported and applied\ncommits/patches (although interface to cherry-pick would be nice, even if\ncherry-pick is limited), so I'd like message box with \"Do you want to\ncommit selected patches?\" when dropping commits, or something like that.\nUnfortunately git-am doesn't have --no-commit flag, but one could emulate it\nwith git-reset after git-am a patch, I think.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23085","messageId":"e5bfff550607022245s2ef160fu5ad30a822f06117d@mail.gmail.com","threadId":"4739","inReplyTo":"e89iql$42a$1@sea.gmane.org","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-03T05:45:17Z","receivedAt":"2006-07-03T05:45:17Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/3/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Marco Costalba wrote:\n>\n> > What do you think about this:\n> >\n> > When dropping the selected commits, instead of creating new commits,\n> > appears a message box with something like \"Do you want to apply the\n> > commits on top of your current branch or on your working directory?\"\n> >\n> > Sounds good for you? Or you still prefer the context menu?\n> > In the latter case, if I have understood correctly, you are limited to\n> > cherry-pick among branches and/or working directory of the _same_\n> > repository.\n>\n> Yes, git-cherry-pick works only between commits in the same repository,\n> as it use merge (first \"simple\", i.e. git-read-tree -m -u --aggresive, if\n> fails tries \"automatic\" i.e. git-merge-index -o git-merge-one-file -a, then\n> git-write-tree), as opposed to git-format-patch and git-am or git-apply,\n> which can work across repositories.\n>\n> What I really want is \"no-commit\" of drag'n'dropped, or exported and applied\n> commits/patches (although interface to cherry-pick would be nice, even if\n> cherry-pick is limited), so I'd like message box with \"Do you want to\n> commit selected patches?\" when dropping commits, or something like that.\n> Unfortunately git-am doesn't have --no-commit flag, but one could emulate it\n> with git-reset after git-am a patch, I think.\n>\n\nWhen I need to modify the patch/revision before to import I usaually\ndrag&drop and then I call git-reset --soft, then I edit working\ndirectory and commit again.\n\nPerhaps I can automate this in case the user answers \"No, apply to\nworking dir only\" to the message box.\n\nIs it the correct way to go or is better to wait for a --no-commit\nflag in git-am?\nJunio?\n\n   Thanks\n   Marco\n"},{"id":"23086","messageId":"7vzmfrrxyp.fsf@assigned-by-dhcp.cox.net","threadId":"4739","inReplyTo":"e5bfff550607022245s2ef160fu5ad30a822f06117d@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-03T06:42:22Z","receivedAt":"2006-07-03T06:42:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" <mcostalba@gmail.com> writes:\n\n> When I need to modify the patch/revision before to import I usaually\n> drag&drop and then I call git-reset --soft, then I edit working\n> directory and commit again.\n\nThese days, I tend to just let \"am\" or \"pull\" do its thing, edit\nworking tree and retest, and run \"commit --amend\".  Before we\nadded \"commit --amend\", I used to do soft reset and recommit\nlike you described above.  One advantage of \"commit --amend\" is\nthat it can even amend a merge, but I do not think it applies to\nwhat Jakub wants in this thread.\n\n> Perhaps I can automate this in case the user answers \"No, apply to\n> working dir only\" to the message box.\n>\n> Is it the correct way to go or is better to wait for a --no-commit\n> flag in git-am?\n\nProbably your \"git-am --no-commit\" would stop after applying one\npatch (the first one in the sequence) but before writing a\ncommit.  We already sometimes do that when the patch does not\napply cleanly, so I do not offhand have much objection against\nadding such a flag.\n\nI think the workflow to continue after \"git-am --no-commit\" will\nbe quite similar to what you would do when \"git-am --3way\" stops\nwith conflicts.  In order to continue from there, you would do\nwhatever is needed to bring the index into the shape you wanted\nto have if the patch applied cleanly.  Then \"git am --resolved\".\n\nPerhaps something like the attached.  If somebody finds it\nuseful, after testing it out, please kick it back to me, perhaps\nwith a paragraph or two to properly document it.\n\n-- >8 --\ngit-am --fail\n\nThe new flag prevents a new commit from being made even when the\npatch applies cleanly.  This gives you an opportunity to further\nfix up the change in your working tree before making the final\ncommit.\n\nIn order to continue, do whatever is needed to bring the index\ninto the shape you wanted to have if the patch applied cleanly,\nand run \"git am --resolved\".\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 679045a..77d8cd9 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -3,7 +3,7 @@ #\n # Copyright (c) 2005, 2006 Junio C Hamano\n \n USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]\n-  [--interactive] [--whitespace=<option>] <mbox>...\n+  [--fail] [--interactive] [--whitespace=<option>] <mbox>...\n   or, when resuming [--skip | --resolved]'\n . git-sh-setup\n \n@@ -91,7 +91,7 @@ fall_back_3way () {\n }\n \n prec=4\n-dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=\n+dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg= fail=\n \n while case \"$#\" in 0) break;; esac\n do\n@@ -109,6 +109,9 @@ do\n \t-b|--b|--bi|--bin|--bina|--binar|--binary)\n \tbinary=t; shift ;;\n \n+\t-f|--f|--fa|--fai|--fail)\n+\tfail=t; shift ;;\n+\n \t-3|--3|--3w|--3wa|--3way)\n \tthreeway=t; shift ;;\n \t-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)\n@@ -401,6 +404,10 @@ do\n \tthen\n \t\techo Patch failed at $msgnum.\n \t\tstop_here_user_resolve $this\n+\telif test -n \"$fail\"\n+\tthen\n+\t\techo Stopped at $msg per user request\n+\t\tstop_here_user_resolve $this\n \tfi\n \n \tif test -x \"$GIT_DIR\"/hooks/pre-applypatch\n"},{"id":"23100","messageId":"e5bfff550607030418n6a46c0cdh1a95155e1feb4356@mail.gmail.com","threadId":"4739","inReplyTo":"7vzmfrrxyp.fsf@assigned-by-dhcp.cox.net","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-03T11:18:46Z","receivedAt":"2006-07-03T11:18:46Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:\n> \"Marco Costalba\" <mcostalba@gmail.com> writes:\n>\n> > When I need to modify the patch/revision before to import I usaually\n> > drag&drop and then I call git-reset --soft, then I edit working\n> > directory and commit again.\n>\n> These days, I tend to just let \"am\" or \"pull\" do its thing, edit\n> working tree and retest, and run \"commit --amend\".  Before we\n> added \"commit --amend\", I used to do soft reset and recommit\n> like you described above.  One advantage of \"commit --amend\" is\n> that it can even amend a merge, but I do not think it applies to\n> what Jakub wants in this thread.\n>\n\nI cannot test your patch now, so I'm just guessing, what if we have a\nseries of patches?\nIs it possible that for two patches A and B happens that\n\ngit-am A\ngit-am B\ngit-reset --soft HEAD^^\n\ngives a different result then\n\ngit-am --fail A\ngit-am --fail B\n\nAs example, if B modify the same file of A then could happen that in\nthe latter case git-am --fail B stops with conflicts because the\nworking dir is not synced with the index (this happens only in the\nlatter case) ?\n\nPut in other words, I don't know if the two procedures are\n_equivalent_ because in the first case you operate under the\nassumption that working dir and index are always synced before and\nafter to apply, in the second case this assumption is broken so I\ndon't know if this could have side effects.\n\n      Marco\n"},{"id":"23126","messageId":"7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net","threadId":"4739","inReplyTo":"e5bfff550607030418n6a46c0cdh1a95155e1feb4356@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-03T20:03:44Z","receivedAt":"2006-07-03T20:03:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" <mcostalba@gmail.com> writes:\n\n> I cannot test your patch now, so I'm just guessing, what if we have a\n> series of patches?\n\nThe patch stops at each patch.  I am primarily interested in\nkeeping \"git-am\" usable from command line while making it easy\nto use from other tools.\n\nThe expected use for the patch you are responding to is that\nafter the first application with --fail the user has an\nopportunity to fix the result up but needs to create a commit by\nrerunning \"git-am\" (or just drop that by resetting the index and\nsaying \"git-am --skip\").\n\n> Is it possible that for two patches A and B happens that\n>\n> git-am A\n> git-am B\n> git-reset --soft HEAD^^\n>\n> gives a different result then\n>\n> git-am --fail A\n> git-am --fail B\n\nIf you had a series of patches chosen inside your GUI and\nsquash-apply them all, two full am with soft reset to the\noriginal state would be the easiest, if and only if both patch\napplications do not fail.  If patch A does not apply for\nwhatever reason, you have to guide your user through the patch\nadjustment process before applying B, regardless of the reason\nwhy the patch application failed (either A did not apply\ncleanly, or you gave --fail to the command).\n\nThe main question is what you would let your users do and how\nyou would guide them through the process, when the application\nof an earlier patch in the series fails.  I think it is a\nsecondary implementation detail which of \"git-am\", \"git-am\n--fail\" or \"git-apply\" to implement that process.\n"},{"id":"23185","messageId":"e5bfff550607032322jdf3bc79l3f41c292ebb6d3f7@mail.gmail.com","threadId":"4739","inReplyTo":"7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-04T06:22:33Z","receivedAt":"2006-07-04T06:22:33Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:\n>\n> If you had a series of patches chosen inside your GUI and\n> squash-apply them all, two full am with soft reset to the\n> original state would be the easiest, if and only if both patch\n> applications do not fail.  If patch A does not apply for\n> whatever reason, you have to guide your user through the patch\n> adjustment process before applying B, regardless of the reason\n> why the patch application failed (either A did not apply\n> cleanly, or you gave --fail to the command).\n>\n> The main question is what you would let your users do and how\n> you would guide them through the process, when the application\n> of an earlier patch in the series fails.  I think it is a\n> secondary implementation detail which of \"git-am\", \"git-am\n> --fail\" or \"git-apply\" to implement that process.\n>\n\nQGit is not supposed to be a GUI replacement of git UI. QGit only let\nusers quickly call some commonly used commands. The process of error\nrecovering, conflicts resolve and any other complication that could\ninvolve more the one main flow of processing are outside the scope.\nQGit simply leaves the job to native git tools any time there\nsomething 'outside tha main flow'.\n\nSo in case a patch does not apply a message feedback is returned and\nthe process is terminated. All the not qgit generated intermediate\nfiles are left at their places and is up to the user fix the things\nup, possibly using native git commands.\n\nQGit does not play magic. If something goes wrong it simply stops.\n\n     Marco\n"},{"id":"23186","messageId":"e8d2eo$k44$1@sea.gmane.org","threadId":"4739","inReplyTo":"e5bfff550607032322jdf3bc79l3f41c292ebb6d3f7@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-04T06:39:53Z","receivedAt":"2006-07-04T06:39:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> QGit is not supposed to be a GUI replacement of git UI. QGit only let\n> users quickly call some commonly used commands. [...]\n\nIt's a pity. Doing some of commands from visual history viewer, with view of\nbranches etc. would be so much easier: like bisect, rebasing, cherry\npicking, reverting a commit...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23187","messageId":"7vk66tna71.fsf@assigned-by-dhcp.cox.net","threadId":"4739","inReplyTo":"e5bfff550607032322jdf3bc79l3f41c292ebb6d3f7@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-04T06:41:38Z","receivedAt":"2006-07-04T06:41:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" <mcostalba@gmail.com> writes:\n\n>> The main question is what you would let your users do and how\n>> you would guide them through the process, when the application\n>> of an earlier patch in the series fails.  I think it is a\n>> secondary implementation detail which of \"git-am\", \"git-am\n>> --fail\" or \"git-apply\" to implement that process.\n>\n> QGit is not supposed to be a GUI replacement of git UI. QGit only let\n> users quickly call some commonly used commands. The process of error\n> recovering, conflicts resolve and any other complication that could\n> involve more the one main flow of processing are outside the scope.\n> QGit simply leaves the job to native git tools any time there\n> something 'outside tha main flow'.\n\nYes, either you (1) need to make sure the user is aware what\nunderlying git commands QGit runs for them, so that the user\nknows what workflow to follow when the procedure needs to go\nmanual, or (2) hide the underlying git commands QGit runs for\nusers, but then you need to make QGit aware of what workflow to\nfollow when the procedure needs to go manual, and guide the user\nthrough that workflow.  I think either is fine approach;\npersonally I prefer transparent tools that does (1), which is\nthe impression I am getting from your description of QGit.\n\nIf you take route (1), using \"am --fail\" number of times\ninvolves QGit runs \"am --fail\" once, guide user to fix things up\n_and_ give control back to QGit, then you run the next \"am\n--fail\", etc, which would be quite cumbersome to implement.  But\nrunning multiple am and do reset soft to roll back needed number\nof parents might be easier option to implement in QGit, but you\nstill have the same \"you give the control to the user but then\nyou have to take the control away to proceed\" problem when the\npatch does not apply cleanly somewhere (you let the user to hand\nresolve and say \"am --resolved\", but then when the series is\ndepleted, somebody has to run \"reset --soft\" to roll N commits\nback to realize what you wanted to do, so at that point QGit\nsomehow needs to take control back).\n"},{"id":"23191","messageId":"e8d3ot$ne9$2@sea.gmane.org","threadId":"4739","inReplyTo":"7vk66tna71.fsf@assigned-by-dhcp.cox.net","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-04T07:02:22Z","receivedAt":"2006-07-04T07:02:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> [...] (you let the user to hand\n> resolve and say \"am --resolved\", but then when the series is\n> depleted, somebody has to run \"reset --soft\" to roll N commits\n> back to realize what you wanted to do, so at that point QGit\n> somehow needs to take control back).\n\nWould it be easier if QGit for \"am --squash\" generated lightweight temporary\ntag before first git-am, so one would need not to remember N for \"reset\n--soft\"?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23215","messageId":"e5bfff550607040421id4e71efw38ee2bd773c949de@mail.gmail.com","threadId":"4739","inReplyTo":"7vk66tna71.fsf@assigned-by-dhcp.cox.net","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-04T11:21:08Z","receivedAt":"2006-07-04T11:21:08Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:\n> \"Marco Costalba\" <mcostalba@gmail.com> writes:\n>\n>\n> Yes, either you (1) need to make sure the user is aware what\n> underlying git commands QGit runs for them, so that the user\n> knows what workflow to follow when the procedure needs to go\n> manual, or (2) hide the underlying git commands QGit runs for\n> users, but then you need to make QGit aware of what workflow to\n> follow when the procedure needs to go manual, and guide the user\n> through that workflow.  I think either is fine approach;\n> personally I prefer transparent tools that does (1), which is\n> the impression I am getting from your description of QGit.\n>\n\nYes, I prefer way (1) too. QGit as an error reporting infrastructure\nto always report by a message box arguments (starting from 0) of\noffending command, be it native git or not.\n\n\n> If you take route (1), using \"am --fail\" number of times\n> involves QGit runs \"am --fail\" once, guide user to fix things up\n> _and_ give control back to QGit, then you run the next \"am\n> --fail\", etc, which would be quite cumbersome to implement.  But\n> running multiple am and do reset soft to roll back needed number\n> of parents might be easier option to implement in QGit, but you\n> still have the same \"you give the control to the user but then\n> you have to take the control away to proceed\" problem when the\n> patch does not apply cleanly somewhere (you let the user to hand\n> resolve and say \"am --resolved\", but then when the series is\n> depleted, somebody has to run \"reset --soft\" to roll N commits\n> back to realize what you wanted to do, so at that point QGit\n> somehow needs to take control back).\n>\n>\n\nI have started to implement the feature suggested by Jakub (patch in\nworking dir only, not committed). The core is a loop of git-am, one\nfor each patch to import, followed by a:\n\n    git-reset --mixed HEAD~<Num of succesfully applied patches>\n\nTo note that the above git-reset command is _always_ run be the patch\nseries apply successfully be it fails at some point, so that in any\ncase the tree is not dirty up, and you have the working tree with the\ninformation you need in case of manual fixup.\n\nI will plan to push as soon I'm able to reach a \"pushable site\" ;-)\n\nComments? could work? not consistent?\n\n     Marco\n"},{"id":"23221","messageId":"e5bfff550607040458m1e6ea6bes44b3e3eba26856f0@mail.gmail.com","threadId":"4739","inReplyTo":"e8d2eo$k44$1@sea.gmane.org","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-04T11:58:10Z","receivedAt":"2006-07-04T11:58:10Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Marco Costalba wrote:\n>\n> > QGit is not supposed to be a GUI replacement of git UI. QGit only let\n> > users quickly call some commonly used commands. [...]\n>\n> It's a pity. Doing some of commands from visual history viewer, with view of\n> branches etc. would be so much easier: like bisect, rebasing, cherry\n> picking, reverting a commit...\n>\n\nIn the past weeks I (with Pavel support) have implemented and pushed\nthe concept of \"custom actions\".\n\nIs it possible to associate commands sequences, scripts and anything\nelse executable to a custom action. Actions can be called and run from\nmenu entry and corresponding output is grabbed by a terminal window.\n\nInstead of hard code each git-native command, this way you have a\nflexible framework to add shortcuts and menu entry for anything you\nwould like to be a click away. BTW I use this for stuff like git pull,\nbut also for 'make' and 'make install' because you have a window\nterminal for feedback.\n\nThere is also the possibility to input command line parameters before\nto run, useful, as example for a git pull action that asks for source\nrepository to pull from.\n\nIs this something that can fulfill you request? do you need something\ndifferent?  perhaps something as a \"default to current selected SHA as\ninput argument\" flag.\n\n  Marco\n"},{"id":"23225","messageId":"e8dqfo$3ff$1@sea.gmane.org","threadId":"4739","inReplyTo":"e5bfff550607040458m1e6ea6bes44b3e3eba26856f0@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-04T13:29:28Z","receivedAt":"2006-07-04T13:29:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> In the past weeks I (with Pavel support) have implemented and pushed\n> the concept of \"custom actions\".\n> \n> Is it possible to associate commands sequences, scripts and anything\n> else executable to a custom action. Actions can be called and run from\n> menu entry and corresponding output is grabbed by a terminal window.\n> \n> Instead of hard code each git-native command, this way you have a\n> flexible framework to add shortcuts and menu entry for anything you\n> would like to be a click away. BTW I use this for stuff like git pull,\n> but also for 'make' and 'make install' because you have a window\n> terminal for feedback.\n> \n> There is also the possibility to input command line parameters before\n> to run, useful, as example for a git pull action that asks for source\n> repository to pull from.\n> \n> Is this something that can fulfill you request? do you need something\n> different?  perhaps something as a \"default to current selected SHA as\n> input argument\" flag.\n\nIt would be nice (I don't know if feasible) that either to provide some kind\nof parameters substitution in the likes of \"%head\" in the invocation line\nfor a script to be expanded to the sha1 or name of head of currently\nselected commit.\n\nOther solution would be to provide GUI for input of command line parameters,\ne.g. combo-box (i.e. editable text field, with provided list of default\nvalues) for repository (populated from .git/branches and .git/remotes),\noption to select commit or use selected commit for head ref or just commit\nref, etc...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23234","messageId":"e5bfff550607041123l485b3e1di7d9d36047934d59b@mail.gmail.com","threadId":"4739","inReplyTo":"e5bfff550607040421id4e71efw38ee2bd773c949de@mail.gmail.com","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-04T18:23:11Z","receivedAt":"2006-07-04T18:23:11Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/4/06, Marco Costalba <mcostalba@gmail.com> wrote:\n> On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:\n> > \"Marco Costalba\" <mcostalba@gmail.com> writes:\n> >\n>\n> I have started to implement the feature suggested by Jakub (patch in\n> working dir only, not committed).\n\nOk. I have pushed two patches, the first with support for applying a\npatch series in working dir only, i.e. without  to create new commits,\nthe second to add \"branch that a rev belongs to\" info as in gitk, near\ntags information was already there.\n\nThe difference with gitk is that only loaded branch/tags are\nconsidered, this is to better scale.\nAnyhow, due to little tricks ;-) , indexing is very fast, about 250ms\nto index the whole Linux tree on my box.\n\n    Marco\n"},{"id":"23235","messageId":"e5bfff550607041138g60a82819lb5e59ea239b55ef5@mail.gmail.com","threadId":"4739","inReplyTo":"e8dqfo$3ff$1@sea.gmane.org","subject":"Re: qgit idea: interface for cherry-picking","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-07-04T18:38:46Z","receivedAt":"2006-07-04T18:38:46Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Marco Costalba wrote:\n>\n> >\n> > Is this something that can fulfill you request? do you need something\n> > different?  perhaps something as a \"default to current selected SHA as\n> > input argument\" flag.\n>\n> It would be nice (I don't know if feasible) that either to provide some kind\n> of parameters substitution in the likes of \"%head\" in the invocation line\n> for a script to be expanded to the sha1 or name of head of currently\n> selected commit.\n>\n\nWell, I think that the indiscussed champion in this field is git-rev-parse\n\nPlease note that an action have not to be _one_  git command, but you\ncan assign a command sequence to an action, if the first command is\ngit-rev-parse probably you have what you need.\n\nI have to better explain some implemantation details. In case a multi\nline text is set as an action content,  qgit wraps up the content in a\ntemporary script and run the script as a whole.\nSo you can use anything inside your action definition.\n\nNOTE: this is possible because the input parameters are _always_\nappended to the first line command only.\n\nAs example if the action 'test' is defined as:\n\necho\necho 2\necho 3\n\nWhen you run 'test' and insert  '1'  when prompted for input\nparameters the output will be:\n1\n2\n3\n\nHope this helps.\n\n    Marco\n"}]}