Thanks, I just did a similar patch to transport.c: $ diff -u ../git-1.5.4.2/transport.c.orig \ ../git-1.5.4.2/transport.c @@ -456,7 +456,8 @@ if (transport->remote->http_proxy) curl_easy_setopt(slot->curl, CURLOPT_PROXY, transport->remote->http_proxy); - + curl_easy_setopt(slot->curl, CURLOPT_PROXYAUTH, (long)CURLAUTH_NTLM); + curl_easy_setopt(slot->curl, CURLOPT_PROXYUSERPWD, "<user-id&...

Hi, I think that GSoC2007 was quite nice for us. And with what we learnt, we would do even better in 2008. However, I simply do not have the time to serve as primary contact. I am willing to be mentor again, though. As for projects, I imagine that Gitorrent, further builtinification and Windows support would be good candidates. Ciao, Dscho -

test-lib used to set it to ".git/config" until recently, so this would have been a no-op. As to why it was ever in here, I have no idea. -Peff -

First, you should rather allow any auth and not just the specific one you want. Then, the userid and password is probably better passed in embedded in the proxy URL as that's given on the command line/environment already. Or as Well, the CURLOPT_PROXY is set in transport.c as well which your patch didn't address. If that's the case, I figure the verbose output should've shown some auth failures with the proxy? -

I'm unsure if this is a "problem" with git but the associated error/warning messages can be concerning to uninitiated users. It occurs when someone starts a clone and someone else does a push while the clone is processing. In 1.5.3.8 we are seeing the following messages after the clone completes (the push was to the b2 branch): ===== jwilliams> git clone /nfs_share/repo.git my_clone.git Initialized empty Git repository in /export/jwilliams/test/my_clone.git/.git/ 5294402 blocks Checking ...

What I meant to say was we have tried to stick to "test -d" or "test -f" and avoided a newer "test -e" when able. It's not a style but more about courtesy to porters. Majority of platforms I did not mean to imply I was presenting the whole solution; I was trying to hint at a different direction which may or may not work. I did not look at what test_create_repo() actually did when I wrote the message, but you are right. It too needs to be made conditional, and when trying an installed version,...

I suspect "uninstalled" cases (both "here" and "elsewhere") needs to do the template magic, while "installed" case should be I have them in ./+denv and after building if I want to see it work in real repo elsewhere I do: : gitster; sh $ . ./+denv $ cd ../elsewhere.git $ do the real workload trial Yeah, sounds like it. -

Yeah, it sounds like a plan. -

Basically, you solve the conflict, refresh the current patch and continue with 'stg push' or 'stg goto <top patch>'. The 'rebase' command does 'pop --all', 'git reset', 'push --all'. In your conflict, the base of the stack was already changed to the latest and hence only push/goto is needed. To fix it: $ vi files # or simply use 'resolved -i' below $ stg resolved -a [-i] $ stg refresh $ stg goto top-patch or (if you want to skip that patch): $ stg push --undo $ stg push next-patch...

You could always make it work like this: * If an address is given on the command line, use that. * Otherwise, if an address is given in config, use that. * Otherwise, look up the address at the remote repo; if successful, use that. * Otherwise, prompt the user. The advantage of this is that if the submission address changes (but the remote repo URL hasn't), then patches can automatically go to the right place. Of course the disadvantage is that the config is not initialized for off...

right. afaik no commands read the remote git config atm, but it might be true. what annoyed me is that i needed net access to generate the file, ie i was not able to do a 'darcs send -o file', copy the file to an usb but that's the case for git as well :) you should tell people (for example): use "git format-patch origin"; send the created *.patch files and use "git pull --rebase" to avoid an unnecessary merge. - VMiklos

Yes. Except for where the end result is! That's kind of the point. If you're developing a driver, your tree is the "driver tree". But if you keep pulling from me, now it's no longer a It probably depends on the submaintainer. But you're absolutely right that at least early on, most of them will want just emailed patches. And for that, the "fetch + rebase" model is the better one. HOWEVER. What happens with me is that I personally prefer patches from people if - they are "single"...

Hi all, When I commit to git, the log shows the correct timezone: Date: Tue Feb 26 23:10:24 2008 +1030 However, when I then dcommit this to SVN with git-svn, the timezone gets mangled. If I now 'git log', the same commit shows Date: Tue Feb 26 12:40:24 2008 +0000 The 'svn log' of that same revision shows the correct timezone: r151 | foo | 2008-02-26 23:10:24 +1030 (Tue, 26 Feb 2008) | 2 lines so, I know it's git-svn doing it, not svn itself. The same mangling has happened to commits...

From: Petr Baudis <pasky@ucw.cz> This patch does a couple of things: * Makes commit/author/committer search case insensitive To be consistent with the grep search; I see no convincing reason for the search to be case sensitive, and you might get in trouble especially with contributors e.g. from Japan or France where they sometimes like to uppercase their last name. * Makes grep search by default search for fixed strings Since we will have a checkbox. * Introduces 're' check...

Change order of parameters in parse_commits() to have $filename before @args (extra options), to allow for multiple extra options, for example both '--grep=<pattern>' and '--fixed-strings'. Change all callers to follow new calling convention. This is part of commit b98f0a7c in http://repo.or.cz/git/gitweb.git gitweb: Clearly distinguish regexp / exact match searches by Petr "Pasky" Baudis. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Jakub Narebski <jnareb@gmail.c...

Hi I recently converted a set of patches to a git repository. In order to use the correct timestamps my script used a 'faketime' solution I found here: http://www.code-wizards.com/projects/libfaketime/ I used a perl subroutine that takes a time (obtained by stat()ing the original patch or looking in logs) and then the normal 'system()' args. sub faketime_system { my $time=shift; $ENV{"LD_PRELOAD"}="/everything/devel/faketime/libfaketime-0.6/libfaketime.so.1"; $ENV{"FAKETIME_FMT...

Depends. after checking the git pages for time arguments then spoofing the time is (was!) the most obvious way to do it IMO :) Indeed - I forgot all about those - and I wrote the first versions of those files IIRC! The variables are not written about much more and didn't show up when I was googling for managing git timestamps/dates. Maybe they will now. And - the whole point of the email was for the archives - so thanks for the reply and the reminder/better suggestion. David -

I sent the series directly based on master, as Shawn suggested (21c34 is only changing the prefix in Makefile): 3c5fb6a798a0b686e7818bf1da63791fb94a7b21 receive-pack: use strict mode for unpacking objects 786bf704ce4067c80055a1fa69be242a59880eb0 index-pack: introduce checking mode 1f7ae754550fb6e0509c1498ba9de6b5f4bba438 unpack-objects: prevent writing of inconsistent objects 143aa20e11c70595e4119a3adac0887446524c7f unpack-object: cache for non written objects 997a515fccb3ef200cb96fbb757366eff8a2ee66...

I call it --long for longformat, maybe --longformat, --always-long, Me too. Santi -

I wrote up a --verbose patch, but it just seemed silly. Who would actually turn it on? How about this instead? -- >8 -- pack-objects: show "using N threads" only when autodetected Every other case is uninteresting, since either: - it is the default of 1, in which case we are always just printing "using 1 thread" - it is whatever the user set it to, in which case they already know But with --threads=0, they might want to be informed of the number of CPUs detected. --- If...

False alarm. It seems to be Ok. -

A non-empty line containing no spaces should be treated by --parseopt as an option group header, but was causing a bus error. Also added a test script for rev-parse --parseopt. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> --- e.g. % printf "foo\n--\noption-group-header\n" | git rev-parse --parseopt -- -h Bus error Wasn't sure whether to add the --parseopt test to t0040-parse-options.sh or t1500-rev-parse.sh. I ended up creating a new test script. Hopefully calling it out will increa...

On Tue, Feb 26, 2008 at 6:26 AM, Johannes Schindelin For your entertainment only, the OS X crash log. [Please don't make fun of me for using tcsh, I'm been meaning to switch to bash for about 10 years now. :-) ] Process: git [86324] Path: /opt/git/bin/git Identifier: git Version: ??? (???) Code Type: X86 (Native) Parent Process: tcsh [80929] Date/Time: 2008-02-25 23:05:42.717 -0500 OS Version: Mac OS X 10.5.2 (9C31) Report Version: 6 Ex...

Hi, I thought that we had that already in the man page, but you're right: we Yes, makes sense. Ciao, Dscho -

Leftover debugging? -