[Don't have Cc: in KNode. oh well...] Thanks a lot! This would become a gigantic patch, which I really dislike. It's much easier The custom lstat() implementation cannot come after the custom struct stat because we can't call Windows's stat() with a custom struct stat. But I also don't want the custom lstat() in the code from the beginning because I strongly disagree. The series is completely bisectable on *nix. But if the Doesn't this go too far? How many systems are there where no...

If you expected it, you should have added the above four and half lines in the initial message. cgit is something even I have heard of, and breakage of it because of what we have is worth taking into consideration. It would have been nicer if Instead of wasting more time in the exchange in this thread, I spent a several uninterrupted minutes' attention to read over your patch to make sure there is no accidental slippage (with help from Dscho as well). I'll make an exception and will apply. ...

We now open and do one conditional per line for each file (in addition to already going through each file a separate time and doing more complex processing). Doing that over the entirety of "git log --pretty=email -p" on git.git takes about 1 second on my machine for 11402 patches. Obviously there's slightly more syscall overhead as you have to open() each patch, but I think think it is clear that the Perhaps. If such things are sufficiently rare, one could simply attach the patch in their MUA....

Errr... doesn't UTF-16 (as compared to USC-2) sometimes (for some exotic characters) require more than two bytes per character? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Actually, we could (and probably should) teach git-submodule not to fetch if the requested SHA1 is already available in the submodule, and I guess this would solve the problem quite nicely for your usage. But that will probably not happen before 1.5.4. -- larsh -

Hi list, there is another nit which annoys me in gitk. Besides the fact that the maximize button (the green `+' button that is part of Apple-style windows) does not do anything, I can't maximize the window on a 2nd screen even if I try manually. Wild guess: I can't make the window bigger than the maximum area usable on the main screen of my MacBook (max area = screen resolution - area used by the Apple menu - (dock hides automatically ? 0 : min size of dock)). Whether this is a bug i...

I do not particularly like hooks that act before or after an operation is initiated locally, act solely on local data. This is maybe because I still consider git tools building blocks suitable for higher level scripting more than other people do. There are five valid reasons you might want a hook to a git operation: (1) A hook that countermands the normal decision made by the underlying command. Examples of this class are the update hook and the pre-commit hook. (2) A hook that ...

It is, but quite a powerful one. :-) template-commit-msg? Paolo -

Hi, Would it not be much better for that hook to verify that the template has not been added? Or would not be yet even better to use the commit.template config variable, which was intended for that purpose? Ciao, Dscho -

Hi, What I meant is this: In the message hook, just grep if the template was already added. If it was, just return. If it was not, add it. No need for yet another hook. Ciao, Dscho -

Hi, No, my intention was to avoid complications. Like introducing yet another commit hook. I like clean, elegant semantics. I don't like overbloated semantics. That's why I speak up whenever I fear it is entering git. Hth, Dscho -

Do you think my three line patch is too complicated? Possibly I was too zealous in documenting the semantics for the new hook and that looked like unelegant semantics. Do you have another possibility which allows the same workflow (git commit shows the output of that script) within the existing framework? Paolo -

Yes it should. Nicolas -

I believe so too. And nowadays there's "git gc --auto", which was made for occasions such as this, so it should be a breeze to implement. The overhead might be low enough that it can be called after _every_ imported revision. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle -

I can ACK this as fixing the test suite failures on Mac OS X 10.4.11 both with and without NO_MMAP=Yes on top of 1.5.4.rc3.24.gb53139 and also on my oldish Fedora install with NO_MMAP=Yes. Acked-by: Charles Bailey <charles@hashpling.org> -

Sorry, I thought that Acked-by was an acceptable tag for people not involved in the development path of a patch. I don't want to add a "Tested-by" as I am not a fast-import user and I am *only* reporting the success of the test suite, not any real-world testing. Charles. -

Hello, I am working agains a linux kernel net git repository. It occurred to me more than once that when trying to git-pull a repository I get the following errors; there errors appear also after I am running "git-reset --hard". Any idea what can it be ? I must add that I did not made changes in my local copy of the repository. the command I am running is: git-pull git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.25.git Here are the errors I get: mygateway:/work/src/2.6....

Thanks a lot. It works here on Windows, too. -- Hannes -

Cygwin does not yet support doing the smart thing. At the moment you can only open() files in the current 8 bit codepage. There is a patch floating around to allow using UTF-8, but it was rejected for inclusion because it was considered too hackish. Instead work has been ongoing for some time to replumb the internal representation of Windows filenames to use UTF-16 instead of plain chars, so that conversion overhead can be held at a minimum. In conjuction with dropping Win9x/ME support this als...

I've just checked the Mac OS X build and it looks like there is a mmap and git is indeed using it, so this is obviously an example of a "really crappy" mmap implementation. This adds more ammunition to the fight against the whole Mac OS X is powered/built/based on UNIX myth. Charles. -

Improbable effect on your health! http://eu.rxneall864.com -

Replace the "This manual page describes only the most frequently used options." text with the list of rev-list options in git-log manpage. (The git-diff-tree options are already included.) Move these options to a separate file and include it from both git-rev-list.txt and git-log.txt. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Yes and no. I generated the documentation, but I forgot to diff the I missed that one. Now should be fixed. Also there were other duplicated F...

Replace the "This manual page describes only the most frequently used options." text with the list of rev-list options in git-log manpage. (The git-diff-tree options are already included.) Move these options to a separate file and include it from both git-rev-list.txt and git-log.txt. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Okay, now using -C :) Also I removed the duplicated options from git-log.txt (--first-parent and -g) to avoid duplicated descriptions. Docum...

[Empty message]

Now, this moves option descriptions of git-log around for no good reason, other than that it was more convenient in the source. Which is not a very good excuse in general, but I do not think the original ordering was carefully designed to be optimal for the readers either, so let's take it. Thanks. -