If you mean this (from your strace): link(".git/objects/df/tmp_obj_cL0wfQ", ".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078") = -1 ENOSYS (Function not implemented) Note that it is immediately followed by: rename(".git/objects/df/tmp_obj_cL0wfQ", ".git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078") = 0 IOW, git tries the hard-link first, then falls back to the rename. If the rename also fails, git does complain. So I don't think that is your problem. I would guess ...

The implementation exposes an API to generate type-specific treap implmentation and various functions to operate on it. Taken directly from David Michael Barr's svn-dump-fast-export repository. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> --- vcs-svn/trp.h | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 221 insertions(+), 0 deletions(-) create mode 100644 vcs-svn/trp.h diff --git a/vcs-svn/trp.h b/vcs-svn/trp.h new file mode 100644 index ...

Create remote-svn.c, which is essentially a stripped-down version of remote-curl.c to build the SVN remote helper upon. Also add a Makefile rule to build it. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> --- Makefile | 9 ++- remote-svn.c | 201 +++++++++++++++++++++++++++++++++++++++++++++++++++ vcs-svn/svnclient.c | 20 +++++ vcs-svn/svnclient.h | 7 ++ 4 files changed, 236 insertions(+), 1 deletions(-) create mode 100644 remote-svn.c create mode ...

string_pool uses the macros in the memory pool library to create a memory pool for strings and expose an API for handling the strings. Taken directly from David Michael Barr's svn-dump-fast-export repository. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> --- vcs-svn/string_pool.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++ vcs-svn/string_pool.h | 11 ++++++ 2 files changed, 95 insertions(+), 0 deletions(-) create mode 100644 vcs-svn/string_pool.c create mode ...

repo_tree parses SVN revisions to build a Git objects, and use fast_export to emit them so they can be imported into the Git object store via a fast-import. Taken directly from David Michael Barr's svn-dump-fast-export repository. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> --- vcs-svn/fast_export.c | 61 +++++++++ vcs-svn/fast_export.h | 17 +++ vcs-svn/repo_tree.c | 333 +++++++++++++++++++++++++++++++++++++++++++++++++ vcs-svn/repo_tree.h | 31 +++++ 4 files ...

Ahh thanks!! Now I know the answer I can see that the docs say that (sort of) :) --

I want to ignore a particular file name in a particular directory. However, the same filename may appear in subdirectories and in those cases I do *not* want it ignored. The documentation seems to imply that git will read up the directories looking for .gitignore files and will ignore files that I need included. Have I misunderstood this and/or how can this be done. Any enlightenment appreciated! --

Aknowledge, An Iraqi business man made a huge deposit in my bank where am a director and he died with his entire family in the war leaving behind no next of kin, I'm ready to share with you if you choose to stand as my deceased client next of kin. If interested mail me at: mnghoyng@yahoo.com.hk Regards, Ming --

Hi Pavan, I'm late to this thread, but I'm leaning against forcing access logs onto people. I don't believe access logs are necessary for instaweb. Error logs are important for debugging breakage, yes, but access logs aren't worth the trouble IMHO. Also, using the same error log paths might make it confusing to people switching between web servers. In fact, it may be the most confusing for those folks if they're trying different web servers and forgetting to shut down the previous server ...

Well, Until before this patch, lighttpd and mongoose have been using the same error log and access log. So, I enabled it for apache2 too in the process of debugging git-instaweb while using apache2. IMVHO If there is no problem using the same logs for lighttpd and mongoose until now, I don't think it will be a problem when apache2 is included into that group. --

Hi Clemens, Without your patch applied, I get $ cd .git $ git --work-tree=/tmp/git symbolic-ref HEAD refs/heads/hello I should have done the following instead: $ worktree=$(pwd) $ cd .git $ git --work-tree="$worktree" symbolic-ref HEAD If I understand correctly, you made two changes here: - interpret GIT_WORK_TREE and friends relative to .git instead of the original cwd (by not calling chdir(retval) before get_git_work_tree()) - make setup_git_directory stay ...

Thanks a lot for your answer. That's what I was looking for :-) --

I had a similar experience - a colleague with a habit of making huge commits happily cleaned up his act when he was shown this. More generally, it seems like everyone reacts to the list of git features with "that one's weird, I don't care about that one, that one's irritating, WHERE HAS THIS BEEN ALL MY LIFE!, don't care about that one, that one doesn't make sense...". A major part of selling people on git is finding the one thing that they each immediately love. - Andrew --

Hi David, I'm quoting all your email with no cleaning here because I think you did not included the git mailing list as a mistake. I KNOW other will not share my view. Another team leader with more experience then me already told me that "moving to something different of subversion is of no interest to him because he don't want to learn something new"[1]. This happened during a random chit-chat when I casually asked: "what would you think about moving from Subversion to something more ...

Yes, .psgi file in the (Perl) PSGI/Plack world is, as I understand it, analogous to .ru file in the (Ruby) Rack world. PSGI/Plack was inspired by WSGI from Python world and Rack from Ruby world. There is no web server in Perl core, although probably HTTP::Server::Simple and HTTP::Engine comes close. Well, there is HTTP::Server::Brick inspired by WEBrick... Using PSGI/Plack (via wrapper around CGI) allows easily to serve gitweb's static files (stylesheet, images, etc.), gives ...

Your polling http_is_ready() function is fine, and really the only portable solution across all servers (and OSes). But if your webserver lets you run arbitrary code hooks after it binds the listen socket, what I do when writing integration tests is have it open a FIFO for writing. Adapted and abridged from the Rainbows! web server test suite, the following config snippet is from the config file for the Rainbows! web server: ---------------- rainbows.conf.rb ----------------- after_fork ...

On Sun, May 23, 2010 at 12:53, Eyvind Bernhardsen It is, sanity checks for broken user tools like these are unfortunately important for Windows adoption of Git. --

That's because you don't use (or work with people who use) editors that mangle line endings without asking. Modern versions of vi and Emacs don't do this, but the problem still exists in popular Windows editors. I don't have strong feelings about the need for this feature, but it has been requested so it's probably useful. That is correct, but "eol=lf" means that the file _should_ be LF-only in the repository. If it isn't, the repository is "corrupted". Such a file is marked as dirty when it ...

Sorry, I still can't reproduce with: mkdir repo && cd repo && git init mkdir subdir commit() { echo content >>subdir/file git add subdir/file git commit -m foo } commit; commit; commit; commit; commit git blame HEAD~3..HEAD~1 subdir/file >no-dash && git blame HEAD~3..HEAD~1 -- subdir/file >dash && diff no-dash dash && echo ok So there must be some difference between your setup and my test case. Can you give more details? -Peff PS I tested on ...

I think this is a good change. But it only covers the part where we translate CR -> LF when staging changes. With Eyvind's patches, if I understand correctly, it will be possible to convert files to have LF line endings. Such files will be translated from LF -> CR when adding changes. So if the file already has LF line endings, will this cause the same problem the other way around? Clemens --

Yeah, that works for me. I was hesitant to do it because I wasn't sure if other callers were relying on that behavior, but it looks like all This confused me at first, because those outputs should be the same, but now I see: the pretty %P does not respect history simplification, so you get the _true_ parent of b801d8b2b, and not the simplified one when limiting history to 'tig.c'. So yes, the rev-list version is better, because it at least realizes that tig.c has no parent. But I think ...

The is_url function and url percent-decoding functions were static, but are generally useful. Let's make them available to other parts of the code. Signed-off-by: Jeff King <peff@peff.net> --- There was some minor tweaking of the url_decode functions to be more generally useful. Makefile | 1 + http-backend.c | 59 +-------------------------- transport.c | 51 +----------------------- url.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ url.h ...

OK. Nobody else seems to be commenting, so I would go ahead and put Inline email is best, but I think an email attachment would be preferred to putting it on some out-of-band service (it's nice for the mailing list archive to have a record of everything). -Peff --