{"thread":{"id":"5361","subject":"git cherry-pick feature request","startedAt":"2006-08-23T06:29:04Z","lastAt":"2006-08-24T12:54:14Z","messageCount":7,"participants":["Paul Mackerras","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25787","messageId":"17643.62896.396783.890223@cargo.ozlabs.ibm.com","threadId":"5361","inReplyTo":null,"subject":"git cherry-pick feature request","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-08-23T06:29:04Z","receivedAt":"2006-08-23T06:29:04Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio,\n\nI have added a feature on the \"new\" branch of gitk which allows the\nuser to cherry-pick commits on to the head of the current branch.\nCurrently I am using 'sh -c \"git cherry-pick -r $id 2>&1\"' for this.\n\nThe reason for the \"2>&1\" is that git cherry-pick writes stuff to\nstderr even when there is no error, and the Tcl exec command assumes\nthat if the command writes to stderr that it failed somehow.\n\nAlso, if the merge fails, git cherry-pick leaves the commit partially\nmerged rather than restoring the original state.\n\nCould I have a flag to git cherry-pick (-q for quiet, maybe) that\ntells it not to print anything if the command succeeds? Could I also\nhave a flag that tells it to clean up if the merge fails and leave the\ntree in its previous state?\n\nOr is there some other git command that already does all this that I\nshould use instead?\n\nThanks,\nPaul.\n"},{"id":"25795","messageId":"7vfyfnixv5.fsf@assigned-by-dhcp.cox.net","threadId":"5361","inReplyTo":"17643.62896.396783.890223@cargo.ozlabs.ibm.com","subject":"Re: git cherry-pick feature request","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-23T09:51:10Z","receivedAt":"2006-08-23T09:51:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Could I have a flag to git cherry-pick (-q for quiet, maybe) that\n> tells it not to print anything if the command succeeds? Could I also\n> have a flag that tells it to clean up if the merge fails and leave the\n> tree in its previous state?\n\nQuiet sounds sane.\n\nReverting to its \"previous state\" I am not quite sure if it is\nworth making it an option and run it as part of cherry-pick.\n"},{"id":"25806","messageId":"17644.21269.128308.313284@cargo.ozlabs.ibm.com","threadId":"5361","inReplyTo":"7vfyfnixv5.fsf@assigned-by-dhcp.cox.net","subject":"Re: git cherry-pick feature request","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-08-23T13:07:33Z","receivedAt":"2006-08-23T13:07:33Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> Quiet sounds sane.\n> \n> Reverting to its \"previous state\" I am not quite sure if it is\n> worth making it an option and run it as part of cherry-pick.\n\nOK. If the git cherry-pick terminates with an error I'll get gitk to\nshow the error message (if any) it printed along with a warning that\nthe working directory might need to be cleaned up. I don't really\nwant to do a git reset automagically since the user might have local\nmodifications that they want to preserve.\n\nWhile I'm asking for features, another one that would be really useful\nfor another tool I'm writing is a 3-way diff for a file between the\nworking directory, the index, and the current head commit, something\nlike what git diff-tree -c does for merges. That is, it would have\ntwo columns of +/-/space characters, one for the current head and one\nfor the index. A '-' would indicate that the line appears in the\ncurrent head or the index but not in the version of the file in the\nworking directory. A '+' would indicate that the line appears in the\nworking directory version.\n\nHow hard would it be to adapt the git diff-tree -c mechanism to work\non two blobs plus the file from the working directory?\n\nThanks,\nPaul.\n"},{"id":"25809","messageId":"20060823143551.GA4592@sigio.intra.peff.net","threadId":"5361","inReplyTo":"17644.21269.128308.313284@cargo.ozlabs.ibm.com","subject":"Re: git cherry-pick feature request","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-08-23T14:35:51Z","receivedAt":"2006-08-23T14:35:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 23, 2006 at 11:07:33PM +1000, Paul Mackerras wrote:\n\n> While I'm asking for features, another one that would be really useful\n> for another tool I'm writing is a 3-way diff for a file between the\n> working directory, the index, and the current head commit, something\n> like what git diff-tree -c does for merges. That is, it would have\n\nTheoretically I'm working on this, but I haven't really had time to get\nstarted on it yet this week. If you have patience, I'll get to it. If\nnot, then somebody else is welcome to take a crack at it.\n\n-Peff\n"},{"id":"25832","messageId":"7vmz9ubnhl.fsf@assigned-by-dhcp.cox.net","threadId":"5361","inReplyTo":"20060823143551.GA4592@sigio.intra.peff.net","subject":"Re: git cherry-pick feature request","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-24T07:29:26Z","receivedAt":"2006-08-24T07:29:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Aug 23, 2006 at 11:07:33PM +1000, Paul Mackerras wrote:\n>\n>> While I'm asking for features, another one that would be really useful\n>> for another tool I'm writing is a 3-way diff for a file between the\n>> working directory, the index, and the current head commit, something\n>> like what git diff-tree -c does for merges. That is, it would have\n>\n> Theoretically I'm working on this, but I haven't really had time to get\n> started on it yet this week. If you have patience, I'll get to it. If\n> not, then somebody else is welcome to take a crack at it.\n\nIt is not entirely related, but I've restarted looking into a\nparallel tree walker again and will push something in \"pu\"\ntonight.\n\nIt will probably be quite a while until it becomes useful,\nthough. I suspect your approach of internally running\nrun_diff_files() and run_diff_index() and consolidating the\nresult, while it might feel hackish, would be easier at least in\nthe short term.\n"},{"id":"25833","messageId":"7vhd02bn64.fsf@assigned-by-dhcp.cox.net","threadId":"5361","inReplyTo":"17644.21269.128308.313284@cargo.ozlabs.ibm.com","subject":"Re: git cherry-pick feature request","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-24T07:36:19Z","receivedAt":"2006-08-24T07:36:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> While I'm asking for features, another one that would be really useful\n> for another tool I'm writing is a 3-way diff for a file between the\n> working directory, the index, and the current head commit, something\n> like what git diff-tree -c does for merges. That is, it would have\n> two columns of +/-/space characters, one for the current head and one\n> for the index. A '-' would indicate that the line appears in the\n> current head or the index but not in the version of the file in the\n> working directory. A '+' would indicate that the line appears in the\n> working directory version.\n\nThe combined diff (-c and --cc) comparison works by comparing a\nsingle post-image (merge result) with multiple pre-images, so I\nthink it is reasonable to compare the working tree files as the\npost-image and cached and HEAD-tree versions as the preimages.\n\nI am not sure how useful this would be though -- I am guessing\nthat in most people's workflow the index and the HEAD would\nexactly match most of the time, since that is the way Linus\nencourages (and I follow that myself). So for that extreme use\ncase, the difference between \"diff-index HEAD\" and the proposed\ncommand (I am thinking about calling it git-diff-status) would\nbe that the latter always has two plus or minus signs instead of\none, and lines with a single plus or minus would be an\nindication that HEAD and index have drifted. In other words,\nthe largest benefit of \"combined diff\" which is to simplify\ntrivial \"The result took this one not that one wholesale\"\ndifferences would not be felt.\n\nI have to visualize the result a bit before coding this.\n"},{"id":"25849","messageId":"17645.41334.9069.267396@cargo.ozlabs.ibm.com","threadId":"5361","inReplyTo":"7vhd02bn64.fsf@assigned-by-dhcp.cox.net","subject":"Re: git cherry-pick feature request","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-08-24T12:54:14Z","receivedAt":"2006-08-24T12:54:14Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> The combined diff (-c and --cc) comparison works by comparing a\n> single post-image (merge result) with multiple pre-images, so I\n> think it is reasonable to compare the working tree files as the\n> post-image and cached and HEAD-tree versions as the preimages.\n\nYes, I think that is probably the most useful way around.\n\n> I am not sure how useful this would be though -- I am guessing\n> that in most people's workflow the index and the HEAD would\n> exactly match most of the time, since that is the way Linus\n> encourages (and I follow that myself). So for that extreme use\n> case, the difference between \"diff-index HEAD\" and the proposed\n> command (I am thinking about calling it git-diff-status) would\n> be that the latter always has two plus or minus signs instead of\n> one, and lines with a single plus or minus would be an\n> indication that HEAD and index have drifted. In other words,\n> the largest benefit of \"combined diff\" which is to simplify\n> trivial \"The result took this one not that one wholesale\"\n> differences would not be felt.\n\nThe tool I am writing knows whether the index matches the HEAD or the\nworking directory, and uses a simple git diff-index -p in those\ncases. The only time when the 3-way diff would be needed is when the\nuser wants to commit a subset of the changes in the working version,\nbecause then the index (== changes to be committed) would be different\nfrom both the HEAD and the working directory.\n\nI could just do the two diffs and combine them in Tcl; I have done\nthat sort of thing in dirdiff. It gets a bit complicated though, and\ngiven that we already have C code for an N-way diff, I thought it made\nsense to reuse it.\n\nThanks,\nPaul.\n"}]}