Re: gitweb wishlist
- From
- H. Peter Anvin <hpa@zytor.com>
- Date
- May 24, 2005, 03:39 UTC
- Message-ID
- <4292A1F2.7020606@zytor.com>
- In-Reply-To
- <4292A08A.5050108@cobite.com>
David Mansfield wrote:
Show 16 quoted lines
> > 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.
Show 8 quoted lines
> > 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.
Show 5 quoted lines
> > 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