Yes. The problem is that you need quite a lot of parents. Every system I could come up with that got all the corner cases right was even more Yes. This is true for any log scheme, though. (But I agree -- longer You're right to worry. My log format makes things feel slightly slower when logging a 20-30 deep stack. If I can't make it faster, it's not viable. But I'm pretty sure I can -- it should be simple to reuse all the trees and blobs for the patches that weren't touched. ...

By generic I meant that it is easily extensible to store other blobs of whatever you need. As you say, a commit message could be extensible Remove them altogether. Is there anyone using them apart from me? I could create a "rotten" branch and pick those patches with It gets too complicated, really. A single commit with the proper parents could do the job. We could also easily use the commit message The time to create that tree and blobs worries me a bit, plus the (in my view) complicated ...

Having : in a filename is asking for trouble. I think the parser thinks [[: as in [[:alpha:]] and break the parsing somhow. This is possibly even undefined, Not trying to clean up got me into trouble with tons and tons of garbage, that is why I placed new repos in a directory and try to delete it if possible. That ofcourse excludes parallell runs. Anyone with a good idea on how to The patch constituents are somwehat loose. Would this rebase do? pick e331b13 Added the package fnmatch ...

Although git-svn keeps track of source revisions in svm-mirrored repositories, it doesn't use that information in all places. This fixes working_head_info and Git::SVN::find_by_url to work with mirrored repositories when useSvmProps is set. At least the commands find-rev and rebase, which didn't work for me with svm-mirrored repositories, are now working. --- git-svn.perl | 26 ++++++++++++++++++++++---- 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/git-svn.perl ...

Hi, It would not be by accident. It would work because we designed git-stash to use refs to store working-directory vs index changes, and this command line you wrote was _exactly_ what I intended. Ciao, Dscho --

Note that you would have to examine gitweb sources to check if it uses href(..., -replay=>1) when it should, so the links from "volatile" link, e.g. HEAD version URL, also lead to appropriate version, BTW. one of earliest idea was to fully resolve hashes, add missing parameters if possible (like 'h', 'hp', 'f') and convert hashes to sha-1. One of intended uses was (weak) ETag for simple HTTP caching. But it was before git-cat-file --batch-check, and ...

Many error status codes simply default to 403 Forbidden, which is not correct in most cases. This patch makes gitweb return semantically correct status codes. For convenience the die_error function now only takes the status code without reason as first parameter (e.g. 404 instead of "404 Not Found"), and it now defaults to 500 (Internal Server Error), even though the default is not used anywhere. Also documented status code conventions in die_error. Signed-off-by: Lea Wiemann ...

Hi, I would have reused local_tzoffset() and been explicit about the used date, but your version is shorter. Ciao, Dscho --

Hi, That is right, but for some stupid reason I did not realize that git-merge-file is not even called by merge-recursive. So the accompanying patch for merge-recursive would use the --theirs or --ours logic only in the !index_only case, i.e. the final merge. And I guess we'd have similar logic as for merge-subtree, introducing merge-recursive-ours and merge-recursive-theirs. Very nice. Ciao, Dscho --

Hi, Thinking about this again, there could be a problem: in case of complex merges, it is possible that the sides are switched around for an intermediate merge. IOW you'd expect it to take "theirs", but it really takes "ours". Hrm. Ciao, Dscho --

Nope. It is currently in the 'builtin-merge' branch of git://repo.or.cz/git/vmiklos.git. And I'm working on to be merged after 1.5.6 will be out.

The upcoming builtin-merge won't have this problem. I have added a testcase for this in my working branch: http://repo.or.cz/w/git/vmiklos.git?a=3Dcommit;h=3D7eef40b3cd772692c6eb7520= 686300533f35f10c

cool, thanks a ton! stupid question: does this mean that if i install the latest Git devel snapshot (v1.5.6-rc3-21-g8c6b578 or later), i'll be able to experiment around with it right now? Ingo --

Do you mean that the first patch rename-edits A to B, and then the second patch edits B in place? Because your fn_cache is keyed by postimage filename (in this case B), I would imagine that the later lookup of B should successfully find the patch result from the previous one. Unless the in_fn_cache() is somehow wrong... or do you mean that the first patch rename-edits A to B, but the second one still wants to edit A in place and you would want to pretend as if the later one is for a patch ...

Maybe using openat, fstatat, etc. when they are available, could be a good thing, already, though it wouldn't help for other platforms. Mike --

Hi, Just a typo here: s/eror/error/ Olivier. --

While I was running the whole test suite, your test cases randomly failed. I did not understand until I see the missing & here. ;-) Olivier. --

You'll need another patch for the decorator to pick up derived resources properly. Probably not the final solution to decorations. For one thing the I'd say implementing .git/info/exlude is the proper solution. The others are mere workarounds. -- robin From 7acc0e63886ed8eda6b38a5edbfe9a6aa4d509dc Mon Sep 17 00:00:00 2001 From: Robin Rosenberg <robin.rosenberg@dewire.com> Date: Wed, 18 Jun 2008 23:50:42 +0200 Subject: [PATCH] Decorate derived resources as ignored. This is done by ...

Hi, Firstly, thanks to all for the quick response. Hmmmm, is marking a resource as "derived" recursive? i.e. if I mark "output" folder as derived, would anything under it be considered derived? It'd be a pain to go a mark as derived each and every class. I suppose you still need the patch to use Team.isIgnoredHint to get Hmmmm, so the proper way is either marking resources as derived and use -- Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red ...

You're right, of course. I was hasty in my gmail, and was referring to http://article.gmane.org/gmane.comp.version-control.git/85337 when I made that comment. Anyway, I don't care enough either, especially since Junio claims to be "quietly rewriting git-stash in C". - Eric --

BTW, looking in my personal repo, I have the start of the exact same patch (except I called it PARSE_OPT_STOP_AT_UNKNOWN). I think I abandoned it when I realized the fundamental flaw with the approach, but I guess I never got it to the point of sharing with the list. -Peff --

Hi, AFAIR Pierre tried a few ways, and settled with a macro to introduce the diff options into a caller's options. IOW it would look something like this: static struct option builtin_what_options[] = { [... options specific to this command ...] DIFF__OPT(&diff_options) }; Ciao, Dscho --

This adds the PARSE_OPT_NO_ERROR_ON_UNKNOWN flag which prevents parse_options() from erroring out when it finds an unknown option, and leaves the original command and unknown options in argv. This option is useful if the option parsing needs to be done in multiple stages for example if the remaining options will be passed to additional git commands. Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com> --- parse-options.c | 25 ++++++++++++++++++++----- parse-options.h | 5 +++-- 2 ...

Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com> --- builtin-shortlog.c | 54 +++++++++++++++++++++++++++------------------------ 1 files changed, 29 insertions(+), 25 deletions(-) diff --git a/builtin-shortlog.c b/builtin-shortlog.c index e6a2865..b1087b5 100644 --- a/builtin-shortlog.c +++ b/builtin-shortlog.c @@ -7,9 +7,12 @@ #include "utf8.h" #include "mailmap.h" #include "shortlog.h" +#include "parse-options.h" -static const char shortlog_usage[] = -"git-shortlog [-n] ...

`p4 describes 114996' shows something like this: Change 114996 by puma@injoin.injoin on 2008/06/18 12:11:24 fix buffer overflow. Affected files ... //puma/Trunk/lib/string/map.c#47 edit But `git log' shows Author: puma <puma@p4_server> Date: Wed Jun 18 12:11:24 2008 +0800 fix buffer overflow. [git-p4: depot-paths = "//puma/Trunk/": change = 114996] The Author field in all logs shows puma <puma@p4_server> All of the programmers use the perforce username 'puma' ...

I sent out a code cleanup for remote.c yesterday that fixes a segfault: http://mid.gmane.org/20080616161502.GA7219@sigill.intra.peff.net I am OK if it doesn't make it in to 1.5.6, but if not, then we should at least apply the very safe one-liner that prevents the segfault. That patch is below. -- >8 -- fix segfault with "git push bogus:bogus" We try to guess the type of the dst half of the refspec based on the src half. If the src half is bogus, we ended up dereferencing ...

Hi Bruce Short version: 0. Using git on WinXP from http://msysgit.googlecode.com/files/Git-1.5.5-preview20080413.exe 1. When a proxy is required, the error message isn't very helpful: Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? 2. I can't get git config to set the proxy 3. When I use a shell variable, I can set the proxy, but I still have trouble cloning git over http. John. Long version: I'm back behind my proxy. I've ...

Patience please. When there is long series it *will* take time for a number of reasons. Most have nothing to do with this project at all. But in general you will find a short patch series *much* easier to get through than a long one. If you think my grouping is ok, then ack and I can commit from there. I --

Hi, I wrote the post below on the Apple Mac OS X Server mailing list, though not subscribed to that list, because I found a solution that I thought others might appreciate having documented, as I found it quite a bit of trouble getting it right myself. Though written for Mac OS X, the essentials apply to any Unix-like system. As the OP's problem arose when using Git, I thought perhaps some other Git users may appreciate the ideas as well, so I am forwarding this mail to you. If you think ...

Besides if I understand correctly gitweb very much requires Perl >= 5.8 because of required Unicode support. Nevertheless adding "use v5.8.0;" or "use 5.008_000;" would be I guess good idea. And best solution, although perhaps unnecessary, would be to check for version >= 5.8, if older check for IO::String, and even if that fails, simply skip those tests that require in-memory filehandle (or use tempfile). -- Jakub Narebski Poland ShadeHawk on #git --

Hi, Heh. The part about the shell scripts was actually meant as a genuine praise. And I did not mean to criticize _you_ for introducing IO::Stream. Ciao, Dscho --

Oops... You are right, my mistake. For my defense I'd like to point out that the patch this patch is response to was made by gitweb caching project GSoC student, Lea Wiemann And I pointed out how it could be resolved (use 5.8 specific feature, or IO::String, or skip tests). -- Jakub Narebski Poland --

"use 5.008;" is preferred form; "use v5.8.0" might yield obscure error messages on perls < 5.6, which is not the desired result. --

Hello I have a big bare repository 'main.git' and many small git repositories sub1, sub2, ... subn. All repositories lie in the same file file system, and each subx repository track and fetch main.git in a remote branch. I would like to avoid duplicating main.git objects, I have made some tries: - Putting a hard link to the pack in the object repository of main.git into subx object repository before fetching the main.git remote. It works well... until the first repack on either side. Note ...

Thanks Michael, this looks like what I want, I'll give it a try, but it takes a week to do our import. As far as making sense, it depends on whether you think of them as projects or cvs modules. Our projects are made up of multiple cvs modules, for various reasons, so it makes sense for us. -Kelly --

So these four patches end up adding support for conditionally enabling fsync() on loose object creation in the .gitconfig file with something like [core] FsyncObjectFiles = true which can be useful on filesystems that don't already guarantee data consistency for other reasons (whether due to ordered writes or due to full data journalling). Actually, just the last one adds the fairly trivial feature, the three first patches are just cleanups of the config parsing that I needed in ...

From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 18 Jun 2008 14:37:18 -0700 Subject: [PATCH 1/4] Split up default "core" config parsing into helper routine It makes the code a bit easier to read, and in theory a bit faster too (no need to compare all the different "core.*" strings against non-core config options). The config system really should get something of a complete overhaul, but in the absense of that, this at least improves on it a tiny bit. Signed-off-by: Linus ...

From: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed, 18 Jun 2008 14:40:35 -0700 Subject: [PATCH 2/4] Split up default "user" config parsing into helper routine This follows the example of the "core" config, and splits out the default "user" config option parsing into a helper routine. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> --- config.c | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/config.c b/config.c index ...

Maybe it would be easier still to read (and unmeasurably more efficient) to actually do it like: if (!prefixcmp(var, "core.")) return git_default_core_config(var+5, value); ... int git_default_core_config(const char *var, const char *value) { if (!strcmp(var, "pager")) I was curious a while ago and instrumented git_config to write the PID to a tempfile each time it was called. Most git programs parse the config files (.git/config, ~/.gitconfig, ...

The latest feature release GIT 1.5.6 is available at the usual places: http://www.kernel.org/pub/software/scm/git/ git-1.5.6.tar.{gz,bz2} (tarball) git-htmldocs-1.5.6.tar.{gz,bz2} (preformatted docs) git-manpages-1.5.6.tar.{gz,bz2} (preformatted docs) RPMS/$arch/git-*-1.5.6-1.$arch.rpm (RPM) As promised, this cycle was short and the release is with only relatively small impact changes. ---------------------------------------------------------------- GIT v1.5.6 Release ...

This function is not used by any other file. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- cache.h | 1 - config.c | 2 +- 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index 81b7e17..a82e493 100644 --- a/cache.h +++ b/cache.h @@ -735,7 +735,6 @@ extern int git_config_set_multivar(const char *, const char *, const char *, int extern int git_config_rename_section(const char *, const char *); extern const char ...

These function are not used anywhere. Also removes graph_release() that is never called. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- graph.c | 57 +++++++++++++++++++++++++++++++++++++++++++-------------- graph.h | 40 ---------------------------------------- 2 files changed, 43 insertions(+), 54 deletions(-) diff --git a/graph.c b/graph.c index e2633f8..5f82170 100644 --- a/graph.c +++ b/graph.c @@ -4,6 +4,43 @@ #include "diff.h" #include "revision.h" +/* ...