I know - openserver, yuch, bla bla bla... Not my choice, but sometimes we have to do things we don't like... But, I've come across this in strbuf.c: va_start(ap, fmt); len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap); va_end(ap); if (len < 0) die("your vsnprintf is broken"); Now, that would seem to be the interpretation of vsnprintf I'm familiar with too, but I read this in the SCO vsnprintf man page: snprint...

Hi, I've been trying to convert an existing git-svn clone to noMetadata (i.e. get rid of git-svn-id in the commit messages), primarily because I've been using it to track two SVN repos which were originally just a single repo-- they have the same UUID but are located on different machines, and have branched significantly, so content-wise are no longer the same repo. Because the two repos have a single line of commits which they share, it would be best if I could store that history in my git re...

Try this in your favorite git repo: git clean -n / Here, it responds with: fatal: oops in prep_exclude I don't know what the expected behavior should be, but certainly not this. Maybe just do nothing like 'git ls-files /'. I'm not familiar with either builtin-clean.c nor dir.c; perhaps someone else can fix this? -- Hannes -

I know it's an absolute path, but, no, I said git clean -n \*.vcproj on Windows, which the MinGW port internally transforms into git clean -n /*.vcproj (which was not exactly what I meant, but that's a different story). And this also reports, just like on Linux: fatal: oops in prep_exclude There remain the questions whether we want to do something about absolute paths in general or this oops in particular. -- Hannes -

Hi All, I have an source directory, which in turn has some other directories too. I do not want to track one of these directories. So i added the directory name in .gitignore as well as in .git/info/exclude for my repo. i.e i have added following line to both of them - xen-3.1.0-src/ I copied xen-3.1.0-src from archives in the git repo's base directory. Now when i do a git-status i get # On branch master # Untracked files: # (use "git add <file>..." to include in what will be comm...

Apologies to all.Kindly pardon my novice experiments with git. Some more trial and error method led to find that you have to put a * at the end of the directory too. i.e xen-3.1.0-src/* But i still would like to ask git gurus here. Isn't it fine to include a directory name as $directory_name/ instead of $directory_name/* ? Thoughts? Thanks, --Pradeep -- -- pradeep singh rautela http://eagain.wordpress.com http://emptydomain.googlepages.com -

I've got the following change in my "pu" right now and am considering adding it to git-gui 0.9.2, which would be in git 1.5.4. I've CC'd a number of people who have emailed me in the past about git-gui's diff or blame failing to display a non US-ASCII file content correctly and I am interested to hear if this would resolve the issue for you. Its configurable on a per-path basis by an "encoding" attribute in .gitattributes (see git-gui's own example below). If we go this route we'll also want to...

Hmmm. At least for now in 1.5.4, I'd prefer the way gitk shows UTF-8 (if I recall correctly latin-1 or other legacy encoding, as long as LANG/LC_* is given appropriately, as well) contents without per-path configuration without introducing new attributes. -

For example LaTeX files either use inputenc package to set encoding (e.g. \usepackage[latin2]{inputenc}) or use magic first line to specify TCX (TeX character translation) file (e.g. %& -translate-file=il2-t1). Emacs encourages to use file variables, either in the form of magic first line, or file variables at the end of file; I think the same is true for Vim. I'd like then for it to be at least as configurable as diff.*.funcname We can at least try to and check for UTF-16 magic firs...

Good idea. I've often needed this myself, without consciously realizing it -- my bash is set to save an infinite amount of history, so Ctrl+R always helps me out ... Will whip up, unless someone beats me to it. It's getting sorta late, so I won't have time for at least a day or two. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle -

One thing I'd like somebody to check: what _does_ happen with OS X and NFS (OS X as a client, not server)? In particular: - Is it suddenly sane and case-sensitive? - Does the NFS client do any unicode conversion? I tried to google for it, but didn't find the right keywords to get anything useful out of that modern-day internet oracle. Linus -

There must be something at the VFS layer, or some other layer: - IIRC, Joliet iso9660 volumes end up being mounted with files names in NFS when the real file names are NFC on the disk. - Likewise for Samba shares. - When I had my problems with iso9660 rockridge volumes using NFC (you can create that just fine with mkisofs), the volume is mounted without normalisation, i.e. if you get to a shell and want to access files, you must use NFC, but at least the Finder does transliteration at some ...

Simple : on a Linux host, create files with NFC names, and create an iso image with mkisofs, with rockridge but no joliet. Burn this to a disc, and insert the disc in your OSX host, and try to open files from the finder. Interestingly, IIRC, Finder is able to copy the files, though. As a bonus, try the same with an iso volume name in NFC, it's even better : the created mount point is NFD, but it tries to mount on the name in NFC and fails. And then you just can't eject the CD anymore. Mike ...

Wait, did you tell us some time ago that normalization does not matter and you just need to treat strings "as text"? Now, it looks like the Carbon stack does not treat strings "as text". How come? Maybe, you should stop lying and admit that changing Unicode On Windows, you can create two *different* files -- one with NFC and the other with NFD name. I wonder, how it is going to work with your renormalization back and force. Dmitry -

Here's a reliable test case to test filename normalization on Mac OS. ------ cut here ------- cat > test.pl << EOF #!/usr/bin/perl -CO print "M".pack("U",0x00E4)."rchen\n"; print "Ma".pack("U",0x0308)."rchen\n"; EOF chmod +x test.pl ./test.pl | xargs touch echo M* | xxd -g1 ------ cut here ------- On an NFS mounted filesystem, what you will get is this: 0000000: 4d 61 cc 88 72 63 68 65 6e 20 4d c3 a4 72 63 68 Ma..rchen M..rch 0000010: 65 6e 0a ...

Well yes, any context in which a string is treated as Unicode instead =20= of an opaque sequence of bytes will probably lead to normalization at =20= some point (e.g. when searching text, I'm going to want M=E4rchen and =20= M=E4rchen to be treated as the same string). The Mac OS X APIs use NFD, =20= Why would the globbing libraries have to do anything special to =20 understand NFD? In fact, I prefer that they don't - it's very handy to =20= be able to type Ma* and have that match M=E4rc...

How about this: it's lossy. It's lossy in a similar sense that TIFF -> JPEG -> TIFF doesn't give you back exactly the same bytes, even though (modulo the compression level) the two TIFFs might be visually indistinguishable. You seem to have an issue with calling this "corruption", but to most of us, if you have a system where you don't get back *exactly the same data* that you put in, then the data has been corrupted. Now, please stop trolling this point, agree to disagree, and either co...

Well "touch" actually since that was what was actually creating the files; I only used perl because it was easist way to gaurantee exactly It's worse than that. You can specify at format time whether or not HFS+ does case-sensitivity or not, and of course, there is UFS, which I expect does no Unicode normalization at all, much like NFS. I suspect what you've pointed out is why certain MacOS programs break horribly when run on non-HFS+ filesystems, though. And if that is the case, then those sa...

0000000: 4d 61 cc 88 72 63 68 65 6e 0a Ma..rchen. -

NFD, you mean ? Mike -

Ok. That's going to make it both easier and harder for them in the future. In particular, it probably means that their VFS layer really has no notion of this at all, and it's going to be fairly hard to support any kind of I wouldn't hold my breadth on ZFS, considering the memory requirements. ZFS apparently wants *lots* of memory: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#ZFS_Administra... http://wiki.freebsd.org/ZFSTuningGuide in fact i...

-Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com

Yes. Similarlty with UFS partitions. After much grief with case-insensitivity on OSX I reinstalled the OS on a UFS partition, only to find that most 3rd party apps can't cope with case-sensitive Don't know, unfortunately. I suspect both bits of mangling happen in the fs code. martin -

Uh, Ted is a filesystem developer. I can't count the hours I spent talking with my father, a theoretical physicist, but that does not make me qualified to consider myself a better authority on physics than a sub-average actual grad student of the matter. If you don't manage to check your arrogance eventually, you'll be causing more damage to your cause than if you just shut up. You make abundantly clear that you don't understand the _implications_ of the details you may or not may happen to fin...

Don't ruin it. You were silent for 12hs and lots of patches and research on the problem started flowing. If you keep making a nuisance of yourself, people will turn from helping you to beating you up for being so annoying. Perhaps help prepare those tests you said it was a good idea to work on. If you manage to stay silent a bit, we'll need them soon ;-) m -