{"thread":{"id":"7944","subject":"FFmpeg considering GIT","startedAt":"2007-05-02T09:29:33Z","lastAt":"2007-05-10T16:52:15Z","messageCount":66,"participants":["Panagiotis Issaris","Jakub Narebski","Petr Baudis","Martin Langhoff","Uwe Kleine-König","david@lang.hm","Johan Herland","Alex Riesen","Andy Parkins","Andrew Ruder","Michael Niedermayer","Johannes Sixt","Nicolas Pitre","Florian Weimer","Carl Worth","Linus Torvalds","Karl Hasselström","Junio C Hamano","Marco Costalba","Paul Mackerras","Jan Hudec","Gábor Farkas","Randal L. Schwartz","Shawn O. Pearce","Jeff King","Robin Rosenberg","Fredrik Kuivinen","Pavel Roskin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40884","messageId":"loom.20070502T111026-882@post.gmane.org","threadId":"7944","inReplyTo":null,"subject":"FFmpeg considering GIT","fromName":"Panagiotis Issaris","fromEmail":"takis.issaris@uhasselt.be","sentAt":"2007-05-02T09:29:33Z","receivedAt":"2007-05-02T09:29:33Z","isPatch":false,"sender":{"key":"takis.issaris@uhasselt.be","avatar":null},"body":"Hi,\n\nSome of the people of the FFmpeg project are looking at both GIT and Mercurial\nas possible replacements for the current Subversion repository. They have some\nquestions regarding the possibility of doing certain things, which I prefer not\nto answer as I am not sure my answer would be correct :) Which is why I am\nposting here...\n\nThe questions are stated in this e-mail [1]. One of the things that are being\ndiscussed is the following action on a publicly mirrored repository:\ngit branch -m master dead_end\ngit branch -m last_good master\n\nI'd think this would fail as people could have pulled from the repository while\nthe \"dead_end\" commit was already available, right?\n\nThere are some other things the FFmpeg maintainer mentions, namely:\n* He wants to be able to revert a commit in some way without \"wiping\" history.\nThat is without committing a patch which reverses the broken commit, as this\nwould pollute \"git blame\". The maintainer sees this as critical feature for\nswitching to git as it apparently can be doing using Subversion:\n\"in svn we can do this with svn cp from a specific\nrevission git and mercurial lack proper copy support\"\n\n* And finally, he noticed that when copying files, history is sometimes lost\n(mentioned at the bottom of [1]).\n\n\nAny answers are greatly appreciated, as I'd really like to see FFmpeg switch to\nGIT.\n\nWith friendly regards,\nTakis\n\n[1]\nhttp://article.gmane.org/gmane.comp.video.ffmpeg.devel/49673\n[2]\nhttp://article.gmane.org/gmane.comp.video.ffmpeg.devel/49656\n"},{"id":"40929","messageId":"f1b806$nc7$1@sea.gmane.org","threadId":"7944","inReplyTo":"loom.20070502T111026-882@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-02T23:48:26Z","receivedAt":"2007-05-02T23:48:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Panagiotis Issaris wrote:\n\n> Some of the people of the FFmpeg project are looking at both GIT and Mercurial\n> as possible replacements for the current Subversion repository. They have some\n> questions regarding the possibility of doing certain things, which I prefer not\n> to answer as I am not sure my answer would be correct :) Which is why I am\n> posting here...\n> \n> The questions are stated in this e-mail [1]. One of the things that are being\n> discussed is the following action on a publicly mirrored repository:\n> git branch -m master dead_end\n> git branch -m last_good master\n> \n> I'd think this would fail as people could have pulled from the repository while\n> the \"dead_end\" commit was already available, right?\n> \n> There are some other things the FFmpeg maintainer mentions, namely:\n> * He wants to be able to revert a commit in some way without \"wiping\" history.\n> That is without committing a patch which reverses the broken commit, as this\n> would pollute \"git blame\". The maintainer sees this as critical feature for\n> switching to git as it apparently can be doing using Subversion:\n> \"in svn we can do this with svn cp from a specific\n> revission git and mercurial lack proper copy support\"\n\nAbout removing a commit: assume that you have the following history\n\n A---B---C---D---E <--- branch\n\nNow you have noticed that commit C is wrong, and it should not be there.\nOne solution, which is used usually if the history was published, is to\nrevert a commit, resulting in the following history:\n\n A---B---C---D---E---C^-1 <--- branch\n\n(which is what git-revert does).\n\nNow if you didn't publish this history, or you don't care that you are\nrewriting history, it is fairly easy to remove commit C (for example\nusing \"git rebase --onto B D E\" command), resulting in the following\nhistory:\n\n A---B---C---D---E\n \\\n \\\n \\----D'--E' <--- branch\n\n(which after pruning would result in A---B---D'--E' history).\n\nThe problem exists _only_ if somebody based his/her work on commit\nC or its descendant, i.e. original D, E commits. He/she would have\nto rebase his/her work on top of _changed_ (moved) commits D' and E'.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"40930","messageId":"20070503010312.GF4489@pasky.or.cz","threadId":"7944","inReplyTo":"f1b806$nc7$1@sea.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-03T01:03:12Z","receivedAt":"2007-05-03T01:03:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:\n> About removing a commit: assume that you have the following history\n> The problem exists _only_ if somebody based his/her work on commit\n> C or its descendant, i.e. original D, E commits. He/she would have\n> to rebase his/her work on top of _changed_ (moved) commits D' and E'.\n\n\"_Only_\"?\n\nI think it's just totally unsustainable to do this history rewriting in\nan \"upstream\" git repository. You will get horridly confused, then\nfrustrated and then just move from software development to beekeeping.\n\nImagine what will happen in gitk --all - you will see many commits\nseveral times in a row because each is part of different subhistory for\na given head. Merging between branches will become totally impossible.\nPeople keeping their clones (or even forking history) will be confused\nand horrified. Bits of patches inbetween the original commit and the\nrevert moment will lose their meaning, the history won't be trustworthy\nanymore at all.\n\nIn the end, using these practices git will end up useful roughly as a\nfaster but crippled SVN. So please don't ever just suggests how random\ngit commands and features with special usage might work without\ncarefully explaining the implications and why this is _not_ the way to\nuse git. If ffmpeg insists on having an X feature and it's not feasible\nto make it work well with principles git is built on, ffmpeg will be\nbetter off without git and staying with SVN, if anything to not make git\nbad name between frustrated ffmpeg users and developers.\n\nPS: Beekeeping _is_ kind of cool, really.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"40931","messageId":"46a038f90705021848w3d3b8f6pdbd100e8419f1b74@mail.gmail.com","threadId":"7944","inReplyTo":"loom.20070502T111026-882@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-03T01:48:03Z","receivedAt":"2007-05-03T01:48:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/2/07, Panagiotis Issaris wrote:\n> The questions are stated in this e-mail [1]. One of the things that are being\n> discussed is the following action on a publicly mirrored repository:\n> git branch -m master dead_end\n> git branch -m last_good master\n>\n> I'd think this would fail as people could have pulled from the repository while\n> the \"dead_end\" commit was already available, right?\n\nYes - that's something you shouldn't do on a normal branch... but\nthat's a feature ;-) -- we call it re-winding a branch.\n\nA good workaround if you expect to go down some dead_ends is to have\nan experimental branch that you pre-announce that will be rewound\nregularly. On the git repo, Junio does exactly that with \"pu\"\n(\"proposed updates\"), and several feature-development branches have\nbeen dropped or rewound at times.\n\nNow, for your main dev and various maintenance branches, just do a\nrevert. If something made it into the main dev branch it means it's\nnot so experimental anymore and all the developers are building\nfurther development on top. At that stage, the potential mistake has\nmade it \"quite far\" so you can't rewind it and pretend it didn't exist\n;-)\n\nSo the good practice is to never rewind the long-term branches people\nbase their work on. Branches in your repo, and public branches clearly\nmarked as experimental, anything goes.\n\ncheers,\n\n\nmartin\n"},{"id":"40967","messageId":"20070503180016.GB21333@informatik.uni-freiburg.de","threadId":"7944","inReplyTo":"loom.20070502T111026-882@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-05-03T18:00:16Z","receivedAt":"2007-05-03T18:00:16Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nPanagiotis Issaris wrote:\n> There are some other things the FFmpeg maintainer mentions, namely:\n> * He wants to be able to revert a commit in some way without \"wiping\" history.\n> That is without committing a patch which reverses the broken commit, as this\n> would pollute \"git blame\". The maintainer sees this as critical feature for\n> switching to git as it apparently can be doing using Subversion:\n> \"in svn we can do this with svn cp from a specific\n> revission git and mercurial lack proper copy support\"\nTo add more context, Michael Niedermayer (=FFmpeg maintainer) wrote (in\n[1]):\n\n\tlet me explain a little bit why this is critically needed\n\tthink of someone misstakely commiting the whole ffmpeg\n\treindented or mistakely commiting a old ffmpeg version over the\n\tnew or another total messup, these things do happen, and\n\tespecially if they cannot be corrected and at the time where\n\tnone of the developers is around\n\nFor me this sounds like: I don't want people with commit access doing\nthis, and if they do, I want to be able to revert it.\n\nIf FFmpeg used a development scheme similar to the linux kernel, there\nshould be no need for revert: The upstream maintainer only needs to pay\nattention to the things he does directly (he probably does in any case)\nand check the patches he applies and the trees he pulls. As git gives a\ndiffstat on pull and he reviews patches before applying the problem is\nmaybe gone?\n\nCommit access is simply different in a distributed environment, see\nhttp://thread.gmane.org/gmane.comp.version-control.git/45849/focus=45956\n\nBest regards\nUwe\n\n> [1]\n> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/49673\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2\n"},{"id":"40976","messageId":"20070503200013.GG4489@pasky.or.cz","threadId":"7944","inReplyTo":"20070503180016.GB21333@informatik.uni-freiburg.de","subject":"Re: FFmpeg considering GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-03T20:00:13Z","receivedAt":"2007-05-03T20:00:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote:\n> Panagiotis Issaris wrote:\n> > There are some other things the FFmpeg maintainer mentions, namely:\n> > * He wants to be able to revert a commit in some way without \"wiping\" history.\n> > That is without committing a patch which reverses the broken commit, as this\n> > would pollute \"git blame\". The maintainer sees this as critical feature for\n> > switching to git as it apparently can be doing using Subversion:\n> > \"in svn we can do this with svn cp from a specific\n> > revission git and mercurial lack proper copy support\"\n> To add more context, Michael Niedermayer (=FFmpeg maintainer) wrote (in\n> [1]):\n> \n> \tlet me explain a little bit why this is critically needed\n> \tthink of someone misstakely commiting the whole ffmpeg\n> \treindented or mistakely commiting a old ffmpeg version over the\n> \tnew or another total messup, these things do happen, and\n> \tespecially if they cannot be corrected and at the time where\n> \tnone of the developers is around\n> \n> For me this sounds like: I don't want people with commit access doing\n> this, and if they do, I want to be able to revert it.\n> \n> If FFmpeg used a development scheme similar to the linux kernel, there\n> should be no need for revert: The upstream maintainer only needs to pay\n> attention to the things he does directly (he probably does in any case)\n> and check the patches he applies and the trees he pulls. As git gives a\n> diffstat on pull and he reviews patches before applying the problem is\n> maybe gone?\n> \n> Commit access is simply different in a distributed environment, see\n> http://thread.gmane.org/gmane.comp.version-control.git/45849/focus=45956\n\n I believe that the development scheme is largely independent on the\nversion control system, except that git makes the \"both ways\" equally\neasy. But that doesn't mean that the \"multiple people with commit\naccess\" scheme is wrong or anything. It has important upsides as well -\nthere's no single human point of failure (_yes_, if the maintainer gets\nstuck in hospital for two months you can fork and maintain own\nrepository, but then it's again just you and it is complicated socially\netc.), the load of the maintainer is significantly lowered, and in many\nprojects there is simply no \"single maintainer\" but a team of people\nwhere decisions are made by consensus.\n\n Still, if this kind of bogus change checkins happens at any frequent\nrate in the ffmpeg project, there is a serious problem somewhere. :-)\nBut I think the git way of alleviating this problem would be to have a\nway to hint the pickaxe and blame tools to ignore changes in given\ncommits. So, you don't _cover up_ the messy things that happened during\nthe history, but avoid in getting in the way in your view. You can still\nlook it up (with git log or something) in case you'd need to (perhaps\nthe revert patch was a bit complicated because of conflicting with some\nother changes, and a subtle bug was introduced; this would be thousand\ntimes harder to track down if you would've rewritten the history).\n\n Would crafting up a patch to implement something like this help ffmpeg\npeople in their decision?\n\n Let's say you have .git/info/reverts with one \"revert pair\" (two\ncommit ids, one for the bogus change and one for reverting it) per line,\nand the blame/pickaxe tools take it into account. The downside is that\nthis isn't preserved over clones and fetches. That's a pretty big one.\n\n Another way might be to have say a magic \"Reverts: commitid\" line at\nthe last paragraph of a commit message recognized by git. The downside\nis that the body of commit message might have magic meaning for some\nnon-core plumbing; I'm not sure how big a downside that is. For adding\nit to commit header it might be a little bit too non-core, I might meet\nwith Linus' ethernal fury, and I'm not sure how big of a compatibility\nproblem would it be.\n\n Ideas?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"40978","messageId":"Pine.LNX.4.64.0705031302110.26172@asgard.lang.hm","threadId":"7944","inReplyTo":"20070503200013.GG4489@pasky.or.cz","subject":"Re: FFmpeg considering GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-05-03T20:05:34Z","receivedAt":"2007-05-03T20:05:34Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 3 May 2007, Petr Baudis wrote:\n\n> On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote:\n>\n> I believe that the development scheme is largely independent on the\n> version control system, except that git makes the \"both ways\" equally\n> easy. But that doesn't mean that the \"multiple people with commit\n> access\" scheme is wrong or anything. It has important upsides as well -\n> there's no single human point of failure (_yes_, if the maintainer gets\n> stuck in hospital for two months you can fork and maintain own\n> repository, but then it's again just you and it is complicated socially\n> etc.), the load of the maintainer is significantly lowered, and in many\n> projects there is simply no \"single maintainer\" but a team of people\n> where decisions are made by consensus.\n>\n> Still, if this kind of bogus change checkins happens at any frequent\n> rate in the ffmpeg project, there is a serious problem somewhere. :-)\n> But I think the git way of alleviating this problem would be to have a\n> way to hint the pickaxe and blame tools to ignore changes in given\n> commits. So, you don't _cover up_ the messy things that happened during\n> the history, but avoid in getting in the way in your view. You can still\n> look it up (with git log or something) in case you'd need to (perhaps\n> the revert patch was a bit complicated because of conflicting with some\n> other changes, and a subtle bug was introduced; this would be thousand\n> times harder to track down if you would've rewritten the history).\n>\n> Would crafting up a patch to implement something like this help ffmpeg\n> people in their decision?\n\nis this needed?\n\nwouldn't you do something like\n\na--b--c--d\n\noops, b was really bad\n\nrebase c b\n\na--b--c--d\n \\\n c'--d'--e--f\n\nand you just start tagging d', e, f as the releases, logicly changing \nthings to\n\na--b--c'--d'--e--f\n \\\n c--d dead branch\n\nthe only thing that this costs is space. unless it's a 'mess up all the \nwhitespace in the entire tree' type of thing (and if it was, whoever \ndid the commit would see the _huge_ diffstat and probably catch it) it's \nnot likely to be a significant amount of space in the overall history.\n\nDavid Lang"},{"id":"40977","messageId":"20070503201338.GB18276@pasky.or.cz","threadId":"7944","inReplyTo":"Pine.LNX.4.64.0705031302110.26172@asgard.lang.hm","subject":"Re: FFmpeg considering GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-03T20:13:38Z","receivedAt":"2007-05-03T20:13:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 03, 2007 at 10:05:34PM CEST, david@lang.hm wrote:\n> On Thu, 3 May 2007, Petr Baudis wrote:\n> > Would crafting up a patch to implement something like this help ffmpeg\n> >people in their decision?\n> \n> is this needed?\n> \n> wouldn't you do something like\n> \n> a--b--c--d\n> \n> oops, b was really bad\n> \n> rebase c b\n..snip..\n\nThis is immensely problematic, but I think I've fully covered all my\nreservations in the other mail in this thread; if anything there was\nunclear or you disagree with something I said, please reply to it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"40999","messageId":"200705040242.46156.jnareb@gmail.com","threadId":"7944","inReplyTo":"20070503010312.GF4489@pasky.or.cz","subject":"Re: FFmpeg considering GIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-04T00:42:45Z","receivedAt":"2007-05-04T00:42:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n> On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:\n\n>> About removing a commit: assume that you have the following history\n>> The problem exists _only_ if somebody based his/her work on commit\n>> C or its descendant, i.e. original D, E commits. He/she would have\n>> to rebase his/her work on top of _changed_ (moved) commits D' and E'.\n> \n> \"_Only_\"?\n> \n> I think it's just totally unsustainable to do this history rewriting in\n> an \"upstream\" git repository. You will get horridly confused, then\n> frustrated and then just move from software development to beekeeping.\n\nPerhaps I should have said: \"There always would be problems if somebody\nbased his/her work on commit C or its descendant...\"\n\nBut there are some times when you can rewrite history without bad\nconsequences. \n\nYou can without any problems rewrite _unpublished_ commits; if one for\nexample pushes to public repo once per day, or few times a week,\nthere is time to remove a commit, or amend a commit, or change commit\ndeeper in a history. Or even use StGIT to manage patches, and change\ntheir sequence, add patch in the midle of patch series, split or join\npatches, all that working on creating 'a perfect patch [series]'.\n\nYou can rewrite a branch which never would be published, like feature\nbranches in git.git repository (which are visible only via 'pu' -- proposed\nupdates branch, which is meant to have history rewritten). Or you can\nannounce that given branch might be rewritten, and not to base any work\non it (well, you can, but you always should rebase before sending).\n\n\nBecause there always are, and always will be problems if somebody would\nbase work on series including now removed commit, even if SCM need not\nto rewrite history to remove a commit [*1*]. And with history rewriting\neven more so, for example accidental inclusion of removed commit.\n\nBesides I think it would be better to teach blame to ignore reversion\ncommits (for example based on first line of commit message) than to mess\nwith the history. Note also that git has more tools for forensic analysis\nthan git-blame; blame / annotate was added later because people are used\nto it (and it is I think better than any other, because it can detect\nmoving and copying code blocks). The primary examining tools are history\nbrowsing limited to specified pathspec, and pickaxe i.e. searching for\ncommits which changed given line.\n\nFootnotes:\n----------\n [1] Git began as content adressed filesystem, where each object is named\n by its contents (or rather cryptographics hash function of contents).\n This results in hash (object id) of commit identifying whole lineage\n of it, and makes signing specified commit (using signed tag)\n identifying / signing whole history.\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"41012","messageId":"200705040921.33443.johan@herland.net","threadId":"7944","inReplyTo":"200705040242.46156.jnareb@gmail.com","subject":"[RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-04T07:21:29Z","receivedAt":"2007-05-04T07:21:29Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 May 2007, Jakub Narebski wrote:\n> Besides I think it would be better to teach blame to ignore reversion\n> commits (for example based on first line of commit message) than to\n> mess with the history.\n\nI'm starting to see a pattern where people would like to tell git about \nmore complicated relationships between commits, so that git can make \nmore intelligent decisions when doing merge, blame, pickaxe, etc.\n\nAdding these relationships as part of the commit message seems like a \nreally stupid idea because git suddenly has to make sense of something \nit has never parsed before, thus making all future and former git \ncommit messages a potential target for pattern (mis)matching by git. \nAlso, we seem to forget that we already have the perfect place to put \nsuch information: The header fields preceding the commit message.\n\nI therefore propose adding header field names to commit objects that \nillustrate the relationships people want to tell git about. Examples \ninclude:\n\n1. \"Reverts\": Mark a commit as reverting another commit. This could be \nused by git-log to cancel out pairs of commits, resulting in a cleaner \nview of history. It can help blame/annotate. There are probably other \ntools that can benefit from this information also.\n\n2. \"Cherry-Pick\": When cherry-picking a commit onto another branch, you \nshould be able to tell git which commit you are cherry-picking \n(git-cherry-pick would of course do this automatically). This could \nenable git to make smarter decisions when merging the two branches: If \nthe cherry-picked commit would cause a conflict with the original \ncommit, git can either skip it (since it knows that one version of this \npatch is already present), or it can at least present the conflict to \nthe user with some more context than what is available today. Not to \nmention how this information could be used by blame/annotate.\n\n3. \"Rebased-From\": This one can be filled in automatically by \ngit-rebase, but when I think about it, it may be too similar \nto \"Cherry-Pick\" to warrant a separate field.\n\n4. \"Rebased-To\": When doing a rebase like the following:\n\n A---B---C---D---E <--- branch\n\n (Hmm. C is broken. Rebase D and E onto B)\n\n A---B---C---D---E\n \\\n \\--D'--E' <--- branch\n\n git-rebase could now add a dummy commit F* to E with \"Rebased-To: \n{Commit ID of D'}\", thus making:\n\n A---B---C---D---E---F*..\n \\ ,............: (yes, this is a poorly drawn meta-arrow)\n \\ v\n \\--D'--E' <--- branch\n\n This would make it easier for git to do the Right Thing when someone \nfollowing the old branch tries to pull after the rebase.\n\n5. Heck, while we're at it, move \"Signed-off-by\" into the header fields, \nwhere git can make more use of it.\n\n6. Finally, allow people to add custom header fields prefixed by \"X-\" \n(like in HTTP), and make it easy for them to extend git tools to use \nthese custom fields in various ways. If some of them end up being \nreally useful, we can import them into git (and lose the \"X-\" prefix).\n\n\nNow, in order to let people specify these fields we probably want to \nmake these fields names settable from the command line. It should also \nbe possible to use a template when doing the commit message in an \neditor. Something like:\n==========\nOptional headers fields (fill in if applicable)\nCherry-Pick: ________\nReverts: ________\nSigned-Off-By: ________\n\nYour commit message goes here:\n________________________________\n==========\n\nOf course, git would have to verify/sanitize these fields when input, so \nthey probably need some type information associated with them.\n\n\nFurthermore we might want to think about the possibility of allowing \nannotations to previous commits, in order to allow these fields to be \nset after the commit has happened, but that's a topic for a \nwhole 'nother discussion.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41028","messageId":"81b0412b0705040236w1d5f26bx8ac351ade2f4ea6a@mail.gmail.com","threadId":"7944","inReplyTo":"200705040921.33443.johan@herland.net","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T09:36:21Z","receivedAt":"2007-05-04T09:36:21Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Johan Herland wrote:\n> 1. \"Reverts\": Mark a commit as reverting another commit. This could be\n> used by git-log to cancel out pairs of commits, resulting in a cleaner\n> view of history. It can help blame/annotate. There are probably other\n> tools that can benefit from this information also.\n>\n> 2. \"Cherry-Pick\": When cherry-picking a commit onto another branch, you\n> should be able to tell git which commit you are cherry-picking\n> (git-cherry-pick would of course do this automatically). This could\n> enable git to make smarter decisions when merging the two branches: If\n> the cherry-picked commit would cause a conflict with the original\n> commit, git can either skip it (since it knows that one version of this\n> patch is already present), or it can at least present the conflict to\n> the user with some more context than what is available today. Not to\n> mention how this information could be used by blame/annotate.\n\nThese are completely useless after the first \"git gc --prune\" or \"git clone\"\nunless these tools taught to preserve the reverted or cherry-picked commits\n(and all their history). And if you are about to teach them that, please notice\nthat as for now cloning and repacking does not even look at the\nobjects contents.\nYou'll absolutely kill their performance.\n"},{"id":"41041","messageId":"20070504111057.GI4489@pasky.or.cz","threadId":"7944","inReplyTo":"200705040921.33443.johan@herland.net","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-04T11:10:57Z","receivedAt":"2007-05-04T11:10:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 04, 2007 at 09:21:29AM CEST, Johan Herland wrote:\n> On Friday 04 May 2007, Jakub Narebski wrote:\n> > Besides I think it would be better to teach blame to ignore reversion\n> > commits (for example based on first line of commit message) than to\n> > mess with the history.\n> \n> I'm starting to see a pattern where people would like to tell git about \n> more complicated relationships between commits, so that git can make \n> more intelligent decisions when doing merge, blame, pickaxe, etc.\n> \n> Adding these relationships as part of the commit message seems like a \n> really stupid idea because git suddenly has to make sense of something \n> it has never parsed before, thus making all future and former git \n> commit messages a potential target for pattern (mis)matching by git. \n> Also, we seem to forget that we already have the perfect place to put \n> such information: The header fields preceding the commit message.\n> \n> I therefore propose adding header field names to commit objects that \n> illustrate the relationships people want to tell git about.\n\n So I've looked it up, and the Linus' writeup on this is at\n\n\thttp://news.gmane.org/find-root.php?message_id=\n\n> 1. \"Reverts\": Mark a commit as reverting another commit. This could be \n> used by git-log to cancel out pairs of commits, resulting in a cleaner \n> view of history. It can help blame/annotate. There are probably other \n> tools that can benefit from this information also.\n\n Actually I think git-log is the one tool which shouldn't cancel it\nout. The number of reverts likely won't be overwhelming and reverting is\nactually pretty important event - it says \"this has been tried and we\ndecided it's not the way\", also can have social meanings etc. It is an\nimportant piece of history. And people still want to actually see the\nchange and possibly revive it. BTW, imagine their confusion if the\nhistory looks like\n\n\t1abcd5 Feature X\n\t37efab Release 2.3.1\n\t724b9c Revert feature X\n\nand git log would cancel out 1abcd5 and 724b9c. Feature X is part of\n2.3.1 but not in the log..?!\n\n The point is that the reverting/reverted commit pairs don't affect\nyour current content (except maybe in an highly abstract way), and this\nis why pickaxe and blame should skip it (by default).\n\n The question wrt. Linus' criteria is if \"it has enough of a meaning\",\nand I wonder about that too. I think it does, though.\n\n\n For the other suggested headers, it should be already mostly obvious\nfrom Linus' writeup why they shouldn't qualify, though.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41048","messageId":"200705041239.22300.andyparkins@gmail.com","threadId":"7944","inReplyTo":"81b0412b0705040236w1d5f26bx8ac351ade2f4ea6a@mail.gmail.com","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-04T11:39:18Z","receivedAt":"2007-05-04T11:39:18Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 04, Alex Riesen wrote:\n> On 5/4/07, Johan Herland wrote:\n> > 1. \"Reverts\": Mark a commit as reverting another commit. This could be\n\n> These are completely useless after the first \"git gc --prune\" or \"git\n\nAgreed for the cherry pick (and the rebase), but the original of a revert \nwon't be pruned - in fact it's almost certain that the original is a subset \nof the revert itself (otherwise the revert wouldn't have applied cleanly).\n\n * --- * --- X --- * --- !X --- * --- *\n\nSee? X won't ever be pruned without !X having been pruned first.\n\nIt doesn't seem unreasonable to record in a machine readable manner that !X \nundid X. It might be useful to someone one day.\n\nAs for custom headers - it's a great idea; here's the one that would be most \nuseful:\n\n X-Git-SVN-ID: 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b\n\nThat way git-svn wouldn't (necessarily) need to keep its .rev_db file, and it \nwouldn't need any special handling to allow the repository to be cloned.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"41049","messageId":"200705041353.17992.johan@herland.net","threadId":"7944","inReplyTo":"81b0412b0705040236w1d5f26bx8ac351ade2f4ea6a@mail.gmail.com","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-04T11:53:10Z","receivedAt":"2007-05-04T11:53:10Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 May 2007, Alex Riesen wrote:\n> On 5/4/07, Johan Herland wrote:\n> > 1. \"Reverts\": Mark a commit as reverting another commit. This could be\n> > used by git-log to cancel out pairs of commits, resulting in a cleaner\n> > view of history. It can help blame/annotate. There are probably other\n> > tools that can benefit from this information also.\n> >\n> > 2. \"Cherry-Pick\": When cherry-picking a commit onto another branch, you\n> > should be able to tell git which commit you are cherry-picking\n> > (git-cherry-pick would of course do this automatically). This could\n> > enable git to make smarter decisions when merging the two branches: If\n> > the cherry-picked commit would cause a conflict with the original\n> > commit, git can either skip it (since it knows that one version of this\n> > patch is already present), or it can at least present the conflict to\n> > the user with some more context than what is available today. Not to\n> > mention how this information could be used by blame/annotate.\n>\n> These are completely useless after the first \"git gc --prune\" or \"git\n> clone\" unless these tools taught to preserve the reverted or cherry-picked\n> commits (and all their history). And if you are about to teach them that,\n> please notice that as for now cloning and repacking does not even look at\n> the\n> objects contents.\n> You'll absolutely kill their performance.\n\nOf course I don't want \"git gc --prune\" or \"git clone\" to follow these links, \nor know anything about them at all.\n\nAs for \"Reverts\", the commit pointed to should already be in your history, \nsince you cannot revert something that hasn't already been applied at an \nearlier point in your history. In other words, the reverted commit will \nautomatically be included in your \"git gc --prune\" or \"git clone\" regardless \nof the \"Reverts\" fields, since \"Reverts\" can only point to an ancestor.\n\nAs for \"Cherry-Pick\", it's a fairly weak relationship that shouldn't affect \nanything except to give a hint to merge, blame, and similar tools. \nIf \"Cherry-Pick\" identifies an object not in your repo (because of \"git \ngc --prune\" or \"git clone\"), that is obviously equivalent to not having \na \"Cherry-Pick\" field in the first place. \"Cherry-Pick\" is only useful when \nyou have access to the original commit (pointed to by \"Cherry-Pick\"), but in \nthat case I think it could be _really_ useful.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41050","messageId":"20070504120651.GA6053@bowser.ruder","threadId":"7944","inReplyTo":"200705041239.22300.andyparkins@gmail.com","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Andrew Ruder","fromEmail":"andy@aeruder.net","sentAt":"2007-05-04T12:06:51Z","receivedAt":"2007-05-04T12:06:51Z","isPatch":false,"sender":{"key":"andy@aeruder.net","avatar":"https://gravatar.com/avatar/cd5239f6d3c9acac61e817de7f7d497e518415e23720f170a10e0663a7981963?d=mp&s=160"},"body":"On Fri, May 04, 2007 at 12:39:18PM +0100, Andy Parkins wrote:\n> That way git-svn wouldn't (necessarily) need to keep its .rev_db file, and it \n> wouldn't need any special handling to allow the repository to be cloned.\n\nWhich, BTW, would be a great thing as on subversion repositories with\nlots of revisions and lots of branches/tags, the disk space for all those\n.rev_db files gets pretty bad. i.e. du -sh .git/objects == 14M, du -sh\n.git == 120M.\n\n- Andy\n\n-- \nAndrew Ruder \nhttp://www.aeruder.net\n"},{"id":"41051","messageId":"200705041422.13975.johan@herland.net","threadId":"7944","inReplyTo":"20070504111057.GI4489@pasky.or.cz","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-04T12:22:11Z","receivedAt":"2007-05-04T12:22:11Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 May 2007, Petr Baudis wrote:\n> On Fri, May 04, 2007 at 09:21:29AM CEST, Johan Herland wrote:\n> > On Friday 04 May 2007, Jakub Narebski wrote:\n> > > Besides I think it would be better to teach blame to ignore reversion\n> > > commits (for example based on first line of commit message) than to\n> > > mess with the history.\n> >\n> > I'm starting to see a pattern where people would like to tell git about\n> > more complicated relationships between commits, so that git can make\n> > more intelligent decisions when doing merge, blame, pickaxe, etc.\n> >\n> > Adding these relationships as part of the commit message seems like a\n> > really stupid idea because git suddenly has to make sense of something\n> > it has never parsed before, thus making all future and former git\n> > commit messages a potential target for pattern (mis)matching by git.\n> > Also, we seem to forget that we already have the perfect place to put\n> > such information: The header fields preceding the commit message.\n> >\n> > I therefore propose adding header field names to commit objects that\n> > illustrate the relationships people want to tell git about.\n>\n> So I've looked it up, and the Linus' writeup on this is at\n>\n> \thttp://news.gmane.org/find-root.php?message_id=0.3701@g5.osdl.org>\n\nThanks a lot for the link. I hadn't seen that writeup.\n\nFor the record: I'm only interested in adding \"machine-readable\" headers in \ncases where _both_ of the following holds:\n1. The header has a _clear_ and _unambiguous_ _meaning_.\n2. git can use the header in a well-defined manner to make informed and better \ndecisions on how to behave.\n\nIn Linus' writeup, he's correct in that \"prior\" is too loosely defined. \nHowever, if we can meet Linus' requirements for clearness and semantics, I \nactually think the core idea is very good.\n\n> > 1. \"Reverts\": Mark a commit as reverting another commit. This could be\n> > used by git-log to cancel out pairs of commits, resulting in a cleaner\n> > view of history. It can help blame/annotate. There are probably other\n> > tools that can benefit from this information also.\n>\n> Actually I think git-log is the one tool which shouldn't cancel it\n> out. The number of reverts likely won't be overwhelming and reverting is\n> actually pretty important event - it says \"this has been tried and we\n> decided it's not the way\", also can have social meanings etc. It is an\n> important piece of history. And people still want to actually see the\n> change and possibly revive it. BTW, imagine their confusion if the\n> history looks like\n>\n> \t1abcd5 Feature X\n> \t37efab Release 2.3.1\n> \t724b9c Revert feature X\n>\n> and git log would cancel out 1abcd5 and 724b9c. Feature X is part of\n> 2.3.1 but not in the log..?!\n>\n> The point is that the reverting/reverted commit pairs don't affect\n> your current content (except maybe in an highly abstract way), and this\n> is why pickaxe and blame should skip it (by default).\n\nOf course git-log shouldn't skip reverted commit pairs _by_default_. But if \nsomeone is interested in a cleaner view of history (e.g. when making a \nchangelog or whatnot), a command-line option for turning on this behaviour \nmight be useful. Or maybe we don't want git-log to be affected by \"Reverts\" \nat all. But if pickaxe and blame can make real use of this header, that's \nsufficient reason to add it, I think.\n\n> The question wrt. Linus' criteria is if \"it has enough of a meaning\",\n> and I wonder about that too. I think it does, though.\n\nAs stated above, I don't want header fields unless they have clearly defined \nmeaning and semantics. I doubt that all of my examples will fulfill these \ncriteria, but some of them should, and that may be useful enough.\n\n> For the other suggested headers, it should be already mostly obvious\n> from Linus' writeup why they shouldn't qualify, though.\n\nI agree with Linus in that if we cannot define clear meaning and accompanying \nsemantics, then adding a header is useless. I do, however, think that there \nare cases where we _can_ define the meaning and semantics, and in those \ncases, I do believe header fields to be a good idea.\n\nAs for \"Cherry-Pick\", it is of course not useful when the commit pointed to is \nnot in the repo, but in the cases where it _is_, it might be very useful. \nIt's a tradeoff, and we might end up deciding that \"Cherry-Pick\" is not worth \nit, but we should at least consider the possibility.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41052","messageId":"200705041430.09405.johan@herland.net","threadId":"7944","inReplyTo":"200705041239.22300.andyparkins@gmail.com","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-04T12:30:09Z","receivedAt":"2007-05-04T12:30:09Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 May 2007, Andy Parkins wrote:\n> As for custom headers - it's a great idea; here's the one that would be\n> most useful:\n>\n> X-Git-SVN-ID: 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b\n>\n> That way git-svn wouldn't (necessarily) need to keep its .rev_db file, and\n> it wouldn't need any special handling to allow the repository to be cloned.\n\nThat's _exactly_ the kind of use of this I'd like to see. Great example. :)\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41056","messageId":"loom.20070504T143538-533@post.gmane.org","threadId":"7944","inReplyTo":"20070503200013.GG4489@pasky.or.cz","subject":"Re: FFmpeg considering GIT","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-04T13:46:28Z","receivedAt":"2007-05-04T13:46:28Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Petr Baudis suse.cz> writes:\n[...]\n> > \tlet me explain a little bit why this is critically needed\n> > \tthink of someone misstakely commiting the whole ffmpeg\n> > \treindented or mistakely commiting a old ffmpeg version over the\n> > \tnew or another total messup, these things do happen, and\n> > \tespecially if they cannot be corrected and at the time where\n> > \tnone of the developers is around\n> > \n[...]\n> Still, if this kind of bogus change checkins happens at any frequent\n> rate in the ffmpeg project, there is a serious problem somewhere. \n\nwell, my example above was exagerated, noone ever reindented the whole\nffmpeg or checked in a old version over HEAD. what did and does occasionally\nhappen is that people check in several things at once (like a 100k reindenton\nmixed with various functional changes)\nfor these we currently copy the last good version of the affected files\nover the current one with svn cp and then apply the changes in nicely\nsplit manner. (possibly without the reindention if its uneeded ...)\nAnother thing that happens occasionally is that complete nonsense is checked\nin like checking in the wrong file or some \"private\" debuging code\n\nwe never use the svn cp method to revert normal buggy code ...\n\n\n\n> But I think the git way of alleviating this problem would be to have a\n> way to hint the pickaxe and blame tools to ignore changes in given\n> commits. So, you don't _cover up_ the messy things that happened during\n> the history, but avoid in getting in the way in your view. You can still\n> look it up (with git log or something) in case you'd need to (perhaps\n> the revert patch was a bit complicated because of conflicting with some\n> other changes, and a subtle bug was introduced; this would be thousand\n> times harder to track down if you would've rewritten the history).\n> \n> Would crafting up a patch to implement something like this help ffmpeg\n> people in their decision?\n\nwell if git blame and others could somehow be told to automatically ignore\nnonsense changes and matching nonsense reverts that would be great\nmaybe by searching for some keyword in the revert message?\n\nignoring all or no reverts though would again be suboptimal as that would\nalso ignore some reverts due to normal buggy changes\n\nactually i think ive found an almost working solution for replacing svn cp\n(though i dont know if its safe on a public repo? or if theres some other\nissue with it iam missing)\n\nascii > testfile\ngit add testfile ; git commit\nCreated initial commit c14755cd59af4b0e6c53fb3d4bf8fa7d5aad3f3d\n 1 files changed, 23 insertions(+), 0 deletions(-)\n create mode 100644 testfile\n\nvim testfile \ngit add testfile ; git commit\nCreated commit 0fd74c0955ae4281ac17520eabefea639f635354\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\nvim testfile \ngit add testfile ; git commit\nCreated commit d1dce0e5a20603faa0e64b722d93e847f5b80845\n 1 files changed, 23 insertions(+), 23 deletions(-)\n\ngit checkout 0fd74c0955ae4281ac17520eabefea639f635354\nNote: moving to \"0fd74c0955ae4281ac17520eabefea639f635354\" which \nisn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b \nHEAD is now at 0fd74c0... good change\n\ncp testfile testbak\ngit add testbak ; git commit\nCreated commit 0e55c6f422005e64fd3b73595f0fe409148d725f\n 1 files changed, 23 insertions(+), 0 deletions(-)\n create mode 100644 testbak\n\ngit checkout d1dce0e5a20603faa0e64b722d93e847f5b80845\nHEAD is now at d1dce0e... bad change\n$git rm testfile \nrm 'testfile'\n\ngit merge 0e55c6f422005e64fd3b73595f0fe409148d725f\n 100% (1/1) done\nMerge made by recursive.\n testbak | 23 +++++++++++++++++++++++\n 1 files changed, 23 insertions(+), 0 deletions(-)\n create mode 100644 testbak\n\ngit mv testbak testfile \nfatal: destination exists, source=testbak, destination=testfile\ngit rm testfile \nrm 'testfile'\ngit mv testbak testfile \n\ngit commit\nCreated commit ca5bcbcadb9799b0a6eaa792fae322d511ecd55f\n 2 files changed, 23 insertions(+), 46 deletions(-)\n delete mode 100644 testbak\n\ngit blame -C1 -C1 -M testfile\n(this just shows ca5bcbca)\n\nvim testfile (changing a single line)\ngit add testfile ; git commit\nCreated commit 7a0a828629935ce139177fc4623a0eb9916b78fd\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ngit blame -C1 -C1 -M testfile | cut -d ' ' -f 1\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n0fd74c09\n0fd74c09\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n^c14755c\n7a0a8286\nca5bcbca\nca5bcbca\nca5bcbca\nca5bcbca\nca5bcbca\nca5bcbca\n\nthis is correct except the last 6 lines\n\n[...]\n\nMichael\n"},{"id":"41060","messageId":"200705041653.49486.andyparkins@gmail.com","threadId":"7944","inReplyTo":"loom.20070504T143538-533@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-04T15:53:47Z","receivedAt":"2007-05-04T15:53:47Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 04, Michael Niedermayer wrote:\n\n> well, my example above was exagerated, noone ever reindented the whole\n> ffmpeg or checked in a old version over HEAD. what did and does\n> occasionally happen is that people check in several things at once (like a\n> 100k reindenton mixed with various functional changes)\n> for these we currently copy the last good version of the affected files\n> over the current one with svn cp and then apply the changes in nicely\n> split manner. (possibly without the reindention if its uneeded ...)\n\nI might be misunderstanding, but doesn't that leave the \"bad\" commit in the \nhistory?\n\n * -- * -- G -- B -- !B -- 1 -- 2 -- 3\n\nB is the bad commit; !B would be the result of the svn cp from the previous \nknown-good revision, \"G\"; then 1, 2, and 3 would be the correctly split \nversion of \"B\".\n\nHave I correctly understood? If so - git would have no trouble at all \nemulating that. !B would actually be easier to create because you could use \ngit-revert to automatically create the inverse of B. If you wanted to only \nrevert a single file, well you could use\n\n git-checkout G-REVISION -- file\n\nTo pull only that file out of G, and then commit that back, before starting \nthe tidy up.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"41061","messageId":"463B5ABB.5D7A3EC4@eudaptics.com","threadId":"7944","inReplyTo":"200705041653.49486.andyparkins@gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-04T16:09:31Z","receivedAt":"2007-05-04T16:09:31Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Andy Parkins wrote:\n> On Friday 2007 May 04, Michael Niedermayer wrote:\n> > for these we currently copy the last good version of the affected files\n> > over the current one with svn cp and then apply the changes in nicely\n> > split manner. (possibly without the reindention if its uneeded ...)\n> \n> I might be misunderstanding, but doesn't that leave the \"bad\" commit in the\n> history?\n\nIn the history? Yes.\nIn the blame? No.\n\n> \n> * -- * -- G -- B -- !B -- 1 -- 2 -- 3\n> \n> B is the bad commit; !B would be the result of the svn cp from the previous\n> known-good revision, \"G\"; then 1, 2, and 3 would be the correctly split\n> version of \"B\".\n\nWith svn cp you actually create this \"blame\" history:\n\n* -- * -- G -- B\n \\\n ----- G* -- 1 -- 2 -- 3\n\nwhere G* is a new revision, but since it is otherwise identical to G, it\ndoes not introduce new blame-able lines.\n\n-- Hannes\n"},{"id":"41064","messageId":"alpine.LFD.0.99.0705041232060.24220@xanadu.home","threadId":"7944","inReplyTo":"loom.20070504T143538-533@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-04T16:40:23Z","receivedAt":"2007-05-04T16:40:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 4 May 2007, Michael Niedermayer wrote:\n\n> well, my example above was exagerated, noone ever reindented the whole\n> ffmpeg or checked in a old version over HEAD. what did and does occasionally\n> happen is that people check in several things at once (like a 100k reindenton\n> mixed with various functional changes)\n> for these we currently copy the last good version of the affected files\n> over the current one with svn cp and then apply the changes in nicely\n> split manner. (possibly without the reindention if its uneeded ...)\n> Another thing that happens occasionally is that complete nonsense is checked\n> in like checking in the wrong file or some \"private\" debuging code\n> \n> we never use the svn cp method to revert normal buggy code ...\n\nA big difference between git and svn is that git allows you to commit \nyour changes individually to your local repository before pushing them \nout to the world. With svn you make your changes visible to the world \nas soon as you commit something, including the commit screwups.\n\nWith Git you always have the opportunity to look at your commits and \ntest them all together before pushing which should make commit mistakes \nobvious before they leave your machine. If a mistake happened in one of \nthose commits you can ammend them, rebase them, etc. and only push when \nthey're satisfactory, something that svn doesn't allow.\n\nSo I think that something that you got used to with svn simply has no \nserious need for with git.\n\n\nNicolas\n"},{"id":"41069","messageId":"87vef8ijth.fsf@mid.deneb.enyo.de","threadId":"7944","inReplyTo":"463B5ABB.5D7A3EC4@eudaptics.com","subject":"Re: FFmpeg considering GIT","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-05-04T17:23:54Z","receivedAt":"2007-05-04T17:23:54Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Johannes Sixt:\n\n> Andy Parkins wrote:\n>> On Friday 2007 May 04, Michael Niedermayer wrote:\n>> > for these we currently copy the last good version of the affected files\n>> > over the current one with svn cp and then apply the changes in nicely\n>> > split manner. (possibly without the reindention if its uneeded ...)\n>> \n>> I might be misunderstanding, but doesn't that leave the \"bad\" commit in the\n>> history?\n>\n> In the history? Yes.\n> In the blame? No.\n>\n>> \n>> * -- * -- G -- B -- !B -- 1 -- 2 -- 3\n>> \n>> B is the bad commit; !B would be the result of the svn cp from the previous\n>> known-good revision, \"G\"; then 1, 2, and 3 would be the correctly split\n>> version of \"B\".\n>\n> With svn cp you actually create this \"blame\" history:\n>\n> * -- * -- G -- B\n> \\\n> ----- G* -- 1 -- 2 -- 3\n>\n> where G* is a new revision, but since it is otherwise identical to G, it\n> does not introduce new blame-able lines.\n\n\nWith GIT, you could create:\n\n\n* -- * -- G --- B\n \\ \\\n ---- 1 -- 2 -- 3\n\nOr perhaps :\n\n* -- * -- G --- B\n \\ \\\n ---- G* -- 1 -- 2 -- 3\n\nHow do the history viewers handle this situation?\n"},{"id":"41071","messageId":"87y7k4lahq.wl%cworth@cworth.org","threadId":"7944","inReplyTo":"loom.20070504T143538-533@post.gmane.org","subject":"Re: FFmpeg considering GIT","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-04T18:17:05Z","receivedAt":"2007-05-04T18:17:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:\n> well, my example above was exagerated, noone ever reindented the whole\n> ffmpeg or checked in a old version over HEAD. what did and does occasionally\n> happen is that people check in several things at once (like a 100k reindenton\n> mixed with various functional changes)\n\nThat sounds like an opportunity to educate your contributors a bit on\nwhat good commits should look like. So I think this is more a social\nissue than a technical issue, (but git has some technical means that\nmake it much easier to address the social issues).\n\nYour description above makes an assumption that there is a single\ncentral repository that multiple people push changes into, (which is\nreally the only way to organize a project with svn or cvs). And with\nthose systems all you get is a bit than you can flip on for whether\nyou trust someone to push changes into the repository or not. But git\nis much more flexible than that.\n\nThe opposite extreme is to organize the project in a way similar to\nthe linux kernel---all contributors maintain their own repositories\nand things get merged only when a maintainer reviews and pulls. With\nthis approach, garbage never lands in your own repository by\ndefinition, (since you don't pull if it looks like garbage to you). So\nthat solves the problem, but this organization might seem too radical\na shift for your project.\n\nFortunately, git is flexible enough to do things in between as\nwell. For example, you can have a central repository where multiple\npeople push changes, and also have personal repositories. Git reduces\nthe cost of creating a new personal repository to basically zero, so\nyou can use these quite freely. They make a great place for new\ncontributors to publish changes where the more experienced maintainers\ncan review and educate the new contributors on mistakes like you\ndescribe above.\n\nSo with this, you can let people play in their own repositories while\nthey're still learning the cultural aspects of what code should look\nlike. I've found that new contributors really like the freedom this\ngives them, (there's no fear that they are going to break anything\nthis way, since they are relying on others to review and pull at\nfirst). So the trust relationship can grow as you work together,\n(which is how it should be).\n\nAnd that whole relationship-building happens while you're both\nbenefiting from the support of the tool, (not like cvs or svn where\nthe new contributor is cut off from almost all help from the tool\nuntil you flip the \"absolute trust\" bit).\n\n> well if git blame and others could somehow be told to automatically ignore\n> nonsense changes and matching nonsense reverts that would be great\n> maybe by searching for some keyword in the revert message?\n\nThat sounds like a bad technical workaround for a problem that really\nshouldn't exist. You should look for ways to create the history you'd\nreally like to have rather than trying to find a way to get the tool\nto ignore the history that's actually there.\n\nSure, mistakes will happen. Just learn to live with that.\n\nOh, and I also think the emphasis on \"blame\" is due to a lack of other\nmore powerful history exploration features in other systems. For\nexample, the fact that \"git log\" can filter based on subsets of the\ndirectory tree:\n\n\tgit log -p -- some/directory\n\nor by content of the patches themselves:\n\n\tgit log -p -S'snippet of interest'\n\t[*]\n\nis often just plain more powerful than blame is, and it makes it quite\ntrivial to skip past any noise, (since you get the complete history of\nwhat you care about, not just information about the last time a line\nin a file got touched).\n\nFor example, I often use git-log to find out what happened to code\nthat used to be in the file, but doesn't appear there anymore. That's\nsimple to do with git log, (sometimes even just plain \"git log -p\" and\nsearching with the pager), but it's something that something like cvs\nor svn blame just fundametally cannot even help with.\n\n-Carl\n\n[*] I just noticed that -S isn't mentioned in the documentation for\ngit-log at all, (though, oddly enough, a 'git log -S' example is\nprovided in the git-blame documentation).\n"},{"id":"41073","messageId":"200705042025.22635.johan@herland.net","threadId":"7944","inReplyTo":"87y7k4lahq.wl%cworth@cworth.org","subject":"Re: FFmpeg considering GIT","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-04T18:25:17Z","receivedAt":"2007-05-04T18:25:17Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 04 May 2007, Carl Worth wrote:\n> [*] I just noticed that -S isn't mentioned in the documentation for\n> git-log at all, (though, oddly enough, a 'git log -S' example is\n> provided in the git-blame documentation).\n\nIt's also used in an example in the User Manual (Chapter 1. Git Quick \nStart -- Exploring history). I was also surprised that it wasn't \nmentioned in the git-log manual page.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41088","messageId":"20070504202448.GD14859@MichaelsNB","threadId":"7944","inReplyTo":"87y7k4lahq.wl%cworth@cworth.org","subject":"Re: FFmpeg considering GIT","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-04T20:24:49Z","receivedAt":"2007-05-04T20:24:49Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nOn Fri, May 04, 2007 at 11:17:05AM -0700, Carl Worth wrote:\n> On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:\n> > well, my example above was exagerated, noone ever reindented the whole\n> > ffmpeg or checked in a old version over HEAD. what did and does occasionally\n> > happen is that people check in several things at once (like a 100k reindenton\n> > mixed with various functional changes)\n> \n> That sounds like an opportunity to educate your contributors a bit on\n> what good commits should look like. \n\nwe have a nice svn policy which explains that, also people wont receive\nwrite access without having submitted a few clean patches first\nso i dont know if more education would really help, the problems are IMHO\nrather caused by a mix of lazyness, arrogance and plain oversight\nbut please dont missunderstand, these problems are not that common, its\nrather once every few month\n\n\n> So I think this is more a social\n> issue than a technical issue, \n\nyes i think so too, the added push after commit wont stop a bad commit\nas the developer already saw the change when running svn diff ...\n\n\n> (but git has some technical means that\n> make it much easier to address the social issues).\n> \n> Your description above makes an assumption that there is a single\n> central repository that multiple people push changes into, (which is\n> really the only way to organize a project with svn or cvs). And with\n> those systems all you get is a bit than you can flip on for whether\n> you trust someone to push changes into the repository or not. But git\n> is much more flexible than that.\n> \n> The opposite extreme is to organize the project in a way similar to\n> the linux kernel---all contributors maintain their own repositories\n> and things get merged only when a maintainer reviews and pulls. With\n> this approach, garbage never lands in your own repository by\n> definition, (since you don't pull if it looks like garbage to you). So\n> that solves the problem, but this organization might seem too radical\n> a shift for your project.\n\nyes, id like to switch ffmpeg to git or mercurial as that seems like a\ngood idea and many of our developers seem to want it, the question\nabout the organization is a different thing, not a single ffmpeg \ndeveloper suggested to change the current \"every developer has write access\"\nsystem, actually its even more than just that, almost every mplayer\ndeveloper has technically write access to ffmpeg and almost every ffmpeg\ndeveloper has technically write access to mplayer and this has never\ncaused a problem ...\n\nalso its kinda nice to review a patch and reply with \"looks ok\" and\nsomeone else applies the patch locally, tests it extensively and\ncommits it, it reduces the work for reviewers ...\n\n\n[...]\n\n> \n> > well if git blame and others could somehow be told to automatically ignore\n> > nonsense changes and matching nonsense reverts that would be great\n> > maybe by searching for some keyword in the revert message?\n> \n> That sounds like a bad technical workaround for a problem that really\n> shouldn't exist. You should look for ways to create the history you'd\n> really like to have rather than trying to find a way to get the tool\n> to ignore the history that's actually there.\n> \n> Sure, mistakes will happen. Just learn to live with that.\n\nbtw, that leads me to another minor issue, i think commit log\nmessages cannot be changed in git after they are public, while we\ncommonly did change them to improve them, the issue simply is that some\ndevelopers are not good at writing nice commit log messages, sometimes\ndue them being plain bad in english or bad at writing descriptive\nlog messages ...\n\nalso our docs team loves to correct spelling errors in the commit messages\nnot that i consider that of any importance :)\n\n\n> \n> Oh, and I also think the emphasis on \"blame\" is due to a lack of other\n> more powerful history exploration features in other systems. For\n\nyes\n\n[...]\n\n-- \nMichael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nIn a rich man's house there is no place to spit but his face.\n-- Diogenes of Sinope\n"},{"id":"41098","messageId":"20070504221152.GF4033@steel.home","threadId":"7944","inReplyTo":"200705041353.17992.johan@herland.net","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T22:11:52Z","receivedAt":"2007-05-04T22:11:52Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johan Herland, Fri, May 04, 2007 13:53:10 +0200:\n> As for \"Reverts\", the commit pointed to should already be in your history, \n> since you cannot revert something that hasn't already been applied at an \n> earlier point in your history. In other words, the reverted commit will \n> automatically be included in your \"git gc --prune\" or \"git clone\" regardless \n> of the \"Reverts\" fields, since \"Reverts\" can only point to an ancestor.\n\nSo it becomes useless after rebase\n\n> As for \"Cherry-Pick\", it's a fairly weak relationship that shouldn't affect \n> anything except to give a hint to merge, blame, and similar tools. \n\nIn which case, just put it in the message part of commit (in fact, it\nwas there for some time. And was mostly useless, and got dropped).\n\nAnd how exactly do you think the tools _can_ use this hint?\nEspecially merge, which should be absolutely certain about what inputs\nand hints gets.\nAnd what use is it for blame? How do you prioritze the hint? Is it\nmore important than the history (which describes each and every line),\nor less? If the hint is more important, than how (and how often) do\nyou tell the user that the hint was not found (because the commit is\nlong pruned) and the tool switched back to looking into history.\n\nIt's useless.\n"},{"id":"41117","messageId":"alpine.LFD.0.98.0705042106370.3819@woody.linux-foundation.org","threadId":"7944","inReplyTo":"20070504202448.GD14859@MichaelsNB","subject":"Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-05T04:15:54Z","receivedAt":"2007-05-05T04:15:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 4 May 2007, Michael Niedermayer wrote:\n> \n> we have a nice svn policy which explains that, also people wont receive\n> write access without having submitted a few clean patches first\n> so i dont know if more education would really help, the problems are IMHO\n> rather caused by a mix of lazyness, arrogance and plain oversight\n> but please dont missunderstand, these problems are not that common, its\n> rather once every few month\n\n[ I was away for a few days, so others probably answered already ... ]\n\nWith git, the right way to do thigns is to not ever give \"write access\" to \nthe \"standard\" tree to developers, but to make each developer have their \nown tree, and then one or more developers are the ones that merge other \npeoples work. \n\nSince I'm the one who does the merging for the kernel, I've made damn sure \nthat merging other peoples work is as easy as humanly possible, so that I \ncan just sit there, sipping my foofy tropical drink, drunk as a skunk and \nenjoying every moment of seeing my peons work their little fingers to the \nbone, when I do a \"git pull ...\" and in two seconds I've downloaded their \nwork and merged it, and I can take another sip of the Piña Colada. \n\nBurp.\n\nAnd git also makes it really easy to see when somebody does something \nstupid. The one thing it always shows to the person doing the merging is \nthe diffstat from the result, so if somebody re-indented the source base, \nthe merger goes \"Whaa\", and assuming he's not too drunk to type, he should \njust send a sternly worded message to the developer who did the bad deed, \nand tell them that their work was unacceptable, and won't be pulled.\n\nA simple \"git reset --hard ORIG_HEAD\" will undo the merge, so the \nperson(s) who actually does the integration again doesn't actually have to \nwork all that hard.\n\nIn other words, the proper sequence really should be to *not* let the \nhorribly buggy commits into the standard version in the first place! Sure, \nindividual developers will make mistakes, but the fact that they screwed \nup should in _no_ way mean that they can screw up the main repository. The \nwhole point in being distributed is that developers can screw up in their \nown _private_ repositories and still have all the power of a proper SCM \ntool, but without actually getting to screw up the main repo.\n\n(And yes, then very occasionally both the developer *and* the maintainer \nscrews up, and something bad gets through, and yeah, then you need to \nrevert, but the point I'm arguing is that with a fairly good flow of \ndevelopment, you don't have to worry about the more clueless people \nscrewing up - they can still do development, and you can still pull from \nthem, but *if* they screw up, you can tell them to clean up their mess \n*before* you actually put it into any standard tree, and the mess can be \nentirely their _local_ mistake and never visible anywhere else).\n\n\t\t\tLinus"},{"id":"41149","messageId":"200705051449.45447.johan@herland.net","threadId":"7944","inReplyTo":"20070504221152.GF4033@steel.home","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-05T12:49:42Z","receivedAt":"2007-05-05T12:49:42Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 05 May 2007, Alex Riesen wrote:\n> Johan Herland, Fri, May 04, 2007 13:53:10 +0200:\n> > As for \"Reverts\", the commit pointed to should already be in your\n> > history, since you cannot revert something that hasn't already been\n> > applied at an earlier point in your history. In other words, the\n> > reverted commit will automatically be included in your \"git gc\n> > --prune\" or \"git clone\" regardless of the \"Reverts\" fields, since\n> > \"Reverts\" can only point to an ancestor.\n>\n> So it becomes useless after rebase\n\nOnly if rebase also rebases the commit pointed to by \"Reverts\" (the \nreverted commit). And even in that case, it should be possible for \nrebase to detect the \"Reverts\" relationship and rewrite it properly, \nor - if people want to - skip both the reverted and the reverting \ncommit in the rebase process.\n\n> > As for \"Cherry-Pick\", it's a fairly weak relationship that\n> > shouldn't affect anything except to give a hint to merge, blame,\n> > and similar tools.\n>\n> In which case, just put it in the message part of commit (in fact, it\n> was there for some time. And was mostly useless, and got dropped).\n\nOk. If merging branches which have had cherry-picks between them is such \na rare occurrence that there is no point in adding hints for merge (to \ndo better conflict resolution), blame (to see who _really_ wrote the \npiece of code that was cherry-picked by someone else), etc. then there \nis indeed no justification for the \"Cherry-Pick\" header field.\n\n> And how exactly do you think the tools _can_ use this hint?\n> Especially merge, which should be absolutely certain about what\n> inputs and hints gets.\n\nWhen merging two branches where one branch has a commit that is later \nreverted, and the other branch has cherry-picked the first/reverted \ncommit, but not the second/reverting: With these hints, git can now ask \nthe user a more intelligent question like \"The following commit was \nreverted in one of the branches. Do you want to keep it or revert it?\". \nThe current alternative seems to be to auto-choose one or the other (in \nmy testing, the reverting commit was dropped in the merge). Will git \nalways make the correct decision? If git is always correct, then what I \nsuggest is obviously useless.\n\n> And what use is it for blame? How do you prioritze the hint? Is it\n> more important than the history (which describes each and every\n> line), or less? If the hint is more important, than how (and how\n> often) do you tell the user that the hint was not found (because the\n> commit is long pruned) and the tool switched back to looking into\n> history.\n\nConsider the following scenario:\n\n====\n$ mkdir test\n$ cd test\n$ git init\nInitialized empty Git repository in .git/\n$ git config user.name \"User A\"\n$ cat >f <<\\EOF\nfoo\nbar\nbaz\nEOF\n$ git add f && git commit -m \"User A: foo, bar, baz\"\nCreated initial commit bb0203aabb4936d95dca30f946cb1d849df59f24\n 1 files changed, 3 insertions(+), 0 deletions(-)\n create mode 100644 f\n$ git config user.name \"User B\"\n$ cat >f <<\\EOF\nfoo\nbarf\nbaz\nEOF\n$ git commit -a -m \"User B: bar -> barf\"\nCreated commit 5ced0ccaba0bf4a982dc2cdd792a1a0e7b1883eb\n 1 files changed, 1 insertions(+), 1 deletions(-)\n$ git config user.name \"User C\"\n$ git revert HEAD\nCreated commit 38da1083ae4677000f8bb70729f474f358c71a3e\n 1 files changed, 1 insertions(+), 1 deletions(-)\n====\n\nAt this point, what output do we _really_ want from \"git blame f\"?\n\nCurrently we get:\n====\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo\n38da1083 (User C 2007-05-05 12:28:00 +0200 2) bar\n^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz\n====\n\nCan you categorically say that there is no use for the following output? \n(even if you need to pass an option to \"git blame\" to get it):\n====\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar\n^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz\n====\n\n> It's useless.\n\nMaybe. At least some of the fields I proposed are probably useless. But \nI don't think we should throw away the core idea unless we can show \nthat _all_ fields are useless.\n\n\nHave fun!\n\n...Johan\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41130","messageId":"20070505133543.GC3379@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"87y7k4lahq.wl%cworth@cworth.org","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-05T13:35:43Z","receivedAt":"2007-05-05T13:35:43Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-04 11:17:05 -0700, Carl Worth wrote:\n\n> or by content of the patches themselves:\n>\n> git log -p -S'snippet of interest'\n\nSomewhat unrelated: how can I make gitk display these (and only these)\ncommits? git-log is not bad, but in 95% of cases I find gitk easier to\nuse.\n\nI know that I can ask it to highlight commits that insert or remove\n\"snippet of interest\", but frequently the highlighted commits are ten\nout of ten thousand, and not that easy to find even when boldfaced.\nWhat I want is to make it display only those commits.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41136","messageId":"200705051813.43897.johan@herland.net","threadId":"7944","inReplyTo":"20070504221152.GF4033@steel.home","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-05T16:13:41Z","receivedAt":"2007-05-05T16:13:41Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 05 May 2007, Alex Riesen wrote:\n> Johan Herland, Fri, May 04, 2007 13:53:10 +0200:\n> > As for \"Reverts\", the commit pointed to should already be in your\n> > history, since you cannot revert something that hasn't already been\n> > applied at an earlier point in your history. In other words, the\n> > reverted commit will automatically be included in your \"git gc\n> > --prune\" or \"git clone\" regardless of the \"Reverts\" fields, since\n> > \"Reverts\" can only point to an ancestor.\n>\n> So it becomes useless after rebase\n\nOnly if rebase also rebases the commit pointed to by \"Reverts\" (the \nreverted commit). And even in that case, it should be possible for \nrebase to detect the \"Reverts\" relationship and rewrite it properly, \nor - if people want to - skip both the reverted and the reverting \ncommit in the rebase process.\n\n> > As for \"Cherry-Pick\", it's a fairly weak relationship that\n> > shouldn't affect anything except to give a hint to merge, blame,\n> > and similar tools.\n>\n> In which case, just put it in the message part of commit (in fact, it\n> was there for some time. And was mostly useless, and got dropped).\n\nOk. If merging branches which have had cherry-picks between them is such \na rare occurrence that there is no point in adding hints for merge (to \ndo better conflict resolution), blame (to see who _really_ wrote the \npiece of code that was cherry-picked by someone else), etc. then there \nis indeed no justification for the \"Cherry-Pick\" header field.\n\n> And how exactly do you think the tools _can_ use this hint?\n> Especially merge, which should be absolutely certain about what\n> inputs and hints gets.\n\nWhen merging two branches where one branch has a commit that is later \nreverted, and the other branch has cherry-picked the first/reverted \ncommit, but not the second/reverting: With these hints, git can now ask \nthe user a more intelligent question like \"The following commit was \nreverted in one of the branches. Do you want to keep it or revert it?\". \nThe current alternative seems to be to auto-choose one or the other (in \nmy testing, the reverting commit was dropped in the merge). Will git \nalways make the correct decision? If git is always correct, then what I \nsuggest is obviously useless.\n\n> And what use is it for blame? How do you prioritze the hint? Is it\n> more important than the history (which describes each and every\n> line), or less? If the hint is more important, than how (and how\n> often) do you tell the user that the hint was not found (because the\n> commit is long pruned) and the tool switched back to looking into\n> history.\n\nConsider the following scenario:\n\n----\n$ mkdir test\n$ cd test\n$ git init\nInitialized empty Git repository in .git/\n$ git config user.name \"User A\"\n$ cat >f <<\\EOF\nfoo\nbar\nbaz\nEOF\n$ git add f && git commit -m \"User A: foo, bar, baz\"\nCreated initial commit bb0203aabb4936d95dca30f946cb1d849df59f24\n 1 files changed, 3 insertions(+), 0 deletions(-)\n create mode 100644 f\n$ git config user.name \"User B\"\n$ cat >f <<\\EOF\nfoo\nbarf\nbaz\nEOF\n$ git commit -a -m \"User B: bar -> barf\"\nCreated commit 5ced0ccaba0bf4a982dc2cdd792a1a0e7b1883eb\n 1 files changed, 1 insertions(+), 1 deletions(-)\n$ git config user.name \"User C\"\n$ git revert HEAD\nCreated commit 38da1083ae4677000f8bb70729f474f358c71a3e\n 1 files changed, 1 insertions(+), 1 deletions(-)\n----\n\nAt this point, what output do we _really_ want from \"git blame f\"?\n\nCurrently we get:\n----\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo\n38da1083 (User C 2007-05-05 12:28:00 +0200 2) bar\n^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz\n----\n\nCan you categorically say that there is no use for the following output? \n(even if you need to pass an option to \"git blame\" to get it):\n----\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo\n^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar\n^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz\n----\n\n> It's useless.\n\nMaybe. At least some of the fields I proposed are probably useless. But \nI don't think we should throw away the core idea unless we can show \nthat _all_ fields are useless.\n\n\nHave fun!\n\n...Johan\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41144","messageId":"alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org","threadId":"7944","inReplyTo":"20070505133543.GC3379@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-05T17:26:12Z","receivedAt":"2007-05-05T17:26:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 May 2007, Karl Hasselstr?m wrote:\n>\n> On 2007-05-04 11:17:05 -0700, Carl Worth wrote: \n> > or by content of the patches themselves:\n> >\n> > git log -p -S'snippet of interest'\n> \n> Somewhat unrelated: how can I make gitk display these (and only these)\n> commits? git-log is not bad, but in 95% of cases I find gitk easier to\n> use.\n> \n> I know that I can ask it to highlight commits that insert or remove\n> \"snippet of interest\", but frequently the highlighted commits are ten\n> out of ten thousand, and not that easy to find even when boldfaced.\n> What I want is to make it display only those commits.\n\nThe \"-S\" thing doesn't really interact well with \"gitk\", because it \ndoesn't rewrite the parent information (it is basically just a \"hide \ncommits that don't pass this criteria\"). As such, gitk, which requires \nparent information to generate the graph, is not very amenable to using \n\"-S\" and such.\n\nThat said, you can apply this fairly trivial patch to \"gitk\" to make it \nparse the output of \"git log\" rather than \"git rev-list\", and that will \nactually get you working -S'xyz' parsing automatically. It's just that the \ncommit history window will look like crap.\n\nThis patch may be worth applying regardless, since there is really no real \nreason to use \"git rev-list\". In fact, I really like the ability to say\n\n\tgitk --stat\n\nand have the diffstat output visible in the commit window automatically ;)\n\nWe might want to teach people that \"git rev-list\" isn't really all that \nuseful any more, at least with the fancy stuff (it's still useful for just \ngenerating a list of objects, and for doing things like\n\n\tgit rev-list v2.6.21.. | wc -l\n\njust to count commits).\n\nJunio, Paul?\n\n\t\tLinus\n---\n gitk | 9 +++++----\n 1 files changed, 5 insertions(+), 4 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex b1c65d7..bec7bb9 100755\n--- a/gitk\n+++ b/gitk\n@@ -33,8 +33,8 @@ proc start_rev_list {view} {\n \tset order \"--date-order\"\n }\n if {[catch {\n-\tset fd [open [concat | git rev-list --header $order \\\n-\t\t\t --parents --boundary --default HEAD $args] r]\n+\tset fd [open [concat | git log -z --pretty=raw $order \\\n+\t\t\t --parents --boundary $args] r]\n } err]} {\n \tputs stderr \"Error executing git rev-list: $err\"\n \texit 1\n@@ -129,7 +129,8 @@ proc getcommitlines {fd view} {\n \tset ok 0\n \tset listed 1\n \tif {$j >= 0} {\n-\t set ids [string range $cmit 0 [expr {$j - 1}]]\n+\t # start with 'commit '\n+\t set ids [string range $cmit 6 [expr {$j - 1}]]\n \t if {[string range $ids 0 0] == \"-\"} {\n \t\tset listed 0\n \t\tset ids [string range $ids 1 end]\n@@ -147,7 +148,7 @@ proc getcommitlines {fd view} {\n \t if {[string length $shortcmit] > 80} {\n \t\tset shortcmit \"[string range $shortcmit 0 80]...\"\n \t }\n-\t error_popup \"Can't parse git rev-list output: {$shortcmit}\"\n+\t error_popup \"Can't parse git git log output: {$shortcmit}\"\n \t exit 1\n \t}\n \tset id [lindex $ids 0]\n"},{"id":"41154","messageId":"20070505180300.GB2898@steel.home","threadId":"7944","inReplyTo":"200705051449.45447.johan@herland.net","subject":"Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-05T18:03:00Z","receivedAt":"2007-05-05T18:03:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johan Herland, Sat, May 05, 2007 14:49:42 +0200:\n> Can you categorically say that there is no use for the following output? \n> (even if you need to pass an option to \"git blame\" to get it):\n> ====\n> ^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo\n> ^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar\n> ^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz\n> ====\n\nAssuming a repo which has 50% of all commits - reverts (just because\nsomeone could not be bothered to learn to use rebase, format-patch\nand git-am before sending things upstream) I would use the exact\nwording I used before. I'd say \"it's dangerous\" now. It hides the\nmess this repo is.\n\n> > It's useless.\n> \n> Maybe. At least some of the fields I proposed are probably useless. But \n> I don't think we should throw away the core idea unless we can show \n> that _all_ fields are useless.\n\nJust think of something you actually _can_ use. Implement it and try.\nAnd than, if you are convinced it actually is useful, try it on your\nfriends. And after them, if you're still alive, try using it with old\ngit (like 1.4 from Debian and Ubuntu).\n"},{"id":"41163","messageId":"alpine.LFD.0.98.0705051511020.17381@woody.linux-foundation.org","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-05T22:18:03Z","receivedAt":"2007-05-05T22:18:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 May 2007, Linus Torvalds wrote:\n> \n> This patch may be worth applying regardless, since there is really no real \n> reason to use \"git rev-list\". In fact, I really like the ability to say\n> \n> \tgitk --stat\n> \n> and have the diffstat output visible in the commit window automatically ;)\n\nBtw, testing this a bit more actually shows what I would consider a real \nbuglet in \"git log --boundary\": the option would be honoured only if \n\"left-right\" was enabled.\n\nThis patch fixes \"git log --boundary\" to actually show the \"-\" in front of \na commit name regardless of whether you _also_ asked for left-right.\n\n(It also shows that my \"gitk\" patch was incorrectly getting the commit \nname from character 6 onward, even though it should have been 7, but I'll \nalso try to make gitk understand the \"<\" and \">\" markers, and make it \npossible to say\n\n\tgitk --left-right a...b\n\nand have the commits colored appropriately. That would be cool, but it \nmight need more tcl/tk knowledge than I actually possess).\n\n\t\tLinus\n\n---\ndiff --git a/log-tree.c b/log-tree.c\nindex c679324..4bef909 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -244,10 +244,10 @@ void show_log(struct rev_info *opt, const char *sep)\n \t\t stdout);\n \t\tif (opt->commit_format != CMIT_FMT_ONELINE)\n \t\t\tfputs(\"commit \", stdout);\n-\t\tif (opt->left_right) {\n-\t\t\tif (commit->object.flags & BOUNDARY)\n-\t\t\t\tputchar('-');\n-\t\t\telse if (commit->object.flags & SYMMETRIC_LEFT)\n+\t\tif (commit->object.flags & BOUNDARY)\n+\t\t\tputchar('-');\n+\t\telse if (opt->left_right) {\n+\t\t\tif (commit->object.flags & SYMMETRIC_LEFT)\n \t\t\t\tputchar('<');\n \t\t\telse\n \t\t\t\tputchar('>');\n"},{"id":"41164","messageId":"alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051511020.17381@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-05T22:30:24Z","receivedAt":"2007-05-05T22:30:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 May 2007, Linus Torvalds wrote:\n> \n> (It also shows that my \"gitk\" patch was incorrectly getting the commit \n> name from character 6 onward, even though it should have been 7, but I'll \n> also try to make gitk understand the \"<\" and \">\" markers, and make it \n> possible to say\n> \n> \tgitk --left-right a...b\n> \n> and have the commits colored appropriately. That would be cool, but it \n> might need more tcl/tk knowledge than I actually possess).\n\nOk, that turned out to be the case.\n\nHere's an updated patch to gitk, which at least *parses* the \n\"--left-right\" data properly, it just doesn't use it. But with the fix to \n\"git log\" I just posted, and this, you at least have the same capabilities \ngitk used to have, and it should be fairly easy for somebody who knows \ntcltk to squirrel away the \"leftright\" data per commit and use that to \ncolor the commit lines in the top-most pane.\n\nI'm also sure the \"if first character is one of '-'/'<'/'>'\" test can be \nwritten more prettily, rather than have three if-statements on it. \n\nFinally, it realy _should_ check that the first 7 characters of the commit \nlog (the ones it ignores by just asking for substring 7..) are actually \nthe exact characters \"commit \", but I'll blame my lack of comfort with the \nlanguage again.\n\nSomebody? Please? It really should be pretty cool. Do\n\n\tgitk --left-right commit^1...commit^2\n\nfor an appropriate 'commit' that is a merge, and the two sides getting \nmerged should show up with different colors!\n\n\t\tLinus\n\n----\n gitk | 18 ++++++++++++++----\n 1 files changed, 14 insertions(+), 4 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex b1c65d7..0bf00ee 100755\n--- a/gitk\n+++ b/gitk\n@@ -33,8 +33,8 @@ proc start_rev_list {view} {\n \tset order \"--date-order\"\n }\n if {[catch {\n-\tset fd [open [concat | git rev-list --header $order \\\n-\t\t\t --parents --boundary --default HEAD $args] r]\n+\tset fd [open [concat | git log -z --pretty=raw $order \\\n+\t\t\t --parents --boundary $args] r]\n } err]} {\n \tputs stderr \"Error executing git rev-list: $err\"\n \texit 1\n@@ -127,13 +127,23 @@ proc getcommitlines {fd view} {\n \tset start [expr {$i + 1}]\n \tset j [string first \"\\n\" $cmit]\n \tset ok 0\n+\tset leftright 0\n \tset listed 1\n \tif {$j >= 0} {\n-\t set ids [string range $cmit 0 [expr {$j - 1}]]\n+\t # start with 'commit '\n+\t set ids [string range $cmit 7 [expr {$j - 1}]]\n \t if {[string range $ids 0 0] == \"-\"} {\n \t\tset listed 0\n \t\tset ids [string range $ids 1 end]\n \t }\n+\t if {[string range $ids 0 0] == \"<\"} {\n+\t\tset leftright -1\n+\t\tset ids [string range $ids 1 end]\n+\t }\n+\t if {[string range $ids 0 0] == \">\"} {\n+\t\tset leftright 1\n+\t\tset ids [string range $ids 1 end]\n+\t }\n \t set ok 1\n \t foreach id $ids {\n \t\tif {[string length $id] != 40} {\n@@ -147,7 +157,7 @@ proc getcommitlines {fd view} {\n \t if {[string length $shortcmit] > 80} {\n \t\tset shortcmit \"[string range $shortcmit 0 80]...\"\n \t }\n-\t error_popup \"Can't parse git rev-list output: {$shortcmit}\"\n+\t error_popup \"Can't parse git git log output: {$shortcmit}\"\n \t exit 1\n \t}\n \tset id [lindex $ids 0]\n"},{"id":"41187","messageId":"7vabwifl23.fsf@assigned-by-dhcp.cox.net","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-06T07:49:56Z","receivedAt":"2007-05-06T07:49:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> and have the commits colored appropriately. That would be cool, but it \n>> might need more tcl/tk knowledge than I actually possess).\n>\n> Ok, that turned out to be the case.\n>\n> Here's an updated patch to gitk, which at least *parses* the \n> \"--left-right\" data properly, it just doesn't use it.\n\nThis on top of yours makes it use it.\n\n gitk | 31 ++++++++++++++++++++++++++-----\n 1 files changed, 26 insertions(+), 5 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex 0bf00ee..a6e762d 100755\n--- a/gitk\n+++ b/gitk\n@@ -74,7 +74,7 @@ proc getcommits {} {\n proc getcommitlines {fd view} {\n global commitlisted nextupdate\n global leftover commfd\n- global displayorder commitidx commitrow commitdata\n+ global displayorder commitidx commitrow commitdata commitside\n global parentlist childlist children curview hlview\n global vparentlist vchildlist vdisporder vcmitlisted\n \n@@ -178,6 +178,7 @@ proc getcommitlines {fd view} {\n \t}\n \tset commitdata($id) [string range $cmit [expr {$j + 1}] end]\n \tset commitrow($view,$id) $commitidx($view)\n+\tset commitside($id) $leftright\n \tincr commitidx($view)\n \tif {$view == $curview} {\n \t lappend parentlist $olds\n@@ -2986,7 +2987,7 @@ proc drawlines {id} {\n \n proc drawcmittext {id row col rmx} {\n global linespc canv canv2 canv3 canvy0 fgcolor\n- global commitlisted commitinfo rowidlist\n+ global commitlisted commitinfo commitside rowidlist\n global rowtextx idpos idtags idheads idotherrefs\n global linehtag linentag linedtag\n global mainfont canvxmax boldrows boldnamerows fgcolor\n@@ -2995,9 +2996,29 @@ proc drawcmittext {id row col rmx} {\n set x [xc $row $col]\n set y [yc $row]\n set orad [expr {$linespc / 3}]\n- set t [$canv create oval [expr {$x - $orad}] [expr {$y - $orad}] \\\n-\t [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \\\n-\t -fill $ofill -outline $fgcolor -width 1 -tags circle]\n+\n+ if {[info exists commitside($id)]} {\n+\tset leftright $commitside($id)\n+ } else {\n+\tset leftright 0\n+ }\n+ if {$leftright == 0} {\n+\tset t [$canv create oval [expr {$x - $orad}] [expr {$y - $orad}] \\\n+\t\t [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \\\n+\t\t -fill $ofill -outline $fgcolor -width 1 -tags circle]\n+ } elseif {$leftright < 0} {\n+\tset t [$canv create polygon \\\n+\t\t [expr {$x - $orad}] $y \\\n+\t\t [expr {$x + $orad - 1}] [expr {$y - $orad}] \\\n+\t\t [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \\\n+\t\t -fill $ofill -outline $fgcolor -width 1 -tags circle]\n+ } else {\n+\tset t [$canv create polygon \\\n+\t\t [expr {$x + $orad - 1}] $y \\\n+\t\t [expr {$x - $orad}] [expr {$y - $orad}] \\\n+\t\t [expr {$x - $orad}] [expr {$y + $orad - 1}] \\\n+\t\t -fill $ofill -outline $fgcolor -width 1 -tags circle]\n+ }\n $canv raise $t\n $canv bind $t <1> {selcanvline {} %x %y}\n set xt [xc $row [llength [lindex $rowidlist $row]]]\n"},{"id":"41188","messageId":"20070506075621.GA16194@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T07:56:21Z","receivedAt":"2007-05-06T07:56:21Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Thanks for the patch! I haven't had time to try it out yet, but ...\n\nOn 2007-05-05 10:26:12 -0700, Linus Torvalds wrote:\n\n> -\t error_popup \"Can't parse git rev-list output: {$shortcmit}\"\n> +\t error_popup \"Can't parse git git log output: {$shortcmit}\"\n\n... this error message should probably lose one of its two \"git \"s.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41190","messageId":"e5bfff550705060115o60fdd637h6c7393d06f75c55@mail.gmail.com","threadId":"7944","inReplyTo":"20070505133543.GC3379@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-06T08:15:16Z","receivedAt":"2007-05-06T08:15:16Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/5/07, Karl Hasselström wrote:\n> On 2007-05-04 11:17:05 -0700, Carl Worth wrote:\n>\n> I know that I can ask it to highlight commits that insert or remove\n> \"snippet of interest\", but frequently the highlighted commits are ten\n> out of ten thousand, and not that easy to find even when boldfaced.\n> What I want is to make it display only those commits.\n>\n\nUse qgit ;-)\n"},{"id":"41198","messageId":"20070506101953.GA17498@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T10:19:53Z","receivedAt":"2007-05-06T10:19:53Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-05 10:26:12 -0700, Linus Torvalds wrote:\n\n> The \"-S\" thing doesn't really interact well with \"gitk\", because it\n> doesn't rewrite the parent information (it is basically just a \"hide\n> commits that don't pass this criteria\"). As such, gitk, which\n> requires parent information to generate the graph, is not very\n> amenable to using \"-S\" and such.\n>\n> That said, you can apply this fairly trivial patch to \"gitk\" to make\n> it parse the output of \"git log\" rather than \"git rev-list\", and\n> that will actually get you working -S'xyz' parsing automatically.\n> It's just that the commit history window will look like crap.\n\nOK, now I've tested it, and just as you said, it works (and is _very_\nuseful) but looks like crap. :-)\n\nIs there any fundamental reason why\n\n gitk -- some/path/name\n\ngenerates a nice, connected graph, while\n\n gitk -S'some string'\n\ngenerates disconnected spaghetti? Or could the latter be made to use\nthe same parent-rewriting logic as the first?\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41200","messageId":"20070506111411.GC17498@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"e5bfff550705060115o60fdd637h6c7393d06f75c55@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T11:14:11Z","receivedAt":"2007-05-06T11:14:11Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:\n\n> Use qgit ;-)\n\nDo I have to use any particular autoconf version? With\n\n kha@yoghurt:~/qgit> autoreconf --version\n autoreconf (GNU Autoconf) 2.60\n\nI get a few warnings and errors when I run \"autoreconf -i\", and the\ngenerated configure script has bugs that prevent it from finishing\nsuccessfully. (I'm trying to build qgit\n4facdd5fc1731662ff9cdf096a576d40b938885c.)\n\nOutput follows:\n\nkha@yoghurt:~/qgit> autoreconf -i\nconfigure.ac: 9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'\nautomake: configure.ac: installing `config/install-sh'\nautomake: configure.ac: installing `config/mkinstalldirs'\nautomake: configure.ac: installing `config/missing'\nautomake: configure.ac: installing `config/config.guess'\nautomake: configure.ac: installing `config/config.sub'\nautomake: Makefile.am: installing `./INSTALL'\nautomake: Makefile.am: required file `./NEWS' not found\nautomake: Makefile.am: required file `./AUTHORS' not found\nconfigure.ac: 9: required file `./[config.h].in' not found\nsrc/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'\nautoreconf: automake failed with exit status: 1\n\nkha@yoghurt:~/qgit> ./configure --prefix=/usr/local/stow/qgit\nchecking for a BSD-compatible install... /usr/bin/install -c\nchecking whether build environment is sane... yes\nchecking whether make sets $(MAKE)... yes\n./configure: line 1874: 1.8: command not found\nchecking for working aclocal-1.4... found\nchecking for working autoconf... found\nchecking for working automake-1.4... found\nchecking for working autoheader... found\nchecking for working makeinfo... found\nchecking for g++... g++\nchecking for C++ compiler default output file name... a.out\nchecking whether the C++ compiler works... yes\nchecking whether we are cross compiling... no\nchecking for suffix of executables... \nchecking for suffix of object files... o\nchecking whether we are using the GNU C++ compiler... yes\nchecking whether g++ accepts -g... yes\nchecking for a BSD-compatible install... /usr/bin/install -c\nchecking how to run the C++ preprocessor... g++ -E\nchecking for X... libraries , headers \nchecking for gethostbyname... yes\nchecking for connect... yes\nchecking for remove... yes\nchecking for shmat... yes\nchecking for IceConnectionNumber in -lICE... yes\nchecking for Qt includes... /usr/share/qt3/include\nchecking Qt version... 3.3.6\nchecking for moc... /usr/share/qt3/bin/moc\nchecking for uic... /usr/share/qt3/bin/uic\nchecking for pthread_exit in -lpthread... yes\nchecking for XftFontOpen in -lXft... yes\nchecking for main in -lqt-mt... yes\nconfigure: QT_CPPFLAGS = -I/usr/share/qt3/include -D_REENTRANT -DQT_THREAD_SUPPORT\nconfigure: QT_LDFLAGS = -L/usr/share/qt3/lib\nconfigure: QT_LIBS = -lqt-mt -lpthread -lXft -lSM -lICE -lX11 \nconfigure: creating ./config.status\nconfig.status: creating Makefile\nconfig.status: WARNING: Makefile.in seems to ignore the --datarootdir setting\nconfig.status: creating src/Makefile\nconfig.status: WARNING: src/Makefile.in seems to ignore the --datarootdir setting\nconfig.status: creating config.h\nkha@yoghurt:~/qgit> make\nmake[1]: Entering directory `/home/kha/qgit'\ncd . && autoheader\nmake[1]: Leaving directory `/home/kha/qgit'\ncd . \\\n && CONFIG_FILES= CONFIG_HEADERS=[config.h] \\\n /bin/bash ./config.status\nconfig.status: error: cannot find input file: [config.h].in\nmake: *** [stamp-h] Error 1\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41201","messageId":"e5bfff550705060519s2c1abd7cl7ecedeb497e10e3b@mail.gmail.com","threadId":"7944","inReplyTo":"20070506111411.GC17498@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-06T12:19:55Z","receivedAt":"2007-05-06T12:19:55Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/6/07, Karl Hasselström wrote:\n> On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:\n>\n> > Use qgit ;-)\n>\n> Do I have to use any particular autoconf version? With\n>\n\nSorry but I cannot reproduce the misbehaviour, my logs are below.\n\nThe only difference is that my autoreconf is 2.61 instead of 2.60\n\nPavel, some ideas?\n\n\nIn the mean time you can download the released tarball from\nhttp://prdownloads.sourceforge.net/qgit/qgit-1.5.5.tar.bz2?download\n\nYou don't need autoreconf in that case and can go directly with\n\n configure/make/make install-strip\n\n\n\nMy log:\n\nbash-3.1$ git clone git://git.kernel.org/pub/scm/qgit/qgit.git\nInitialized empty Git repository in /home/marco/tmp/qgit/.git/\nremote: Generating pack...\nremote: Done counting 5723 objects.\nremote: Deltifying 5723 objects.\nremote: 100% (5723/5723) done\nIndexing 5723 objects...\nremote: Total 5723 (delta 4541), reused 5612 (delta 4461)\n 100% (5723/5723) done\nResolving 4541 deltas...\n 100% (4541/4541) done\n\nbash-3.1$ cd qgit\nbash-3.1$ autoreconf --version\nautoreconf (GNU Autoconf) 2.61\nCopyright (C) 2006 Free Software Foundation, Inc.\nThis is free software. You may redistribute copies of it under the terms of\nthe GNU General Public License .\nThere is NO WARRANTY, to the extent permitted by law.\n\nWritten by David J. MacKenzie and Akim Demaille.\nbash-3.1$ autoreconf -i\nconfigure.ac: installing `config/install-sh'\nconfigure.ac: installing `config/missing'\nsrc/Makefile.am: installing `config/depcomp'\nbash-3.1$ ./configure\nchecking for a BSD-compatible install... /usr/bin/install -c\nchecking whether build environment is sane... yes\nchecking for gawk... gawk\nchecking whether make sets $(MAKE)... yes\nchecking for g++... g++\nchecking for C++ compiler default output file name... a.out\nchecking whether the C++ compiler works... yes\nchecking whether we are cross compiling... no\nchecking for suffix of executables...\nchecking for suffix of object files... o\nchecking whether we are using the GNU C++ compiler... yes\nchecking whether g++ accepts -g... yes\nchecking for style of include used by make... GNU\nchecking dependency style of g++... gcc3\nchecking for a BSD-compatible install... /usr/bin/install -c\nchecking for prefix by checking for qgit... /home/marco/bin/qgit\nchecking how to run the C++ preprocessor... g++ -E\nchecking for X... libraries , headers\nchecking for gethostbyname... yes\nchecking for connect... yes\nchecking for remove... yes\nchecking for shmat... yes\nchecking for IceConnectionNumber in -lICE... yes\nchecking for Qt includes... /usr/lib/qt3//include\nchecking Qt version... 3.3.8\nchecking for moc... /usr/lib/qt3//bin/moc\nchecking for uic... /usr/lib/qt3//bin/uic\nchecking for pthread_exit in -lpthread... yes\nchecking for XftFontOpen in -lXft... yes\nchecking for main in -lqt-mt... yes\nconfigure: QT_CPPFLAGS = -I/usr/lib/qt3//include -D_REENTRANT\n-DQT_THREAD_SUPPORT\nconfigure: QT_LDFLAGS = -L/usr/lib/qt3//lib\nconfigure: QT_LIBS = -lqt-mt -lpthread -lXft -lSM -lICE -lX11\nconfigure: creating ./config.status\nconfig.status: creating Makefile\nconfig.status: creating src/Makefile\nconfig.status: creating config.h\nconfig.status: executing depfiles commands\n\nbash-3.1$ make\nmake all-recursive\nmake[1]: Entering directory `/home/marco/tmp/qgit'\nMaking all in src\nmake[2]: Entering directory `/home/marco/tmp/qgit/src'\n/usr/lib/qt3//bin/uic -o commitbase.h commitbase.ui\n/usr/lib/qt3//bin/uic -o consolebase.h consolebase.ui\n\n-------------- cut ---------------------\n\nif g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/usr/lib/qt3//include\n-D_REENTRANT -DQT_THREAD_SUPPORT -g -O2 -Wall -Wno-non-virtual-dtor\n-W -Wno-long-long -pedantic -frepo -MT settingsbase.uic.o -MD -MP -MF\n\".deps/settingsbase.uic.Tpo\" -c -o settingsbase.uic.o\nsettingsbase.uic.cc; \\\n then mv -f \".deps/settingsbase.uic.Tpo\"\n\".deps/settingsbase.uic.Po\"; else rm -f \".deps/settingsbase.uic.Tpo\";\nexit 1; fi\ng++ -g -O2 -Wall -Wno-non-virtual-dtor -W -Wno-long-long -pedantic\n-frepo -L/usr/lib/qt3//lib -o qgit annotate.o cache.o commitimpl.o\nconsoleimpl.o customactionimpl.o dataloader.o domain.o\nexceptionmanager.o filecontent.o filelist.o fileview.o git.o\ngit_startup.o lanes.o listview.o mainimpl.o myprocess.o\nnamespace_def.o patchview.o qgit.o rangeselectimpl.o revdesc.o\nrevsview.o settingsimpl.o treeview.o commitbase.moc.o\nconsolebase.moc.o customactionbase.moc.o filebase.moc.o helpbase.moc.o\nmainbase.moc.o patchbase.moc.o rangeselectbase.moc.o revbase.moc.o\nsettingsbase.moc.o annotate.moc.o commitimpl.moc.o consoleimpl.moc.o\ncustomactionimpl.moc.o dataloader.moc.o domain.moc.o filecontent.moc.o\nfilelist.moc.o fileview.moc.o git.moc.o listview.moc.o mainimpl.moc.o\nmyprocess.moc.o patchview.moc.o rangeselectimpl.moc.o revdesc.moc.o\nrevsview.moc.o settingsimpl.moc.o treeview.moc.o commitbase.uic.o\nconsolebase.uic.o customactionbase.uic.o filebase.uic.o helpbase.uic.o\nmainbase.uic.o patchbase.uic.o rangeselectbase.uic.o revbase.uic.o\nsettingsbase.uic.o -lqt-mt -lpthread -lXft -lSM -lICE -lX11\ncollect: recompiling patchview.cpp\ncollect: recompiling mainimpl.cpp\ncollect: recompiling git_startup.cpp\ncollect: recompiling git.cpp\n\n-------------- cut ---------------------\n\ncollect: relinking\ncollect: recompiling mainimpl.cpp\ncollect: recompiling git_startup.cpp\ncollect: recompiling git.cpp\ncollect: recompiling annotate.cpp\ncollect: relinking\nmake[3]: Leaving directory `/home/marco/tmp/qgit/src'\nmake[2]: Leaving directory `/home/marco/tmp/qgit/src'\nmake[2]: Entering directory `/home/marco/tmp/qgit'\nmake[2]: Nothing to be done for `all-am'.\nmake[2]: Leaving directory `/home/marco/tmp/qgit'\nmake[1]: Leaving directory `/home/marco/tmp/qgit'\n\nbash-3.1$ make install-strip\nmake INSTALL_PROGRAM=\"/bin/sh /home/marco/tmp/qgit/config/install-sh -c -s\" \\\n install_sh_PROGRAM=\"/bin/sh\n/home/marco/tmp/qgit/config/install-sh -c -s\" INSTALL_STRIP_FLAG=-s \\\n `test -z '' || \\\n echo \"INSTALL_PROGRAM_ENV=STRIPPROG=''\"` install\nmake[1]: Entering directory `/home/marco/tmp/qgit'\nMaking install in src\nmake[2]: Entering directory `/home/marco/tmp/qgit/src'\nmake install-am\n\n-------------- cut ---------------------\n\nmake[2]: Leaving directory `/home/marco/tmp/qgit'\nmake[1]: Leaving directory `/home/marco/tmp/qgit'\n\nbash-3.1$ qgit\nFound GNU source-highlight 2.5\nSaving cache. Please wait...\nCompressing data...\nDone.\nbash-3.1$\n"},{"id":"41203","messageId":"20070506123349.GB18883@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"e5bfff550705060519s2c1abd7cl7ecedeb497e10e3b@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T12:33:49Z","receivedAt":"2007-05-06T12:33:49Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 14:19:55 +0200, Marco Costalba wrote:\n\n> In the mean time you can download the released tarball from\n> http://prdownloads.sourceforge.net/qgit/qgit-1.5.5.tar.bz2?download\n>\n> You don't need autoreconf in that case and can go directly with\n>\n> configure/make/make install-strip\n\nWorks like a charm. Thanks.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41204","messageId":"e5bfff550705060533x18f63c09rc6a742058b82f712@mail.gmail.com","threadId":"7944","inReplyTo":"e5bfff550705060519s2c1abd7cl7ecedeb497e10e3b@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-06T12:33:59Z","receivedAt":"2007-05-06T12:33:59Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/6/07, Marco Costalba wrote:\n> On 5/6/07, Karl Hasselström wrote:\n> > On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:\n> >\n> > > Use qgit ;-)\n> >\n> > Do I have to use any particular autoconf version? With\n> >\n>\n\nAfter googling a little bit....\n\nPlease apply this patch before to run 'autoreconf -i' on a *fresh\ncloned* repository\n\ndiff --git a/configure.ac b/configure.ac\nindex e352eba..95f45d1 100644\n--- a/configure.ac\n+++ b/configure.ac\n@@ -6,7 +6,7 @@ AC_INIT(qgit, 1.5.5)\n AC_CONFIG_AUX_DIR(config)\n AM_INIT_AUTOMAKE(foreign 1.8)\n AC_CONFIG_SRCDIR([src/annotate.cpp])\n-AC_CONFIG_HEADER([config.h])\n+AM_CONFIG_HEADER([config.h])\n\n # Checks for programs.\n AC_LANG(C++)\n\n\nOn my box it compiles the same and perhaps you can avoid the reported errors.\n\nPlease, let me know how it goes.\n\nMarco\n"},{"id":"41205","messageId":"20070506125938.GA19317@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"e5bfff550705060533x18f63c09rc6a742058b82f712@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T12:59:38Z","receivedAt":"2007-05-06T12:59:38Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 14:33:59 +0200, Marco Costalba wrote:\n\n> After googling a little bit....\n>\n> Please apply this patch before to run 'autoreconf -i' on a *fresh\n> cloned* repository\n>\n> diff --git a/configure.ac b/configure.ac\n> index e352eba..95f45d1 100644\n> --- a/configure.ac\n> +++ b/configure.ac\n> @@ -6,7 +6,7 @@ AC_INIT(qgit, 1.5.5)\n> AC_CONFIG_AUX_DIR(config)\n> AM_INIT_AUTOMAKE(foreign 1.8)\n> AC_CONFIG_SRCDIR([src/annotate.cpp])\n> -AC_CONFIG_HEADER([config.h])\n> +AM_CONFIG_HEADER([config.h])\n>\n> # Checks for programs.\n> AC_LANG(C++)\n>\n>\n> On my box it compiles the same and perhaps you can avoid the\n> reported errors. Please, let me know how it goes.\n\nNope, no luck. I get the same error messages from autoreconf:\n\nkha@yoghurt:~/qgit> autoreconf -i\nautomake: configure.ac: installing `config/install-sh'\nautomake: configure.ac: installing `config/mkinstalldirs'\nautomake: configure.ac: installing `config/missing'\nautomake: configure.ac: installing `config/config.guess'\nautomake: configure.ac: installing `config/config.sub'\nautomake: Makefile.am: installing `./INSTALL'\nautomake: Makefile.am: required file `./NEWS' not found\nautomake: Makefile.am: required file `./AUTHORS' not found\nconfigure.ac: 9: required file `./[config.h].in' not found\nsrc/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'\nautoreconf: automake failed with exit status: 1\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41206","messageId":"20070506130326.GB19317@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"20070506125938.GA19317@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T13:03:26Z","receivedAt":"2007-05-06T13:03:26Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 14:59:38 +0200, Karl Hasselström wrote:\n\n> Nope, no luck. I get the same error messages from autoreconf:\n>\n> kha@yoghurt:~/qgit> autoreconf -i\n> automake: configure.ac: installing `config/install-sh'\n> automake: configure.ac: installing `config/mkinstalldirs'\n> automake: configure.ac: installing `config/missing'\n> automake: configure.ac: installing `config/config.guess'\n> automake: configure.ac: installing `config/config.sub'\n> automake: Makefile.am: installing `./INSTALL'\n> automake: Makefile.am: required file `./NEWS' not found\n> automake: Makefile.am: required file `./AUTHORS' not found\n> configure.ac: 9: required file `./[config.h].in' not found\n> src/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'\n> autoreconf: automake failed with exit status: 1\n\nWell, actually some luck. This line was first in my previous output,\nbut doesn't appear with your patch:\n\nconfigure.ac: 9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'\n\nBut there seems to be more stuff to fix. :-(\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41219","messageId":"alpine.LFD.0.98.0705060919010.25245@woody.linux-foundation.org","threadId":"7944","inReplyTo":"20070506101953.GA17498@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-06T16:38:48Z","receivedAt":"2007-05-06T16:38:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 6 May 2007, Karl Hasselstr?m wrote:\n> \n> OK, now I've tested it, and just as you said, it works (and is _very_\n> useful) but looks like crap. :-)\n> \n> Is there any fundamental reason why\n> \n> gitk -- some/path/name\n> \n> generates a nice, connected graph, while\n> \n> gitk -S'some string'\n> \n> generates disconnected spaghetti?\n\nThere is a reason, and it's fairly fundamental: the path limiting code is \ndeeply embedded in the revision walking, and I've spent a fair amount of \neffort on making that work and efficient as hell (it's one of the few \nareas in git where I'm probably still the main author). Because it's \nliterally what I do 90% of the time: for me, the path-limiting code is \nbasically _the_ most important git feature, and I care very deeply.\n\nIn contrast, the \"-S\" thing is not actually part of the revision walking \nat all, and is a totally separate phase that is done when revisions are \n_shown_. I almost never use it myself, and it grew out of a totally \nseparate effort by Junio. \n\n> Or could the latter be made to use the same parent-rewriting logic as \n> the first?\n\nIt would probably be possible to make the -S logic be another part of the \n\"prune_fn()\" logic in revision.c, and it might even simplify some of the \nlogic, but I suspect it would actually suck really really badly from a \nperformance standpoint.\n\nWhy? Because the prune_fn() logic is done when we generate the revision \ngraph, which is generally something that a lot of the operations have to \ndo up-front before they can do _anything_ else. Eg, any revision limiter \n(and that's a very common case) like \"v2.6.21..\" will cause the revision \npruning to happen synchronously and early on.\n\nAnd the path-limiting is *fast*. It's so incredibly fast that people don't \nreally realize how fast it is. And it absolutely needs to be fast, because \nwhen you do something like \"gitk v2.6.18.. drivers/\" on the kernel you end \nup doing a _lot_ of tree comparisons. It's why I'm pretty sure nobody else \ncan ever do what git does - it takes full advantage of how git can tell \nthat a whole subdirectory hasn't changed without even recursing into it.\n\nIn contrast, \"-S\" is _slow_. It's a really really expensive operation. Git \nmakes generating diffs faster than just about anything else, but it's \nstill really expensive. This is a really unfair comparison, but:\n\n\ttime git log drivers/net/ > /dev/null\n\n\treal 0m1.488s\n\tuser 0m1.444s\n\tsys 0m0.040s\n\nie we can do the log pruning for the whole kernel git history on a \nsubdirectory in less than two seconds. \n\nTry to compare it with\n\n\ttime git log -Sdrivers/net/ > /dev/null\n\nand I suspect you won't have the patience to wait for the end result.\n\nAnd yeah, the operations are fundamentally very very different, and yes, \nthe latter operation is really really expensive (which is why I said it's \na really unfair comparison). But the point is that the expense comes from \nhow git has been designed: seeing differences in the paths is cheap by \ndesign (it's how the data structures are laid out), but seeing differences \nin actual diffs means that we have to fully generate each diff for each \nrevision!\n\nA different approach to the underlying datastructures could change the \nequation. For example, if the fundamental data representation was the \n\"diff\" (rather than the \"whole tree\") maybe -S would be as fast as path \nlimiting. But you'd *really* suck for other things.\n\nTo summarize a long story: the path limiting is simply more fundamental in \ngit. Both by design, and then - obviously partly _due_ to that - by pure \neffort we've spent on it. It's something very deep and very important. In \ncomparison, the -S thing is a cute extra feature, nothing really \"deep\".\n\n\t\tLinus\n"},{"id":"41328","messageId":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","threadId":"7944","inReplyTo":"alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org","subject":"Re: FFmpeg considering GIT","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-05-07T12:13:44Z","receivedAt":"2007-05-07T12:13:44Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Finally, it realy _should_ check that the first 7 characters of the commit \n> log (the ones it ignores by just asking for substring 7..) are actually \n> the exact characters \"commit \", but I'll blame my lack of comfort with the \n> language again.\n\nI have thought about rewriting it in a different language, but I\nhaven't found anything that really appeals. I don't want to go to\nC/GTK or C/Qt since that would make it hard to port to Windows and\nMacOS AFAIK. Python/Tk would be a possibility, but I have never\nlearnt python and I'm actually not all that comfortable with having to\ndo things the object-oriented way.\n\nAny suggestions?\n\nTcl/Tk does come with a comprehensive set of man pages, usually\ninstalled either in section n or sections 3tcl and 3tk. So you can do\n\"man string\" to find out how to do string manipulations, for instance.\nThe syntax is quite regular and is explained in the \"Tcl\" man page.\n\nPaul.\n"},{"id":"41330","messageId":"20070507123055.GB3255@diana.vm.bytemark.co.uk","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-07T12:30:55Z","receivedAt":"2007-05-07T12:30:55Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-07 22:13:44 +1000, Paul Mackerras wrote:\n\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having\n> to do things the object-oriented way.\n>\n> Any suggestions?\n\nwxWidgets (http://www.wxwidgets.org/) is a cross-platform C++ library\nthat seems popular. There are bindings for lots of languages,\nincluding Python (http://www.wxpython.org/).\n\n \"wxWidgets lets developers create applications for Win32, Mac OS X,\n GTK+, X11, Motif, WinCE, and more using one codebase. It can be used\n from languages such as C++, Python, Perl, and C#/.NET.\"\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41333","messageId":"200705071450.39233.johan@herland.net","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-05-07T12:50:34Z","receivedAt":"2007-05-07T12:50:34Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 07 May 2007, Paul Mackerras wrote:\n> I don't want to go to C/Qt since that would make it hard to port to\n> Windows and MacOS AFAIK.\n\nWrong. Qt is now GPL for Windows, Linux, Unix, and Mac OS X. See \nhttp://www.trolltech.com/products/qt/licenses/licensing/opensource for more \ninfo.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"41335","messageId":"81b0412b0705070556o25289676i2df60ad84a2a4e13@mail.gmail.com","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-07T12:56:37Z","receivedAt":"2007-05-07T12:56:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/7/07, Paul Mackerras wrote:\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n\nC++/Qt4 is ported to Windows.\n\n> Any suggestions?\n\nIt(Qt4) wasn't a suggestion though. I still consider Tcl/Tk more portable.\n"},{"id":"41350","messageId":"20070507175222.GA13927@efreet.light.src","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-07T17:52:22Z","receivedAt":"2007-05-07T17:52:22Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, May 07, 2007 at 22:13:44 +1000, Paul Mackerras wrote:\n> Linus Torvalds writes:\n> \n> > Finally, it realy _should_ check that the first 7 characters of the commit \n> > log (the ones it ignores by just asking for substring 7..) are actually \n> > the exact characters \"commit \", but I'll blame my lack of comfort with the \n> > language again.\n> \n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n\nC/Gtk would be perfectly portable. As would C++/Gtk, Python/Gtk and Perl/Gtk.\nC++/Qt4 would be perfectly portable as well, so choose whichever you find\neasier to work with. For C/C++ they are on par, for Python/Perl/Ruby I think\nGtk has better bindings.\n\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having to\n> do things the object-oriented way.\n\nI would actually recommend against Python/Tk, because (tried it) py2exe does\nnot work seem to work with it, so you couldn't wrap it to easy to install\nbinary for windows folks. I did not try Python/Gtk, but I expect you might\nhave better luck with it (it's the Tcl/Tk interpreter that causes problems).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"41352","messageId":"7vfy6878la.fsf@assigned-by-dhcp.cox.net","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-07T19:10:57Z","receivedAt":"2007-05-07T19:10:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Linus Torvalds writes:\n>\n>> Finally, it realy _should_ check that the first 7 characters of the commit \n>> log (the ones it ignores by just asking for substring 7..) are actually \n>> the exact characters \"commit \", but I'll blame my lack of comfort with the \n>> language again.\n>\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having to\n> do things the object-oriented way.\n>\n> Any suggestions?\n\nI've looked at Perl and Python Tk integration in the past; they\ntake slightly different approaches. The Perl integration tries\nto first libify Tk part to make it less dependent to the host\nlanguage, tcl, and then retargets it to a new host language,\nPerl. Compared to that, Python integration was shallower;\ncalling from Python to Tk and callback from Tk to Python were\ndone using Tcl as intermediary. Which looked somewhat hacky but\nat the same time cleaner. From scriptability point of view,\nboth were much more pleasant to use than tcl. You would have\nobject-orientation in the nature of data anyway (e.g. your\ncommitdata, commitlisted, commitidx and friends will not be\nlook-up tables keyed with commit object name, rather they will\nbecome attributes to commit objects), so I would expect doing it\nin Python+Tk would feel natural.\n"},{"id":"41371","messageId":"463FA3C5.70101@nekomancer.net","threadId":"7944","inReplyTo":"20070507175222.GA13927@efreet.light.src","subject":"Re: FFmpeg considering GIT","fromName":"Gábor Farkas","fromEmail":"gabor@nekomancer.net","sentAt":"2007-05-07T22:10:13Z","receivedAt":"2007-05-07T22:10:13Z","isPatch":false,"sender":{"key":"gabor@nekomancer.net","avatar":null},"body":"Jan Hudec wrote:\n> On Mon, May 07, 2007 at 22:13:44 +1000, Paul Mackerras wrote:\n>> I have thought about rewriting it in a different language, but I\n>> haven't found anything that really appeals. I don't want to go to\n>> C/GTK or C/Qt since that would make it hard to port to Windows and\n> \n> C/Gtk would be perfectly portable. As would C++/Gtk, Python/Gtk and Perl/Gtk.\n> C++/Qt4 would be perfectly portable as well, so choose whichever you find\n> easier to work with. For C/C++ they are on par, for Python/Perl/Ruby I think\n> Gtk has better bindings.\n> \n>> MacOS AFAIK.\n\nGTK does not work natively on OSX (it only works using the X11 server ).\nQT works fine.\n\ngabor\n"},{"id":"41374","messageId":"868xc0cja0.fsf@blue.stonehenge.com","threadId":"7944","inReplyTo":"463FA3C5.70101@nekomancer.net","subject":"Re: FFmpeg considering GIT","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-05-07T23:21:11Z","receivedAt":"2007-05-07T23:21:11Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Gábor\" == Gábor Farkas writes:\n\nGábor> GTK does not work natively on OSX (it only works using the X11 server ).\n\nBut \"Tk\" works fine. I don't fire up X11, except rarely. And gitk works fine.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"41390","messageId":"20070508020338.GF11311@spearce.org","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T02:03:38Z","receivedAt":"2007-05-08T02:03:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Paul Mackerras wrote:\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having to\n> do things the object-oriented way.\n> \n> Any suggestions?\n\nFunny that you mention this. Lately I have been hacking on git-gui,\ntrying to improve it and clean up some of the code.\n\nI've thought about wxWindows but didn't really dig into it to see\nhow usuable it would be - primary reason is not everyone has it\ninstalled on their system. The same for GTK and Qt. Actually I\ndon't even have GTK installed on my Mac but I did install Qt3\n(took half a day!) so I could build qgit at one point in time.\n\nBut almost everyone already has a wish installed.\n\nI've thought about writing git-gui in C, but linking to the Tk\nlibrary for the \"portable UI\". But not everyone has the Tcl/Tk\ndevelopment headers and libraries installed, but they probably do\nhave the wish executable installed.\n\nI want to limit the barrier to entry for git, and that means limiting\nthe barrier of entry for git-gui. Keeping our requirements to a\nminimum helps.\n\nSo I think I've settled on sticking to Tcl and its Tk extensions,\nbut making more use of newer Tcl constructs like namespaces. If you\nlook at my `pu` branch of git-gui I have actually split the program\ndown into many files, and have started to organize the code in each\ninto different namespaces, depending on function.\n\n-- \nShawn.\n"},{"id":"41420","messageId":"e5bfff550705072330h3b59f4a5off5f9e341ccf3e7e@mail.gmail.com","threadId":"7944","inReplyTo":"81b0412b0705070556o25289676i2df60ad84a2a4e13@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-08T06:30:15Z","receivedAt":"2007-05-08T06:30:15Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/7/07, Alex Riesen wrote:\n> On 5/7/07, Paul Mackerras wrote:\n> > I have thought about rewriting it in a different language, but I\n> > haven't found anything that really appeals. I don't want to go to\n> > C/GTK or C/Qt since that would make it hard to port to Windows and\n> > MacOS AFAIK. Python/Tk would be a possibility, but I have never\n>\n> C++/Qt4 is ported to Windows.\n>\n> > Any suggestions?\n>\n> It(Qt4) wasn't a suggestion though. I still consider Tcl/Tk more portable.\n> -\n\nQt4 is a very good designed and elegant API and it works perfectly\nunder Windows, see current porting of qgit under Windows:\n\n git://git.kernel.org/pub/scm/qgit/qgit4\n\n\nLanguage to use is C++, not C (much more powerful IMHO)\n\nOne thing that you should note is that if you go Qt4/C++ you can\nforget to have it all in one file.\n\nI think you should consider the new gitk 'footprint' becuase if you\nleave TCL, any windows library you use will force you to create a\nmulti file project.\n\n Marco\n\nP.S: If you choose Qt/C++ (the best technically speaking ;-) please\nyou could consider starting from an already laid out code base instead\nof starting from scratch.\nAs example, hmmmm, I think there is one called 'qgit', if I remember\ncorrectly. It's nice and very very very fast.\n"},{"id":"41424","messageId":"20070508072651.GA1554@coredump.intra.peff.net","threadId":"7944","inReplyTo":"17983.6136.147062.346626@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-08T07:26:52Z","receivedAt":"2007-05-08T07:26:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 07, 2007 at 10:13:44PM +1000, Paul Mackerras wrote:\n\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having to\n> do things the object-oriented way.\n> \n> Any suggestions?\n\nI just ran across this today (it was just packaged for Debian):\n\n http://developer.imendio.com/projects/giggle\n\nIt seems to be a C/GTK repository browser (but also with a few git-gui\ntype features). It doesn't seem very far along (the viewer barfs on the\ngit.git repo, but shows some of my simpler repos), but it might worth\nstarting a dialogue with those guys.\n\n-Peff\n"},{"id":"41473","messageId":"46409D07.3050808@nekomancer.net","threadId":"7944","inReplyTo":"fcaeb9bf0705080707x7ad28afelf98ecd93276042d1@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Gábor Farkas","fromEmail":"gabor@nekomancer.net","sentAt":"2007-05-08T15:53:43Z","receivedAt":"2007-05-08T15:53:43Z","isPatch":false,"sender":{"key":"gabor@nekomancer.net","avatar":null},"body":"Nguyen Thai Ngoc Duy wrote:\n> On 5/7/07, Gábor Farkas wrote:\n>> >> MacOS AFAIK.\n>>\n>> GTK does not work natively on OSX (it only works using the X11 server ).\n>> QT works fine.\n>>\n>> gabor\n> \n> Recent GTK+ can work on OSX without X11:\n> http://developer.imendio.com/projects/gtk-macosx\n> \n\ni know about that project, but it does not seem to be finished yet.\n\nfor example, in \nhttp://developer.imendio.com/projects/gtk-macosx/build-instructions\n\nthey write:\n\n\n\nNOTE: This is mainly meant for developers wanting to help out with GTK+ \nMac OS X, not for users. The port is not yet finished or usable for \nmainstream use.\n\n\n\ngabor\n"},{"id":"41531","messageId":"17985.19926.347089.878721@cargo.ozlabs.ibm.com","threadId":"7944","inReplyTo":"e5bfff550705072330h3b59f4a5off5f9e341ccf3e7e@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-05-09T04:28:06Z","receivedAt":"2007-05-09T04:28:06Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Marco Costalba writes:\n\n> Language to use is C++, not C (much more powerful IMHO)\n\nSorry, C++ is not an option because I dislike it so much. The main\nreason for changing languages would be to enable people like Linus to\nhack on it more easily, and I don't think C++ would achieve that.\n\n> P.S: If you choose Qt/C++ (the best technically speaking ;-) please\n> you could consider starting from an already laid out code base instead\n> of starting from scratch.\n> As example, hmmmm, I think there is one called 'qgit', if I remember\n> correctly. It's nice and very very very fast.\n\nYes, but isn't there already a talented hacker working on that? :)\n\nPaul.\n"},{"id":"41543","messageId":"e5bfff550705082338p1a0c003lef230f96a3219ab8@mail.gmail.com","threadId":"7944","inReplyTo":"17985.19926.347089.878721@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-09T06:38:48Z","receivedAt":"2007-05-09T06:38:48Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/9/07, Paul Mackerras wrote:\n> Marco Costalba writes:\n>\n> > Language to use is C++, not C (much more powerful IMHO)\n>\n> Sorry, C++ is not an option because I dislike it so much.\n\nWell, speaking about GUI applications, the 90% is in the graphic\nlibrary and only in small part in the language. With Qt we are at 95%\n\nAnyhow does exist also python bindings for Qt.\n\n\n> The main\n> reason for changing languages would be to enable people like Linus to\n> hack on it more easily, and I don't think C++ would achieve that.\n>\n\nPoor Linus ;-)\n\nI think the design of the application states the easiness of changes,\nspaghetti code and bad designed functions are much worst then any ugly\nlanguage you can think about.\n\nThat's for substantial changes, for one liners or for adding little\nfeatures encapsulation and modularity of the code are the magical\nwords here, and an object oriented language *could* help achieving\nthat.\n\n\n> > P.S: If you choose Qt/C++ (the best technically speaking ;-) please\n> > you could consider starting from an already laid out code base instead\n> > of starting from scratch.\n> > As example, hmmmm, I think there is one called 'qgit', if I remember\n> > correctly. It's nice and very very very fast.\n>\n> Yes, but isn't there already a talented hacker working on that? :)\n>\n\nTwo is better then one :-)\n\n\n Marco\n"},{"id":"41637","messageId":"200705092017.06637.robin.rosenberg.lists@dewire.com","threadId":"7944","inReplyTo":"e5bfff550705082338p1a0c003lef230f96a3219ab8@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-05-09T18:17:06Z","receivedAt":"2007-05-09T18:17:06Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 09 maj 2007 skrev Marco Costalba:\n> On 5/9/07, Paul Mackerras wrote:\n> > Marco Costalba writes:\n> >\n> > > Language to use is C++, not C (much more powerful IMHO)\n> >\n> > Sorry, C++ is not an option because I dislike it so much.\n> \n> Well, speaking about GUI applications, the 90% is in the graphic\n> library and only in small part in the language. With Qt we are at 95%\n> \n> Anyhow does exist also python bindings for Qt.\n\nYes, there is package called PyQT (GPL) here: http://www.riverbankcomputing.co.uk/pyqt/\n\nThere are bindings for most languages, even a Java binding.\n\n-- robin\n"},{"id":"41638","messageId":"20070509182844.GA2982@efreet.light.src","threadId":"7944","inReplyTo":"e5bfff550705082338p1a0c003lef230f96a3219ab8@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-09T18:28:44Z","receivedAt":"2007-05-09T18:28:44Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, May 09, 2007 at 08:38:48 +0200, Marco Costalba wrote:\n> On 5/9/07, Paul Mackerras wrote:\n> >Marco Costalba writes:\n> >\n> >> Language to use is C++, not C (much more powerful IMHO)\n> >\n> >Sorry, C++ is not an option because I dislike it so much.\n> \n> Well, speaking about GUI applications, the 90% is in the graphic\n> library and only in small part in the language. With Qt we are at 95%\n> \n> Anyhow does exist also python bindings for Qt.\n\nTried them, beed deeply disapointed. Qt always destroys all child objects\nwith the parent, which is OK in C++, but does not play well with\ngarbage-collection. And the python bindings (ruby ones seem to be better)\nfail to check reference validity, so you can quite easily segfault the python\ninterpreter. Gtk plays much better with dynamic languages.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"41666","messageId":"4c8ef70705091409g30674cb6p6d3af42eb47ffc08@mail.gmail.com","threadId":"7944","inReplyTo":"20070509182844.GA2982@efreet.light.src","subject":"Re: FFmpeg considering GIT","fromName":"Fredrik Kuivinen","fromEmail":"frekui@gmail.com","sentAt":"2007-05-09T21:09:25Z","receivedAt":"2007-05-09T21:09:25Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On 5/9/07, Jan Hudec wrote:\n> On Wed, May 09, 2007 at 08:38:48 +0200, Marco Costalba wrote:\n> > On 5/9/07, Paul Mackerras wrote:\n> > >Marco Costalba writes:\n> > >\n> > >> Language to use is C++, not C (much more powerful IMHO)\n> > >\n> > >Sorry, C++ is not an option because I dislike it so much.\n> >\n> > Well, speaking about GUI applications, the 90% is in the graphic\n> > library and only in small part in the language. With Qt we are at 95%\n> >\n> > Anyhow does exist also python bindings for Qt.\n>\n> Tried them, beed deeply disapointed. Qt always destroys all child objects\n> with the parent, which is OK in C++, but does not play well with\n> garbage-collection. And the python bindings (ruby ones seem to be better)\n> fail to check reference validity, so you can quite easily segfault the python\n> interpreter. Gtk plays much better with dynamic languages.\n\nI have used PyQt for some smaller projects (notably Hgct, a no longer developed\ncommit tool for git and Mercurial. See\nhttp://repo.or.cz/w/hgct.git?a=tree). For me\nPyQt has worked very well. The python interface to Qt is more or less a direct\ntranslation of the C++ interface, so the excellent documentation troll\ntech provides\nfor Qt can be used when developing with PyQt as well.\n\nI have never seen the segfaulting you mention. Maybe my programs have been too\nsmall to trigger that bug...\n\n- Fredrik\n"},{"id":"41667","messageId":"20070509213610.GA9144@efreet.light.src","threadId":"7944","inReplyTo":"4c8ef70705091409g30674cb6p6d3af42eb47ffc08@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-09T21:36:10Z","receivedAt":"2007-05-09T21:36:10Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, May 09, 2007 at 23:09:25 +0200, Fredrik Kuivinen wrote:\n> I have used PyQt for some smaller projects (notably Hgct, a no longer \n> developed\n> commit tool for git and Mercurial. See\n> http://repo.or.cz/w/hgct.git?a=tree). For me\n> PyQt has worked very well. The python interface to Qt is more or less a \n> direct\n> translation of the C++ interface, so the excellent documentation troll\n> tech provides\n> for Qt can be used when developing with PyQt as well.\n> \n> I have never seen the segfaulting you mention. Maybe my programs have been \n> too\n> small to trigger that bug...\n\nIt's not about size of the programs. It's about having to be careful not to\nrefer to widgets inside eg. dialog box from outside and close that dialog\nbox. That is having to be careful about something, that is normal in C++, but\nwhat you normally expect python to handle for you. And such quirks of the\nbindings are completely undocumented.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"41679","messageId":"1178749843.1680.17.camel@dv","threadId":"7944","inReplyTo":"20070506125938.GA19317@diana.vm.bytemark.co.uk","subject":"Re: FFmpeg considering GIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-05-09T22:30:43Z","receivedAt":"2007-05-09T22:30:43Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nOn Sun, 2007-05-06 at 14:59 +0200, Karl Hasselström wrote:\n> configure.ac: 9: required file `./[config.h].in' not found\n\nSorry for being late with the comments, but it looks like some very old\nAutomake doesn't understand that the argument to AC_CONFIG_HEADER or\nAM_CONFIG_HEADER can be quoted.\n\nRegarding AM_CONFIG_HEADER vs AC_CONFIG_HEADERS, the documentation for\nAutomake says:\n\nAC_CONFIG_HEADERS\nAutomake will generate rules to rebuild these headers. Older versions\nof Automake required the use of AM_CONFIG_HEADER; this is no longer the\ncase today.\n\nSo I suggest that we keep AC_CONFIG_HEADERS. Automake's NEWS file says\nAM_CONFIG_HEADER is obsolete since version 1.7.\n\n> src/Makefile.am:30: invalid unused variable name:\n> `nodist_qgit_SOURCES'\n\nThat's another sign of an obsolete version of Automake. \"nodist_\" was\nintroduced many years ago, back in the good old days when I had time to\ntrack its progress. NEWS says it was introduced in Automake 1.5!\n\nPerhaps we should require version 1.7 by adding this to the top-level\nMakefile.am:\n\nAUTOMAKE_OPTIONS = 1.7\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"41732","messageId":"e5bfff550705100420x63b365f7x526c1d58d9d5c761@mail.gmail.com","threadId":"7944","inReplyTo":"20070509213610.GA9144@efreet.light.src","subject":"Re: FFmpeg considering GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-10T11:20:02Z","receivedAt":"2007-05-10T11:20:02Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/9/07, Jan Hudec wrote:\n> On Wed, May 09, 2007 at 23:09:25 +0200, Fredrik Kuivinen wrote:\n> > I have used PyQt for some smaller projects (notably Hgct, a no longer\n> > developed\n> > commit tool for git and Mercurial. See\n> > http://repo.or.cz/w/hgct.git?a=tree). For me\n> > PyQt has worked very well. The python interface to Qt is more or less a\n> > direct\n> > translation of the C++ interface, so the excellent documentation troll\n> > tech provides\n> > for Qt can be used when developing with PyQt as well.\n> >\n> > I have never seen the segfaulting you mention. Maybe my programs have been\n> > too\n> > small to trigger that bug...\n>\n> It's not about size of the programs. It's about having to be careful not to\n> refer to widgets inside eg. dialog box from outside and close that dialog\n> box.\n\nIn Qt all the classes that ineriths from QObject are memory managed,\nto be more clear\nyou can say that one class is \"child\" of another class (always\nineritherd from QObject) that becames the parent.\n\nWhen you delete the parent, all his children are deleted too, this is\na (big) feature to avoid\nmissing free() calls for resources created with mallocs() , (well, in\nC++ we say 'delete' for resources created by 'new' but the concept is\nmore or less the same).\n\nNote that this property can be nested: create a main window, inside a\nwindow there is a tab form, inside the tab there is a list view,\ninside the list view there are items (lines of list view).\n\nSo *when* you delete the main window all this stuff is automatically\ndeleted by Qt. It is diffrent from a garbage collector because there\nis no delay in releasing memory and all the thing is strict\ndeterministic.\n\nSo coming to your problem, if you need to refer to a widget inside a\ndialog *after* the dialog has been deleted you can simply reparent to\nNULL the widget before closing the dialog so to remove your object\nfrom the delete list of the dialog.\n\nAnother option, in case your obect is not a graphical widget, is to\navoid declaring your object \"child\" of the dialog in first instance\nsetting his parent to NULL. This is clearly better because documents\n'in code' also the real relationship between the dialog and your\nobject.\n\n Marco\n"},{"id":"41752","messageId":"20070510165215.GA13060@efreet.light.src","threadId":"7944","inReplyTo":"e5bfff550705100420x63b365f7x526c1d58d9d5c761@mail.gmail.com","subject":"Re: FFmpeg considering GIT","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-10T16:52:15Z","receivedAt":"2007-05-10T16:52:15Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, May 10, 2007 at 13:20:02 +0200, Marco Costalba wrote:\n> On 5/9/07, Jan Hudec wrote:\n> >On Wed, May 09, 2007 at 23:09:25 +0200, Fredrik Kuivinen wrote:\n> >> I have used PyQt for some smaller projects (notably Hgct, a no longer\n> >> developed\n> >> commit tool for git and Mercurial. See\n> >> http://repo.or.cz/w/hgct.git?a=tree). For me\n> >> PyQt has worked very well. The python interface to Qt is more or less a\n> >> direct\n> >> translation of the C++ interface, so the excellent documentation troll\n> >> tech provides\n> >> for Qt can be used when developing with PyQt as well.\n> >>\n> >> I have never seen the segfaulting you mention. Maybe my programs have \n> >been\n> >> too\n> >> small to trigger that bug...\n> >\n> >It's not about size of the programs. It's about having to be careful not to\n> >refer to widgets inside eg. dialog box from outside and close that dialog\n> >box.\n> \n> In Qt all the classes that ineriths from QObject are memory managed,\n> to be more clear\n> you can say that one class is \"child\" of another class (always\n> ineritherd from QObject) that becames the parent.\n> \n> When you delete the parent, all his children are deleted too, this is\n> a (big) feature to avoid\n> missing free() calls for resources created with mallocs() , (well, in\n> C++ we say 'delete' for resources created by 'new' but the concept is\n> more or less the same).\n\nI know well how it works. And while it is definitely a nice feature in C++\n(though it can't beat well done reference-counting smart pointers as Gtkmm\nhas), it is a gross misfeature in any dynamic language.\n\nAnd no, I am not objecting to existence of that system -- it's useful in C++.\nWhat I say is, that the PyQt bindings are buggy because it completely\nfails to make this feature compatible with python memory management - python\nprogram should not be able to segfault the interpreter no matter how buggy\nthat program is.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}