From: Petr Baudis <pasky@suse.cz>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [ANNOUNCE] Cogito-0.18.2
Date: Fri, 17 Nov 2006 02:58:06 +0100 [thread overview]
Message-ID: <20061117015806.GE7201@pasky.or.cz> (raw)
In-Reply-To: <46a038f90611161744q6c535218n5b815ef1fc5228b6@mail.gmail.com>
On Fri, Nov 17, 2006 at 02:44:47AM CET, Martin Langhoff wrote:
> On 11/17/06, Petr Baudis <pasky@suse.cz> wrote:
>
> >* cg-log does not follow history across renames anymore; it never really
> > actually worked and was instead causing problems and random error
> > messages. There needs to be git-core support for this funcionality,
> > hacking it with a perl filter is bad design, so I'm not going to fix
> > the filter (but I'd take patches if someone else did ;).
>
> I was looking at the follow renames Perl script last week (hey, I was
> bored!) and while I could tell it didn't work, I did get the feeling
> that it wasn't an impossible task, at least for the 'explicit paths'
> case.
Yes. It's fixable, but IIRC the current script is fairly broken; I'd
have to look at it again to remember why, but I think I wrote it to a
comment inside there somewhere.
It would be cool if someone would fix it, of course.
> For the 'whole tree' and subpath cases it _is_ tricky, and would
> be faster to solve within git, but not impossible.
>
> And even then, I am tempted to think that git log could provide some
> better hints than it does today when walking the whole tree or
> subpaths, so that cg-log or gitk can ask [if relevant] for selective
> rename info.
>
> I am curious as to why you see it as bad design...
Exactly because this information is really something core Git should
provide, and I'm feeling bad for not pushing this kind of functionality
to core Git and instead going at lengths implementing it in Cogito.
The conceptually proper solution I'd imagine is
http://news.gmane.org/find-root.php?message_id=<20060515203700.GB4497@c165.ib.student.liu.se>
(I didn't look at the actual code though), currently in limbo and
waiting for someone to fight for it. :-)
OTOH doing it in a filter simulates greatly how powerful the Git's
pipeline architecture is, and has certain undeniable cool factor
associated. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
prev parent reply other threads:[~2006-11-17 1:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-17 0:49 [ANNOUNCE] Cogito-0.18.2 Petr Baudis
2006-11-17 1:44 ` Martin Langhoff
2006-11-17 1:58 ` Petr Baudis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061117015806.GE7201@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=martin.langhoff@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).