Re: gitweb wishlist

["H. Peter Anvin" <hpa@zytor.com>]

David Mansfield wrote:
> 
> Ok.  I'll tell you.  It means that the committer uses bad practices in 
> tagging ;-)  It generally means that force tag (cvs tag -F <file>) was 
> used on a specific file.  Here's the scenario:
> 
> cvsps is trying to associate a tag to a specific commit.  But in the cvs 
> world this is not always at all possible.  If, for example, a commit 
> made and  all files are tagged.  Now some random file is modified and 
> committed.  Then, a bug is found in a file from the previously tagged 
> set, say the file 'memdisk/init32.asm'.  The bug is fixed, committed and 
> the tag is MOVED for _just that file_ forward to the new version.  Now 
> there is no commit that can be associated with the tag.  In this case, 
> cvsps believes this to be a 'FUNKY' tag.  There is a more pathological 
> case having to do with 'INVALID' tags...  It's enough to make a grown 
> man cry.
> 

This is only pathological if the tag now represents a state that never 
actually existed in the history of the repository.  I don't believe 
there are any such cases in the syslinux repository; I could be wrong, 
but I am *highly* sceptical.

> 
> I accept patches ;-)  Honestly, handling binary data should be trivial I 
> just haven't had the interest, and surprisingly noone else on the 
> internet ever has.  The only binary file in the kernel appears to be the 
> logo.gif, according to Ingo.
> 
> [ discussion on working around broken handling of binary files in cvsps]
> 

Actually, as long as we can create the tree that exists between each 
changeset, we should be OK.

> 
> Hey, a polished turd is only so shiny...  cvsps is a 99% solution [to 
> the problem of extracting metatdata from cvs] only and cvs makes the 
> other 1% impossible.
> 

No sh*t...

	-hpa