hoi :) I hacked a little bit in gitweb so that it can get the project path form the URI without using a ?p=3D parameter. That is, you can now use "http://.../cgi-bin/gitweb.cgi/path/to/project/" to show the summary of your project. Together with a apache configuration like below, you can give your gitweb pages the same URL as your repositories: <VirtualHost www:80> ServerName git.hostname.org DocumentRoot /pub/git RewriteEngine on RewriteRule ^/(.*\.git/(.*\.html)?)?$ /usr/l...

It cannot be assumed that the given buffer will never be moved when shrinking the allocated memory size with realloc(). So let's ignore that optimization for now. This patch makes Electric Fence happy on Linux. Signed-off-by: Nicolas Pitre <nico@cam.org> --- I can't tell if that fixes it on BSD and Cygwin though. diff --git a/Makefile b/Makefile diff --git a/diff-delta.c b/diff-delta.c index c618875..25a798d 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -199,7 +199,6 @@ st...

No. The initial allocation assumes a perfectly even distribution of entries in which case the entry array would be all populated. When there are repeated bytes then consecutive blocks will have the same hash, and in that case keeping only the first one is useful. Which means that the entry pointer won't get to the end of the allocated space for all entries and I naively assumed that using realloc would only mark the allocated memory as smaller than it originally was without actually c...

Yes, ptr points to the last byte of the window for given hash value. This is so because in the matching loop the window is scrolled byte by byte and the new hash value is always made of ROBIN_WINDOW-1 bytes which already have been processed (most probably added as literal bytes in the delta buffer) plus one new byte. So it makes sense to start forward byte matching only from that last byte to find the longest source area to match, especially since all the other bytes in the window are like...

Actually, no, you got that part right. Mea culpa. It really only ended up being a problem when the area was moved, since the pointers into that area weren't updated. The alignment issue is real, but looking at the different structures, they'll all have pointers that end up being the real (and only) alignment constraint, so as a result, on any reasonable machine they all have the same alignment and things are fine. Junio - pls apply Nico's patch asap. It's correct, and fixes a really ...

If there would be possible to use external grep (like one can use external diff), then lack of some options wouldn't matter. -- Jakub Narebski Warsaw, Poland -

They have seen some limited use in-house -- we don't use Eclipse in-house that much, but that has been the test target. I am currently looking for a machine with good bandwidth to a backbone and cycles to spare where we can run anon cvs access to Linus's kernel.git repo. cheers, martin -

Tonight's latest (f7a3276) merged Nico's delta patches that was in "next" branch for some time, so that is what I would suspect first. commit 06a9f9203570d21f9ef5fe219cdde527dcdf0990 Author: Nicolas Pitre <nico@cam.org> improve diff-delta with sparse and/or repetitive data commit 2d08e5dd730680f7f8645a6326ec653435e032df Author: Nicolas Pitre <nico@cam.org> tiny optimization to diff-delta commit 3dc5a9e4cdcc7124c665a050547d1285d86a421f ...

When linking with Electric Fence I can reproduce the segfault on Linux as well. Looking into it now. Nicolas -

T24gNS8xMC8wNiwgTmljb2xhcyBQaXRyZSA8bmljb0BjYW0ub3JnPiB3cm90ZToKPiA+ID4KPiA+ ID4gSnVuaW8+IFRoaXMgd2VlaydzICJXaGF0J3MgaW4iIGlzIGEgZGF5IGVhcmx5LCBzaW5jZSBJ IGRvIG5vdCBleHBlY3QgdG8KPiA+ID4gSnVuaW8+IGJlIGFibGUgdG8gZG8gbXVjaCBnaXR0aW5n IGZvciB0aGUgcmVzdCBvZiB0aGUgd2Vlay4KPiA+ID4KPiA+ID4gSSBqdXN0IGdvdCB0aGlzIHdp dGggdGhlIGxhdGVzdCwgb24gdGhlIGdpdCBhcmNoaXZlLCB1c2luZyBnaXQtcmVwYWNrIC1hOgo+ ID4gPgo+ID4gPiBHZW5lcmF0aW5nIHBhY2suLi4KPiA+ID4gRG9uZSBjb3VudGluZyAxOTE1MSBv YmplY3RzLgo+ID4gPiBEZWx0aWZ5aW5nIDE5MTUxIG9i...

It is problematic but not more than the current index + "Binary files differ" output. If you have both pre and postimage then you do not need the binary data. The forward application is done assuming you have the preimage (but not necessarily postimage), and when you do not have postimage the binary data is used. When going reverse we should assume you have the postimage (but not necessarily preimage), but the pack-object format xdelta is not reversible so if you do not have preimage that matc...

Btw, I don't actually know why we don't support "-R". The way git-apply is written, it should be totally trivial (just switch old/new around for data and line numbers - since it doesn't actually apply the patch directly line by line or anything like that) for a normal patch. So if I read the binary patch right, the lack of "-R" went from "silly oversight" to "uhhuh, I don't think the patch format supports it". Maybe it's not a big deal. Linus -

Sure. It clearly _is_ a bike shed, which is why I posted patches: I think the way to resolve bike sheds is to "just do it". In the kernel, the general rule ends up being "he who writes the code gets to choose how it gets done", because it turns out that there are a lot more people willing to _argue_ about code than there are people willing to _write_ it, and thus that "real code wins" rule actually works very well in practice. I don't think I've ever really seen an argument where you ende...

I think we can do better in a few pretty important regards: - having the information in one place. I agree that the multi-file approach works fine for shell scripts (although I disagree that the new one would be harder - you just use git-repo-config instead), but I think it's quite confusing from a new user perspective. I bet that even without any tools, new users can be told to just open ".git/config", and guess how hard a time they would have to add a new branch, i...

As you say, this needs to be explained/exposed better to the user. Now, how about having one .git/config and one .git/branches file? Agreed, but I suspect repo config and branches config travel at different speeds. Maybe what this means is that if this happens, we'll start seeing a need for ~/.git/config and /etc/git/config to set defaults (merge.summary=1 for all my repos, core.sharedrepository=1 for all the repos on this server) where I now I just mostly copy .git/config around. Must be ...

Hi, Depends on how you look at it. A bunch of files is okay for quick-n-dirty, where you do not care about locking or consistency or extensibility. Ciao, Dscho -