{"thread":{"id":"44925","subject":"Idea: Add a filter option to 'git rebase'","startedAt":"2017-01-20T22:28:15Z","lastAt":"2017-01-23T11:57:44Z","messageCount":4,"participants":["Philip Oakley","Thomas Braun","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309866","messageId":"8AED6D90D2B64AE3A63C6195CA983FE8@PhilipOakley","threadId":"44925","inReplyTo":null,"subject":"Idea: Add a filter option to 'git rebase'","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-20T22:28:15Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"A recent question on stackoverflow \nhttp://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase \nsought to remove automatically commits that could be identified by relevant \nwords in the commit message.\n\nI had thought that the ubiquitous `git filter-branch` should be able to do \nthis sort of thing. I was wrong. (It was pointed out to me that...) The man \npage notes that removing a commit via filter-branch does not remove the \nchanges from following commits and directs readers to using `git rebase(1)`.\n\nHowever the rebase command does not have any filter option to allow the \nautomatic population of its TODO list with the appropriate \npick/edit/drop/etc. values.\n\nIt does feel as if a --filter style option would be a useful addition to \nrebase to complement the filter-branch options once the current conversion \nfrom script to code is complete.\n\nIs this something that should be put in the 'worth considering' pile?\n\n--\nPhilip \n\n"},{"id":"309876","messageId":"0bd00cda-65d0-eeba-d8b9-a839e76d8e88@virtuell-zuhause.de","threadId":"44925","inReplyTo":"8AED6D90D2B64AE3A63C6195CA983FE8@PhilipOakley","subject":"Re: Idea: Add a filter option to 'git rebase'","fromName":"Thomas Braun","fromEmail":"thomas.braun@virtuell-zuhause.de","sentAt":"2017-01-20T23:35:22Z","receivedAt":"2017-01-20T23:57:01Z","isPatch":false,"sender":{"key":"thomas.braun@virtuell-zuhause.de","avatar":"https://avatars.githubusercontent.com/u/1185677?v=4"},"body":"Am 20.01.2017 um 23:28 schrieb Philip Oakley:\n> A recent question on stackoverflow\n> http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase\n> sought to remove automatically commits that could be identified by\n> relevant words in the commit message.\n> \n> I had thought that the ubiquitous `git filter-branch` should be able to\n> do this sort of thing. I was wrong. (It was pointed out to me that...)\n> The man page notes that removing a commit via filter-branch does not\n> remove the changes from following commits and directs readers to using\n> `git rebase(1)`.\n> \n> However the rebase command does not have any filter option to allow the\n> automatic population of its TODO list with the appropriate\n> pick/edit/drop/etc. values.\n\nWell you can use an arbitrary shell command as editor, so something like\n\n$ GIT_SEQUENCE_EDITOR=\"sed -i -re 's/^pick /edit /'\" git rebase -i master\n\nwill change pick to edit of all commits.\n\nMaybe that can be mentioned in the man page of rebase?\n"},{"id":"309912","messageId":"7EEBBEA4046743C9AE04AE50EE30D72A@PhilipOakley","threadId":"44925","inReplyTo":"0bd00cda-65d0-eeba-d8b9-a839e76d8e88@virtuell-zuhause.de","subject":"Re: Idea: Add a filter option to 'git rebase'","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-21T23:18:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Thomas Braun\"  Friday, January 20, 2017 11:35 PM\n> Am 20.01.2017 um 23:28 schrieb Philip Oakley:\n>> A recent question on stackoverflow\n>> http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase\n>> sought to remove automatically commits that could be identified by\n>> relevant words in the commit message.\n>>\n>> I had thought that the ubiquitous `git filter-branch` should be able to\n>> do this sort of thing. I was wrong. (It was pointed out to me that...)\n>> The man page notes that removing a commit via filter-branch does not\n>> remove the changes from following commits and directs readers to using\n>> `git rebase(1)`.\n>>\n>> However the rebase command does not have any filter option to allow the\n>> automatic population of its TODO list with the appropriate\n>> pick/edit/drop/etc. values.\n>\n> Well you can use an arbitrary shell command as editor, so something like\n>\n> $ GIT_SEQUENCE_EDITOR=\"sed -i -re 's/^pick /edit /'\" git rebase -i master\n>\n> will change pick to edit of all commits.\n>\n> Maybe that can be mentioned in the man page of rebase?\n>\n\nI had been more thinking of a process that passed single sha1's to the \nfilter on each pass through the rebase list, so that the coding was simpler, \nplus the --interactive could be used, if required, for final refinement \n(gitk being handy for that).\n\nHowever, a mention in the man pages would be zero code cost, and could help.\n\n--\n\nPhilip \n\n"},{"id":"309973","messageId":"alpine.DEB.2.20.1701231214190.3469@virtualbox","threadId":"44925","inReplyTo":"7EEBBEA4046743C9AE04AE50EE30D72A@PhilipOakley","subject":"Re: Idea: Add a filter option to 'git rebase'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-23T11:57:18Z","receivedAt":"2017-01-23T11:57:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jan 2017, Philip Oakley wrote:\n\n> From: \"Thomas Braun\"  Friday, January 20, 2017 11:35 PM\n> > Am 20.01.2017 um 23:28 schrieb Philip Oakley:\n> > > A recent question on stackoverflow\n> > > http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase\n> > > sought to remove automatically commits that could be identified by\n> > > relevant words in the commit message.\n\nInteresting. As long as those magic words appear in the oneline, I would\nsimply call the command \":%s/^pick.*<magic-word>/#&/\".\n\nBut that is neither scripted nor does it work with magic words elsewhere\nin the commit message (let alone more sophisticated filtering based on,\nsay, authorship or magic words in the diff's \"+\" lines).\n\n> > > I had thought that the ubiquitous `git filter-branch` should be able\n> > > to do this sort of thing. I was wrong. (It was pointed out to me\n> > > that...) The man page notes that removing a commit via filter-branch\n> > > does not remove the changes from following commits and directs\n> > > readers to using `git rebase(1)`.\n\nRight, filter-branch never cherry-picks patches, but instead complete\ntrees.\n\n> > > However the rebase command does not have any filter option to allow\n> > > the automatic population of its TODO list with the appropriate\n> > > pick/edit/drop/etc. values.\n> >\n> > Well you can use an arbitrary shell command as editor, so something\n> > like\n> >\n> > $ GIT_SEQUENCE_EDITOR=\"sed -i -re 's/^pick /edit /'\" git rebase -i master\n> >\n> > will change pick to edit of all commits.\n> >\n> > Maybe that can be mentioned in the man page of rebase?\n\nPlease note that using a script instead of a command, you can do really\nsophisticated things including sophisticated re-writing of the edit script\nas well as calling the GIT_EDITOR in the end to re-establish\ninteractivity. I do exactly that in my Git garden shears [*1*].\n\n> I had been more thinking of a process that passed single sha1's to the\n> filter on each pass through the rebase list, so that the coding was\n> simpler, plus the --interactive could be used, if required, for final\n> refinement (gitk being handy for that).\n> \n> However, a mention in the man pages would be zero code cost, and could\n> help.\n\nIn the (frustratingly) long run, we will want to add a command-line option\nthat allows overriding the edit script generation, paired with a\ncommand-line option that generates the current version of the edit script\n(in my rebase--helper work that is still under review, the latter option\nalready exists).\n\nThat way, you have full flexibility and could even generate the entire\nedit script from scratch, rather than letting rebase -i generate one and\nthen filtering it.\n\nCiao,\nJohannes\n\nFootnote *1*:\nhttps://github.com/git-for-windows/build-extra/blob/master/shears.sh\n"}]}