This function used to call locate_object_entry_hash() _twice_ per added object while only once should suffice. Let's reorganize that code a bit. Signed-off-by: Nicolas Pitre <nico@cam.org> --- diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index 687b4b5..bc5f232 100644 --- a/builtin-pack-objects.c +++ b/builtin-pack-objects.c @@ -781,12 +781,19 @@ static unsigned name_hash(const char *name) static int add_object_entry(const unsigned char *sha1, unsigned hash, int exclud...

Hi, Just wondering if there is a canonical place to download the MinGW port of git for non-git users... ideally precompiled, since a lot of Windows users probably won't have MinGW installed? Or is the port too fragile for that, still? -hpa -

At least some MTAs (exim is the one I know for sure) can restrict -f usage to some users and deny it for others. Don't know how much this would really be a problem, but using -f unconditionally might be a bad idea none-the-less. Gruesse, -- Frank Lichtenheld <frank@lichtenheld.de> www: http://www.djpig.de/ -

Can't find anything in the archives. So either I completly suck at searching, or it is at least several months old, or you are hallucinating :) Gruesse, -- Frank Lichtenheld <frank@lichtenheld.de> www: http://www.djpig.de/ -

Weird mail header here: "Cc: junkio@cox.net, Robin@orbis-terrarum.net, H.Johnson@orbis-terrarum.net= , robbat2@gentoo.org" Looks like git-send-email didn't put the quotation marks around the CC address, so my MTA broke it up (and tried to expand each part locally). --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

This patch set is both a testcase, and a useful addition. Some mailing lists (git@vger included) use the envelope sender to determine is posts are allowed, and depending how use git-send-email, the envelope sender might not be the address that you are subscribed with! -

Is there a way for our tests to be a bit more stable than urandom? I saw on the first run fsck was OOM-killed, but the second and subsequent run did not. It's a bit hard to diagnose. -

Hi, just posting a very very minor thing, that anyway might be easy to improve... consider the following cases: 1) Empty repo mkdir Foo cd Foo git --bare init git --bare fsck error: HEAD is not a symbolic ref error: No default references Should this be an error...? Of course fsck is not happy: HEAD points to master, but master does not exist. However, the newbie might find it weird that git complains over a brand new repo it has just made. BTW also gitk dies badly in this case. ...

Hi Junio, I recently upgraded to 1.5.1, via tarball as usual, without much problem. The only problem being the "printf format warnings" issue, which prevents me building with -Werror. I have included, below, an updated version of my patch from the 1.5.0 series. We agreed last time that this patch is not the correct solution to this problem in general (but it works on cygwin!), so this is *not* intended for submission. I just wanted to document the problem. As before, I don't really have a soluti...

At least git-update-index should work. --- builtin-update-index.c | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/builtin-update-index.c b/builtin-update-index.c index 47d42ed..55c9f93 100644 --- a/builtin-update-index.c +++ b/builtin-update-index.c @@ -94,12 +94,10 @@ static int process_file(const char *path) path); } } - if (0 == status) - return error("%s: is a directory - add files inside instead", - path); -...

If I used to have a symlink S and now the filesystem has a file S/F which I am running "update-index --add --remove" on, what happens? If I have a subproject at path P, and mistakenly try to add path P/F with "update-index --add --remove P/F", it should be refused, shouldn't it? -

Hi Martin, I've seen this behavior when the server repo files don't have the same owner/group as the one you're running the server with. That happened to me after I edited the config files. Cheers, Emil. -----Original Message----- From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Martin Langhoff Sent: Tuesday, April 10, 2007 7:41 AM To: Git Mailing List Subject: Oddities cloning over http Cloning over http this repo, using git v1.5.0.5 and v1.5.1.106.g...

Hi, maybe I'm daft, or cogito has eaten my brain. The task at hand is really simple: clone from repo X, tracking branch Y (where branch Y != HEAD). The repo is http://git.catalyst.net.nz/git/moodle-r2.git , the branch is mdl18-olpc . With cg, this is trivial: cg-clone http://git.catalyst.net.nz/git/moodle-r2.git#mdl18-olpc which automagically gives me a "master" and "origin" pair of heads that do the right thing. Specifically, cg-update does the right thing. With git 1.5.x, I managed to...

thanks. And I'm reading the doco for 1.5.latest and it turns out I'm using 1.5.0.5 so that won't work either. hmmm. actually, I'm having another problem that is a bit more serious: cloning via http doesn't create a remotes/origin and doesn't perform the initial checkout. will post separately about this... martin -

They are already fixed in the master branch. At least the t9105 was a fix in the test suite. Santi -

Yes. It has cut down on our spam, but it has also caused some things to be blocked, almost without good reason. ;-) I send a fair number of patches to this list (at times anyway) and am also unable to use git-send-email. If I have the email also CC back to me it does make it through a number of SMTP server hops, including my own spam filters, but it never makes it through the Git mailing list. So I dump the patches to an mbox with --stdout, open them up in mutt and resend them there. I've bo...

I'm pretty sure the last time I tried git-send-email I had the MTA path exactly the same. My mutt sends to `localhost`, which forwards over an SSL channel to my colo'd spearce.org mail server, and that relays to the final destination. Hence spearce.org mail always originates from spearce.org. Now I ran git-send-email on a different system, but had it connect over SMTP to port 25 of the same system mutt runs on, so the initial Received line was different, but othewrise the mail path was the sam...

Ok, see my patch series for envelope sender, that is the source of the problem. --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Depending on your definition of "good". I run my mail server off my DSL line. I prefer having control over my mail server instead of being chained to what my ISP provides. (The problems of having been a sysadmin for way too many years.) I don't have control over the reverse ip address, but I do over my DNS resolution. (Well, most of it. A couple domains are sitting on really old dns servers Which makes Greylisting a useful tool. However, some people define a "real SMTP host" as being t...

That would be a very bad idea I think. Doing that would lose quite a lot of small companies and individuals such as me that run a mail server but are unable to get the ISP to change the reverse DNS. For example I do have a fixed IP, but have an reverse DNS pointer which looks like 1-2-3-4-5a.foo.bar.bostream.se. Forcing everybody to send mail through their ISP (and I'm not even sure if my ADSL subscription includes such a service) would be a big loss. First of all its a philosophical thing, ...

this isn't a problem. as long as you can lookup 1-2-3-4-5a.foo.bar.bostream.se. and get your IP address you pass this test. David Lang -

This replaces the inflate validation with a CRC validation when reusing data from a pack which uses index version 2. That makes repacking much safer against corruptions, and it should be a bit faster too. Signed-off-by: Nicolas Pitre <nico@cam.org> --- This completes the development for this patch series. I tested that this works as expected by manually corrupting a pack, etc. I intend to write real tests for this stuff of course, but at least the way should be completely clear for the...

Here is, for your enjoyment, the last patch I used to actually test this all. I do *not* submit it as a patch for actual inclusion - the other patches in the series are, I think, ready to actually be merged. This one is not. It's broken for a few reasons: - it allows you to do "git add subproject" to add the subproject to the index (and then use "git commit" to commit it), but even something as simple as "git commit -a" doesn't work right, because the sequence that "git com...

Note that I was definitely planning on adding them too, but they are at a higher level. So the long-term plan is/was to add a flag to "git diff" (and "git ls-tree" etc) to say "recurse into subprojects". You cound perhaps even make that flag the default with some .git/config option, if your superproject is small enough. But this series of 6 (and the seventh ugly hack) is literally meant for just the really core object-handling stuff, and even there it's not really complete. For ...

Well, unless it hits something like Junios 'pu' (or 'next') branch, or somebody (like you?) ends up maintaining a repo with this, it's just unnecessarily hard to have lots of people working together on it.. I'm obviously interested in working on it, but at the same time, I don't expect to be a primary *user* of it, so I'm hoping others will come in and start looking at it. It looks promising that you're getting involved, but I suspect you may be a bit too optimistic when you say "just ...