{"thread":{"id":"13589","subject":"Understanding git filter-branch --subdirectory-filter behaviour","startedAt":"2008-05-20T20:11:55Z","lastAt":"2008-05-22T18:05:21Z","messageCount":3,"participants":["David Tweed","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77336","messageId":"e1dab3980805201311m3cbde4f2id8c3493a25745238@mail.gmail.com","threadId":"13589","inReplyTo":null,"subject":"Understanding git filter-branch --subdirectory-filter behaviour","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-05-20T20:11:55Z","receivedAt":"2008-05-20T20:11:55Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"Hi, I'm experimenting with git filter-branch --subdirectory-filter\n(being specific since it appears to have several special code branches\nin the script) and getting results that I don't understand. Firstly,\ncan I confirm what appears implied by the man-page but I can't find\nexplicitly stated:\n\ngit filter-branch HEAD\n\nis expected to do its filtering on the branch HEAD is on the entire\nDAG all the way back to the initial commit, even if this is a DAG with\nmultiple branches splitting off and remerging?\n\nI'm trying this on a repo (copy) containing a directory WRITING,\nalthough not quite all the way back to the repo creation getting:\n\n$ git filter-branch --subdirectory-filter WRITING/ HEAD\nRewrite 42f24be8d8198738134a19471697b39359199fa3 (351/351)\nRef 'refs/heads/master' was rewritten\n\n$ git rev-list HEAD | wc\n 55 55 2255\n\nLooking at this with gitk and git log confirms 55 commits, and the\nfirst commit is the one immediately after the first merge encountered\n(the commit that occured just after the merge) when walking backwards\nin history. Is this something that would be expected?\n\nDigging a little into the shell-script I find the list of commits is\ngenerated with\n\ngit rev-list --reverse --topo-order --default HEAD --parents HEAD\n--full-history -- WRITING\n\nand (adding --pretty so I can easily read it) running this manually\ngives 351 entries and looks to contain the expected commits. So I'm\nconfused what's happening?\n\nIf this is expected, is there an refspec I'm missing to get\nfilter-branch to filter the entire repo?\n\n(FWIW, git version 1.5.5.1.316.g377d9 on x86-64 Linux.)\n\nMany thanks,\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"},{"id":"77371","messageId":"4833C07B.3060004@viscovery.net","threadId":"13589","inReplyTo":"e1dab3980805201311m3cbde4f2id8c3493a25745238@mail.gmail.com","subject":"Re: Understanding git filter-branch --subdirectory-filter behaviour","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-05-21T06:26:03Z","receivedAt":"2008-05-21T06:26:03Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"David Tweed schrieb:\n> $ git filter-branch --subdirectory-filter WRITING/ HEAD\n> Rewrite 42f24be8d8198738134a19471697b39359199fa3 (351/351)\n> Ref 'refs/heads/master' was rewritten\n> \n> $ git rev-list HEAD | wc\n> 55 55 2255\n> \n...\n> \n> Digging a little into the shell-script I find the list of commits is\n> generated with\n> \n> git rev-list --reverse --topo-order --default HEAD --parents HEAD\n> --full-history -- WRITING\n> \n> and (adding --pretty so I can easily read it) running this manually\n> gives 351 entries and looks to contain the expected commits. So I'm\n> confused what's happening?\n\nThat's difficult to tell without a peek at the repository.\n\nDid you compare 'gitk HEAD' to 'gitk HEAD -- WRITING'? I'd expect the\nlatter to be a subset of the former. Note that with a path specified\n\"history simplification\" happens, which means that you won't see as many\nmerges as when no path is specified.\n\n-- Hannes\n"},{"id":"77486","messageId":"e1dab3980805221105k15908606s3397ba1a96ecf081@mail.gmail.com","threadId":"13589","inReplyTo":"4833C07B.3060004@viscovery.net","subject":"Re: Understanding git filter-branch --subdirectory-filter behaviour","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2008-05-22T18:05:21Z","receivedAt":"2008-05-22T18:05:21Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Wed, May 21, 2008 at 7:26 AM, Johannes Sixt wrote:\n> David Tweed schrieb:\n> That's difficult to tell without a peek at the repository.\n>\n> Did you compare 'gitk HEAD' to 'gitk HEAD -- WRITING'? I'd expect the\n> latter to be a subset of the former. Note that with a path specified\n> \"history simplification\" happens, which means that you won't see as many\n> merges as when no path is specified.\n\nJust did that in the before-filtering repository, and \"gitk HEAD --\nWRITING\" doesn't have any branches after the simplification but it\ndoes go back to the first commit in the repository creating WRITING\n(presumably simplifying out several branches that didn't affect\nWRITING), whereas the filtered repository starts on the commit\nimmediately after the first merge you encounter walking backwards in\ntime. I was prepared for the branch structure to possibly simplify\nwhilst keeping all the commits that change that directory, but was a\nbit surprised it stopped before the first merge.\n\n\n$ git log HEAD -- WRITING | wc -l\n 2033\n\n\n$ git log | wc -l\n329\n\nSo it's definitely creating a smaller repo than git log filtering. If\nyou would be interested in looking at the actual repo (about 17M) let\nme know and I'll send you tarball details via personal mail.\n\nAnyway, many thanks for the insight and assistance,\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"while having code so boring anyone can maintain it, use Python.\" --\nattempted insult seen on slashdot\n"}]}