git-ls-remote(1) says that ls-remote supports filtering by reference But when I try to use the <refs> argument on a current build of git (git version v1.5.3.7-1112-g9758ecd), I just get its usage message, ls-remote was recently made a builtin; was reference filtering deliberately removed, or was it just lost in translation from the shell script? Eyvind Bernhardsen -

It is very easy to use dmalloc with git. Follow the instructions here, http://dmalloc.com/docs/latest/online/dmalloc_4.html But using dmalloc shows a pervasive problem, none of the git commands are cleaning up after themselves. For example I ran a simple command, git-status, and thousands of objects were not freed. Normally this doesn't hurt since exiting the process obviously frees all of the memory. But when programming this way it becomes impossible to tell which leaks were on purpose and whic...

I tried using dmalloc to find the leak in repack but it is impossible to sort out the accidental leaks from the on-purpose ones. On exit there were millions of unfreed objects coming from all over the place. -- Jon Smirl jonsmirl@gmail.com -

From an earlier discussion here on the mailing list I had the impression that there was some support for merging submodules from the supermodule. This does not seem to be the case, but I think it would be very good if this WAS possible? Here is the shortest example that still mimics "real" work that shows the problem. Assume change1 and change2 are done by two different people in two different repositories and push this into separate branches in a central repo somewhere. A maintainer at the central...

* config.c (store_write_pair): Don't read value[-1]. Signed-off-by: Jim Meyering <meyering@redhat.com> --- config.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/config.c b/config.c index ed96213..6031b38 100644 --- a/config.c +++ b/config.c @@ -652,7 +652,7 @@ static int store_write_pair(int fd, const char* key, const char* value) for (i = 0; value[i]; i++) if (value[i] == ';' || value[i] == '#') quote = 1; - if (value[i-1] == ' ') + if (i &amp...

Shouldn't it be + return ref($val) ? $val : defined($val) ? [ $val ] : []; -- Jakub Narebski -

How about... (1) In each repository, run "repack -a -d". That would ensure that everybody has the necessary objects that they themselves need. By doing this for a repository that borrows from another makes sure pruning the latter would not break the former, so you start from leaves and move on to the repositories they borrow from. (2) In each repository, run "repack -a -l -d". By doing this for a repository that borrows from another repacks the former without ...

And by "you seem to think" I obviously don't mean "stupid n00b, you don't understand git" but "I'm unclear on what the behavior should be. You seem to be saying this, which means this is a serious bug." -Peff -

Since 930cf7dd7cc6b87d173f182230763e1f1913d319 'blob' action knows the file type; if the file type is not "text/*" or one of common network image formats/mimetypes (gif, png, jpeg) then the action "blob" defaulted to "blob_plain". This caused the problem if mimetypes file was not well suited for web, for example returning "application/x-sh" for "*.sh" shell scripts, instead of "text/plain" (or other "text/*"). Now "blob" action defaults to "blob_plain" ('raw' view) only if file is of type which is...

As desired, these pass for git-commit.sh, fail for builtin-commit (prior to the fixes), and succeeded for builtin-commit (after the fixes). Signed-off-by: Wincent Colaiuta <win@wincent.com> --- t/t7501-commit.sh | 2 +- t/t7503-pre-commit-hook.sh | 64 ++++++++++++++++++++++++++++++++ t/t7504-commit-msg-hook.sh | 88 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 153 insertions(+), 1 deletions(-) create mode 100755 t/t7503-pre-commit-hook.sh create mode 100...

At the moment the --no-verify switch to "git commit" instructs it to skip over the pre-commit hook. Here we teach "git commit --no-verify" to skip over the commit-msg hook as well. This brings the behaviour of builtin-commit back in line with git-commit.sh. Signed-off-by: Wincent Colaiuta <win@wincent.com> --- builtin-commit.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/builtin-commit.c b/builtin-commit.c index 2ec8223..df9377e 100644 --- a/builtin-commit.c...

The old git-commit.sh script allowed the commit-msg hook to not only prevent a commit from proceding, but also to edit the commit message on the fly and allow it to proceed. So here we teach builtin-commit to do the same. Signed-off-by: Wincent Colaiuta <win@wincent.com> --- builtin-commit.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/builtin-commit.c b/builtin-commit.c index df9377e..a6223d2 100644 --- a/builtin-commit.c +++ b/builtin-commit...

The patch looks correct, but I have an offtopic comment that does not have anything to do with the problem being discussed right now. Before being able to understand what was going on, I had to shuffle the above patch by duplicating the context lines, prefix them with '-' and then '+', and grouping preimage lines and postimage lines together, to come up with this patch: static int type_size_sort(const void *_a, const void *_b) { const struct object_entry *a = *(struct object_entry **)_a; ...

[... skip testcase showing a much nicer diff for human consumption ...] AFAIR bzr uses the patience diff already. I don't actually use bzr (obviously, because git is so much better:-) but it produces much nicer diffs than git if you have many small changes nearby. -Peter -

Yes, my impression is that the code in question can be improved a lot. This is specifically the error message I'd like to see fixed in some way, as it's confusing to beginners trying to check out the module for the first time. $ CVS_SERVER=/home/proski/bin/git-cvsserver cvs -d \ :fork:/home/proski/src/qgit/.git co foo fatal: ambiguous argument 'foo': unknown revision or path not in the working tree. Use '--' to separate paths from revisions Invalid module 'foo' at /home/proski/bin/git...

This suppresses unhelpful error messages from git rev-parse during checkout if the module doesn't exist. Signed-off-by: Pavel Roskin <proski@gnu.org> --- git-cvsserver.perl | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index ecded3b..409b301 100755 --- a/git-cvsserver.perl +++ b/git-cvsserver.perl @@ -2427,9 +2427,6 @@ sub update # first lets get the commit list $ENV{GIT_DIR} = $self->{git_pa...

Yay! This works great on my "pack a few hundred very large objects" repo. -Peff -

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- help.c | 31 +++++++++++-------------------- 1 files changed, 11 insertions(+), 20 deletions(-) Junio wrote about "help.c" in my "git-help: add -w|--web option to display html man page in a browser." patch: > Isn't this "check-help-cmd" duplication ugly, by the way? You are right, this patch should fix it. Thanks. diff --git a/help.c b/help.c index ecc8c66..78686db 100644 --- a/help.c +++ b/help.c @@ -241,7 ...

Hi, Patches? ;-) Ciao, Dscho -

Actually he never spoke like that (probably I missed that part too). Thanks Marco -

The code tried to parse and clean-up the author name and the one line information in three places (two callers of insert_author_oneline() and the called function itself), whihc was a mess. This renames the callee to insert_one_record() and make it responsible for cleaning up the author name and one line information. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-shortlog.c | 165 +++++++++++++++++++-------------------------------- 1 files changed, 62 insertions(+), 103 del...

whihc -> which Cheers, Wincent -

Try using 'git svn rebase remotes/ooo-build-2-3'. git-svn should produce its branches under refs/remotes/* and your local branches are under refs/heads/*. By using 'git checkout -b ooo-build-2-3 ooo-build-2-3' you created refs/heads/ooo-build-2-3 as a copy of refs/remotes/ooo-build-2-3 and now using only ooo-build-2-3 is ambigious. (at least in some cases where git Look up --prefix in the manpage for git-svn. -Peter -

git svn init --stdlayout creates this entry in your .git/config per default [svn-remote "svn"] url = https://url/to/your/svn/repo fetch = trunk:refs/remotes/trunk branches = branches/*:refs/remotes/* tags = tags/*:refs/remotes/tags/* You could change this to [svn-remote "svn"] url = https://url/to/your/svn/repo fetch = trunk:refs/remotes/origin/trunk branches = branches/*:refs/remotes/origin/* tags = tags/*:refs/remotes/o...

Since you have a different result according to the source pack used then those cache settings, even if there was a bug with them, are not Which is quite reasonable, even if the same issue might still be there. So the problem seems to be related to the pack access code and not the repack code. And it must have something to do with the number of deltas being replayed. And because the repack is attempting delta compression roughly from newest to oldest, and because old objects are typica...