{"thread":{"id":"25720","subject":"scan entire repo for changes to file","startedAt":"2010-11-12T01:28:20Z","lastAt":"2010-11-18T00:47:10Z","messageCount":6,"participants":["Neal Kreitzinger","Martin von Zweigbergk","Jonathan Nieder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155749","messageId":"ibi59v$pjg$1@dough.gmane.org","threadId":"25720","inReplyTo":null,"subject":"scan entire repo for changes to file","fromName":"Neal Kreitzinger","fromEmail":"neal@rsss.com","sentAt":"2010-11-12T01:28:20Z","receivedAt":"2010-11-12T01:28:20Z","isPatch":false,"sender":{"key":"neal@rsss.com","avatar":null},"body":"Is there a way to scan my entire repo (many unmerged branches) for any \nchanges to a file?\ne.g.\n$ git log * -- somepath/myblob\nwould return all commits in the repo that changed myblob.\n\nv/r,\nNeal \n"},{"id":"155751","messageId":"AANLkTi=uKhrvAS6ApnmCZnfbFboYU77rNcKDpaSBn1id@mail.gmail.com","threadId":"25720","inReplyTo":"ibi59v$pjg$1@dough.gmane.org","subject":"Re: scan entire repo for changes to file","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-11-12T01:35:39Z","receivedAt":"2010-11-12T01:35:39Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger wrote:\n> Is there a way to scan my entire repo (many unmerged branches) for any\n> changes to a file?\n> e.g.\n> $ git log * -- somepath/myblob\n> would return all commits in the repo that changed myblob.\n>\n> v/r,\n> Neal\n\nMight replacing '*' by '--all' give you what are looking for?\n"},{"id":"155752","messageId":"20101112014434.GA10679@burratino","threadId":"25720","inReplyTo":"AANLkTi=uKhrvAS6ApnmCZnfbFboYU77rNcKDpaSBn1id@mail.gmail.com","subject":"Re: scan entire repo for changes to file","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-12T01:44:34Z","receivedAt":"2010-11-12T01:44:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Martin von Zweigbergk wrote:\n> On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger wrote:\n\n>> Is there a way to scan my entire repo (many unmerged branches) for any\n>> changes to a file?\n>> e.g.\n>> $ git log * -- somepath/myblob\n>> would return all commits in the repo that changed myblob.\n>\n> Might replacing '*' by '--all' give you what are looking for?\n\nProbably with --full-history if you want to know what happened on\nhistoric branches, too.\n"},{"id":"156004","messageId":"7vk4kdi2h4.fsf@alter.siamese.dyndns.org","threadId":"25720","inReplyTo":"20101112014434.GA10679@burratino","subject":"Re: scan entire repo for changes to file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-16T17:48:39Z","receivedAt":"2010-11-16T17:48:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Martin von Zweigbergk wrote:\n>> On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger wrote:\n>\n>>> Is there a way to scan my entire repo (many unmerged branches) for any\n>>> changes to a file?\n>>> e.g.\n>>> $ git log * -- somepath/myblob\n>>> would return all commits in the repo that changed myblob.\n>>\n>> Might replacing '*' by '--all' give you what are looking for?\n>\n> Probably with --full-history if you want to know what happened on\n> historic branches, too.\n\nYou would need to clarify what you mean by \"historic branches\" here.\n"},{"id":"156008","messageId":"20101116182043.GA14552@burratino","threadId":"25720","inReplyTo":"7vk4kdi2h4.fsf@alter.siamese.dyndns.org","subject":"Re: scan entire repo for changes to file","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-16T18:20:43Z","receivedAt":"2010-11-16T18:20:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>> Martin von Zweigbergk wrote:\n>>> On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger wrote:\n\n>>>> Is there a way to scan my entire repo (many unmerged branches) for any\n>>>> changes to a file?\n>>>> e.g.\n>>>> $ git log * -- somepath/myblob\n>>>> would return all commits in the repo that changed myblob.\n>>>\n>>> Might replacing '*' by '--all' give you what are looking for?\n>>\n>> Probably with --full-history if you want to know what happened on\n>> historic branches, too.\n>\n> You would need to clarify what you mean by \"historic branches\" here.\n\nYes, quite right. I meant failed experiments of a certain kind.\n\nThe \"git log -- path\" facility can be used to learn the nature and\norigin of a collection of files.\n\n\t$ git log --graph --oneline -- block-sha1/\n\t* 078e9bc msvc: Select the \"fast\" definition of the {get,put}_be32() macros\n[...]\n\t* d7c208a Add new optimized C 'block-sha1' routines\n\nThe result is a list of commits that explains the current state of\nthat file, without commits irrelevant to that purpose.\n\nWhat happens to merges? Consider a history like this (history flowing\nleft to right):\n\n A --- B --- C --- D --- E --- F --- G ---- M --- H\n \\ /\n I ... ... J\n\nThere is a main line and a side branch. On the mainline, the selected\nfiles have been getting better and better. The side branch does not\ntouch those files. Then the side branch would irrelevant to the\nhistory of those files.\n\nTo flesh out this idea, git history simplification. When walking\nthrough history, if a merge is encountered (M) and one of the parents\nalready matches the resulting state (G), then git will follow that\nparent and ignore the others. If no parent matches the resulting\nstate, git follows all parents. So we get a simpler history that\nshould still adequately explain the result.\n\nConsider another scenario, though:\n\n A --- B --- C --- D --- E --- F --- G ---- M' --- H'\n \\ /\n I' ... ... J'\n\nThere is a mainline and a side branch. On the mainline, the selected\nfiles have been getting better and better. On the side branch, there\nwas an abortive experiment; some changes were made to the selected\nfiles there, but none of these changes survived as far as the merge M'.\n\nThe side branch is _still_ irrelevant to the purpose of explaining the\ncurrent state of those files. Git will notice that (G matches M') and\nignore the side branch. But if your goal is not to explain the\ncurrent state but to delve into the history of all thoughts this\nproject remembers on a subject, such history simplification would not\nbe appropriate and you should be using the --full-history option.\n\nThe History Simplification section of git-log(1) has details.\n\nCaveat: the list of commits selected with --full-history --dense do\nnot convey a coherent history. M' is uninteresting but some of the\ncommits on the I' ... J' track are; how do we stitch the interesting\ncommits together? So history visualization tools cop out and show\nall merges when --full-history is enabled. (Put another way,\n--parents --full-history implies --no-dense.)\n\nHope that helps.\n"},{"id":"156073","messageId":"ic1t5i$9hs$1@dough.gmane.org","threadId":"25720","inReplyTo":"20101116182043.GA14552@burratino","subject":"Re: scan entire repo for changes to file","fromName":"Neal Kreitzinger","fromEmail":"neal@rsss.com","sentAt":"2010-11-18T00:47:10Z","receivedAt":"2010-11-18T00:47:10Z","isPatch":false,"sender":{"key":"neal@rsss.com","avatar":null},"body":"\n\"Jonathan Nieder\" wrote in message \nnews:20101116182043.GA14552@burratino...\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>> Martin von Zweigbergk wrote:\n>>>> On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger \n>>>> wrote:\n>\n>>>>> Is there a way to scan my entire repo (many unmerged branches) for any\n>>>>> changes to a file?\n>>>>> e.g.\n>>>>> $ git log * -- somepath/myblob\n>>>>> would return all commits in the repo that changed myblob.\n>>>>\n>>>> Might replacing '*' by '--all' give you what are looking for?\n>>>\n>>> Probably with --full-history if you want to know what happened on\n>>> historic branches, too.\n>>\n>> You would need to clarify what you mean by \"historic branches\" here.\n>\n> Yes, quite right. I meant failed experiments of a certain kind.\n>\n> The \"git log -- path\" facility can be used to learn the nature and\n> origin of a collection of files.\n>\n> $ git log --graph --oneline -- block-sha1/\n> * 078e9bc msvc: Select the \"fast\" definition of the {get,put}_be32() \n> macros\n> [...]\n> * d7c208a Add new optimized C 'block-sha1' routines\n>\n> The result is a list of commits that explains the current state of\n> that file, without commits irrelevant to that purpose.\n>\n> What happens to merges? Consider a history like this (history flowing\n> left to right):\n>\n> A --- B --- C --- D --- E --- F --- G ---- M --- H\n> \\ /\n> I ... ... J\n>\n> There is a main line and a side branch. On the mainline, the selected\n> files have been getting better and better. The side branch does not\n> touch those files. Then the side branch would irrelevant to the\n> history of those files.\n>\n> To flesh out this idea, git history simplification. When walking\n> through history, if a merge is encountered (M) and one of the parents\n> already matches the resulting state (G), then git will follow that\n> parent and ignore the others. If no parent matches the resulting\n> state, git follows all parents. So we get a simpler history that\n> should still adequately explain the result.\n>\n> Consider another scenario, though:\n>\n> A --- B --- C --- D --- E --- F --- G ---- M' --- H'\n> \\ /\n> I' ... ... J'\n>\n> There is a mainline and a side branch. On the mainline, the selected\n> files have been getting better and better. On the side branch, there\n> was an abortive experiment; some changes were made to the selected\n> files there, but none of these changes survived as far as the merge M'.\n>\n> The side branch is _still_ irrelevant to the purpose of explaining the\n> current state of those files. Git will notice that (G matches M') and\n> ignore the side branch. But if your goal is not to explain the\n> current state but to delve into the history of all thoughts this\n> project remembers on a subject, such history simplification would not\n> be appropriate and you should be using the --full-history option.\n>\n> The History Simplification section of git-log(1) has details.\n>\n> Caveat: the list of commits selected with --full-history --dense do\n> not convey a coherent history. M' is uninteresting but some of the\n> commits on the I' ... J' track are; how do we stitch the interesting\n> commits together? So history visualization tools cop out and show\n> all merges when --full-history is enabled. (Put another way,\n> --parents --full-history implies --no-dense.)\n>\n> Hope that helps.\n\nThank you for the explanations. I needed to use --full-history in addition \nto --all this time because I was querying our 'QA' repo. Our projects push \ntheir commits up to the QA repo and then the testers pull down from the QA \nrepo a commit they want to test into a test repo that points to its own set \nof data/DB files. Our commits contain the binaries along with the source. \nThe test repos are sparse checkouts of binaries only. As projects do \nvarious interactive rebases and deliver to QA without necessarily rebasing \non master branch's HEAD and while master branch is also advancing and being \ntested, the QA repo acquires many lines of development. These repos in \nquestion are for a new system so we don't have anything in true production \nyet and therefore our master branch is tested in-house rather than by \nend-users at this point. (For our productional system the master branch is \nstable, but not for the new system I'm talking about in this context.) \nUsing --all --full-history, I can interrogate everything being tested by \nquerying the QA repo. In this case, I checked to see what the impact of a \nnewfound bug was on current testing by checking if any projects' QA \ndeliveries had the buggy modules in any of their changesets. Of course, I \nfound that some projects had modified these modules so I was then able to \nassess the impact and devise the proper remediation.\n\nThis is my first newsgroup and I'm learning as I go so I'm not sure if I'm \ndoing it right. Jonathan, did this reply automatically show up in your \nemail in addition to showing up on the newsgroup?\n\nv/r,\nNeal \n"}]}