{"thread":{"id":"43569","subject":"[ANNOUNCE] Cogito-0.18.2","startedAt":"2006-11-17T00:49:30Z","lastAt":"2006-11-17T01:58:06Z","messageCount":3,"participants":["Petr Baudis","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295583","messageId":"20061117004930.GC7201@pasky.or.cz","threadId":"43569","inReplyTo":null,"subject":"[ANNOUNCE] Cogito-0.18.2","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-17T00:49:30Z","receivedAt":"2006-11-17T00:49:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hello,\n\n I've released cogito-0.18.2, bringing a couple of bugfixes and a trivial new\nfeature to cogito-0.18.1. Still nothing too groundshattering.\n\n* cg-log does not follow history across renames anymore; it never really\n actually worked and was instead causing problems and random error\n messages. There needs to be git-core support for this funcionality,\n hacking it with a perl filter is bad design, so I'm not going to fix\n the filter (but I'd take patches if someone else did ;).\n\n* Fix cg-init not letting you edit the initial commit message by default\n* Fix cg-clone -l which would not setup alternates properly in some cases\n* Fix cg-merge not picking the right base when following volatile branches\n* Fix cg-log -d sometimes showing \"% @\" in diff output\n* Some other minor fixes\n\n* New cg-object-id -b to print the current branch name\n\n* Documentation improvements (better documented ignoring mechanism,\n ~/.gitconfig mentioned, GIT_COMMITTER_* bogus information fixed, ...)\n* Some testsuite fixes\n\n Happy hacking,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\n"},{"id":"296027","messageId":"46a038f90611161744q6c535218n5b815ef1fc5228b6@mail.gmail.com","threadId":"43569","inReplyTo":"20061117004930.GC7201@pasky.or.cz","subject":"Re: [ANNOUNCE] Cogito-0.18.2","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-17T01:44:47Z","receivedAt":"2006-11-17T01:44:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/17/06, Petr Baudis wrote:\n\n> * cg-log does not follow history across renames anymore; it never really\n> actually worked and was instead causing problems and random error\n> messages. There needs to be git-core support for this funcionality,\n> hacking it with a perl filter is bad design, so I'm not going to fix\n> the filter (but I'd take patches if someone else did ;).\n\nI was looking at the follow renames Perl script last week (hey, I was\nbored!) and while I could tell it didn't work, I did get the feeling\nthat it wasn't an impossible task, at least for the 'explicit paths'\ncase. For the 'whole tree' and subpath cases it _is_ tricky, and would\nbe faster to solve within git, but not impossible.\n\nAnd even then, I am tempted to think that git log could provide some\nbetter hints than it does today when walking the whole tree or\nsubpaths, so that cg-log or gitk can ask [if relevant] for selective\nrename info.\n\nI am curious as to why you see it as bad design...\n\ncheers,\n\n\n"},{"id":"298656","messageId":"20061117015806.GE7201@pasky.or.cz","threadId":"43569","inReplyTo":"46a038f90611161744q6c535218n5b815ef1fc5228b6@mail.gmail.com","subject":"Re: [ANNOUNCE] Cogito-0.18.2","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-17T01:58:06Z","receivedAt":"2006-11-17T01:58:06Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 17, 2006 at 02:44:47AM CET, Martin Langhoff wrote:\n> On 11/17/06, Petr Baudis wrote:\n> \n> >* cg-log does not follow history across renames anymore; it never really\n> > actually worked and was instead causing problems and random error\n> > messages. There needs to be git-core support for this funcionality,\n> > hacking it with a perl filter is bad design, so I'm not going to fix\n> > the filter (but I'd take patches if someone else did ;).\n> \n> I was looking at the follow renames Perl script last week (hey, I was\n> bored!) and while I could tell it didn't work, I did get the feeling\n> that it wasn't an impossible task, at least for the 'explicit paths'\n> case.\n\nYes. It's fixable, but IIRC the current script is fairly broken; I'd\nhave to look at it again to remember why, but I think I wrote it to a\ncomment inside there somewhere.\n\nIt would be cool if someone would fix it, of course.\n\n> For the 'whole tree' and subpath cases it _is_ tricky, and would\n> be faster to solve within git, but not impossible.\n> \n> And even then, I am tempted to think that git log could provide some\n> better hints than it does today when walking the whole tree or\n> subpaths, so that cg-log or gitk can ask [if relevant] for selective\n> rename info.\n> \n> I am curious as to why you see it as bad design...\n\nExactly because this information is really something core Git should\nprovide, and I'm feeling bad for not pushing this kind of functionality\nto core Git and instead going at lengths implementing it in Cogito.\n\nThe conceptually proper solution I'd imagine is\n\n\thttp://news.gmane.org/find-root.php?message_id=<20060515203700.GB4497@c165.ib.student.liu.se>\n\n(I didn't look at the actual code though), currently in limbo and\nwaiting for someone to fight for it. :-)\n\nOTOH doing it in a filter simulates greatly how powerful the Git's\npipeline architecture is, and has certain undeniable cool factor\nassociated. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i