Re: Libify puzzle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 07, 2006 at 12:00:02PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> I was just thinking a bit about teaching git-blame about renames, and hit 
> a problem: When rev-list stops because none of the parents has the file of 
> interest, the program should look if the parents contained a similar file 
> which got deleted. But the commit's parents were explicitely culled!
> 
> The problem seems to affect more programs when we try to libify them: What 
> used to be a pipe between two programs, can no longer just set 
> save_commit_buffer = 0 in the first stage, since the second might depend 
> on the buffer.
> 
> Would the correct solution be something like reparse_commit(commit)?
> 

I have started on the rename support for git-blame but it isn't
working code yet.

My idea is to change the revision.h interface a bit. Instead having
the pathname pruning hard-coded in try_to_simplify_commit as it is
today we could have a pointer to a function in the rev_info structure
which is called the same way as try_to_simplify_commit is called
now. Then users of the revision walking interface could populate the
rev_info structure with their own try_to_simplify_commit-like
function. In the case of git-blame that function could then do the
appropriate rename detection.

Thoughts/comments?

- Fredrik
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]