* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, gitster, git
In-Reply-To: <32c343770911142034j6cf10e36jbd031c49119973c8@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> On Fri, Nov 13, 2009 at 5:19 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>>
>> The second change is good but why do you remove -v from the
>> synopsis section? Why is it a good idea? Manual pages for
>> many other commands list --verbose in their synopsis section.
>>
>
> After checking other git operations (fetch, pull, clone, commit, merge, etc)
> I found that none of these other commands document '-v' in the synopsis.
>
> With that in mind, I wondered why it had been listed for 'git remote'. My best
> guess is that only some of the 'git remote' subcommands are affected by '-v'.
> However, to me it still seems better to only mention it as a general option.
> That way if subcommands add/remote support for '-v', the usage string
> and man page don't need to be updated.
>
> Please note that even with the change, '-v' is still printed as one of the
> general options in the usage string. I simply removed it from the synopsis
> section.
You noticed a good issue to address. That is, "git remote -h" output
looks Ok but "git remote add -h" and friends show way suboptimal help.
The current output looks like:
$ git remote add -h
usage: git remote [-v | --verbose]
or: git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name>
<url>
or: git remote rename <old> <new>
or: git remote rm <name>
or: git remote set-head <name> [-a | -d | <branch>]
or: git remote show [-n] <name>
or: git remote prune [-n | --dry-run] <name>
or: git remote [-v | --verbose] update [-p | --prune] [group]
add specific options
-f, --fetch fetch the remote branches
-t, --track <branch> branch(es) to track
-m, --master <branch>
master branch
--mirror no separate remotes
As the user already knows "add" is the subcommand she is interested in,
this is insane.
My preference is:
(1) to drop your change to the synopsis section ("git remote -v" is a
valid way to get more verbose information, isn't it?);
(2) to keep the current output of "git remote -h";
(3) to drop the general description section altogether from "git remote
add -h" output;
I think this is related to a bigger issue of how we generally would want
to show help in response to "-h", and also in the manual pages.
http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ permalink raw reply
* Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Jan Krüger; +Cc: Jeff King, Jan Nieuwenhuizen, Tomas Carnecky, git list
In-Reply-To: <20091112170814.1858aba4@perceptron>
Jan Krüger <jk@jk.gs> writes:
> So this still uses config file syntax, but the erroneous check for
> using the "rebase" setting is gone. Instead, if --rebase is in effect,
> include "rebase = true" in the sample config snippet.
Will queue.
I've been ill and didn't follow the discussion very closely, so perhaps
there may still some minor disagreements in the details I didn't catch?
Just in case, I'll queue it on 'pu' for now.
Thanks.
^ permalink raw reply
* Re: [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Tarmigan; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <905315640911141349t7121baa8vc0b2be59fa348512@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Our Content-Length needs to report an off_t, which could be larger
>> precision than size_t on this system (e.g. 32 bit binary built with
>> 64 bit large file support).
>>
>> We also shouldn't be passing a size_t parameter to printf when
>> we've used PRIuMAX as the format specifier.
>>
>> Fix both issues by using uintmax_t for the hdr_int() routine,
>> allowing strbuf's size_t to automatically upcast, and off_t to
>> always fit.
>>
>> Also fixed the copy loop we use inside of send_local_file(), we never
>> actually updated the size variable so we might as well not use it.
>>
>> Reported-by: Tarmigan <tarmigan+git@gmail.com>
>
> Tested-by: Tarmigan <tarmigan+git@gmail.com>
Thanks; care to spell your name in full (as if you are publishing say a
scientific paper)? I am guessing that the other Tarmigan with full name
who posted a few patches is the same person as you.
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Junio C Hamano @ 2009-11-15 9:05 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <20091114110141.GB1829@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> __git_compute_merge_strategies ()
> {
> - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
> + __git_merge_strategies=$(__git_list_merge_strategies)
Wouldn't
: ${__gms:=$(command)}
run command only until it gives a non-empty string?
^ permalink raw reply
* Re: [PATCH v4 0/9] Default pager and editor
From: Junio C Hamano @ 2009-11-15 9:04 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Thanks, re-queued.
I've been sick and in bed for the past few days, so apologies for a late
reply.
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Jacob Helwig @ 2009-11-15 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <20091115073628.GE5934@penguin.codegnome.org>
On Sat, Nov 14, 2009 at 23:36, Todd A. Jacobs <nospam@codegnome.org> wrote:
> On Sat, Nov 14, 2009 at 09:36:47PM -0800, Jacob Helwig wrote:
>
>> What version of git are you using? git checkout -b foo/bar/baz works
>
> I'm using 1.6.5.2 as well. Okay, try this in a temp directory, and
> you'll see what I mean:
>
> git init
> echo foo > foo
> git add foo
> git commit -m testing foo
> git checkout -b dev
> git checkout -b dev/feature/foobar
>
> The first branch works fine, but after attempting the nested branch the
> message reappears:
>
> error: unable to resolve reference refs/heads/dev/feature/foobar: Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> I can recreate this behavior at any time; it isn't just a problem with
> an existing repository.
>
> --
> "Oh, look: rocks!"
> -- Doctor Who, "Destiny of the Daleks"
>
The problem is that you have a branch dev. You can't have both a
file, and a directory with the same name.
You're trying to get git to do basically this:
% cd .git/refs/heads
% ls -l
total 0
-rw-rw-r-- 1 jhe jhe 41 2009-11-14 23:51 dev
-rw-rw-r-- 1 jhe jhe 41 2009-11-14 23:51 master
% mkdir dev
mkdir: cannot create directory `dev': File exists
You're getting the equivalent of the "cannot create directory" error.
When you have a branch with slashes in it, it gets stored as a
directory hierarchy under .git/refs/heads.
-Jacob
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Todd A. Jacobs @ 2009-11-15 7:36 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060911142136s68a08892ifa27989f3a5bfdfb@mail.gmail.com>
On Sat, Nov 14, 2009 at 09:36:47PM -0800, Jacob Helwig wrote:
> What version of git are you using? git checkout -b foo/bar/baz works
I'm using 1.6.5.2 as well. Okay, try this in a temp directory, and
you'll see what I mean:
git init
echo foo > foo
git add foo
git commit -m testing foo
git checkout -b dev
git checkout -b dev/feature/foobar
The first branch works fine, but after attempting the nested branch the
message reappears:
error: unable to resolve reference refs/heads/dev/feature/foobar: Not a directory
fatal: Failed to lock ref for update: Not a directory
I can recreate this behavior at any time; it isn't just a problem with
an existing repository.
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Daniel Barkalow @ 2009-11-15 7:16 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <20091115050227.GD5934@penguin.codegnome.org>
On Sat, 14 Nov 2009, Todd A. Jacobs wrote:
> I want to create a nested feature branch, but git keeps complaining if I
> nest more than one level deep:
>
> $ git checkout -b dev/feature/foo
> error: unable to resolve reference refs/heads/dev/feature/foo:
> Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> Based on my reading of the manual pages, it seems like I should be able
> to nest branch names as long as it conforms to certain rules. I read
> git-branch(1), which points me to git-check-ref-format(1), which seems
> to say that the rules are being followed.
Do you have a branch "dev/feature"? Branch names are path-like in that you
can't have dev/feature as both a branch and a prefix for branches.
> On the other hand, running:
>
> $ git check-ref-format foo; echo $?
>
> always results in a non-zero error code, even with a literal 'foo' as a
> branch name, so clearly it isn't saying what I think it's saying.
> *shrug*
You want either "git check-ref-format --branch foo" or "git
check-ref-format refs/heads/foo".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-15 6:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <1258242380.9650.90.camel@swboyd-laptop>
Stephen Boyd wrote:
> I was thinking of adding an option to git merge (like --strategies) to
> list the strategies without requiring you to be in a git directory. It
> doesn't look that easy at first glance so it might not be worth the
> trouble.
Right, that would require support from run_builtin().
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Jacob Helwig @ 2009-11-15 5:36 UTC (permalink / raw)
To: git
In-Reply-To: <20091115050227.GD5934@penguin.codegnome.org>
On Sat, Nov 14, 2009 at 21:02, Todd A. Jacobs <nospam@codegnome.org> wrote:
> I want to create a nested feature branch, but git keeps complaining if I
> nest more than one level deep:
>
> $ git checkout -b dev/feature/foo
> error: unable to resolve reference refs/heads/dev/feature/foo:
> Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> Based on my reading of the manual pages, it seems like I should be able
> to nest branch names as long as it conforms to certain rules. I read
> git-branch(1), which points me to git-check-ref-format(1), which seems
> to say that the rules are being followed.
>
> On the other hand, running:
>
> $ git check-ref-format foo; echo $?
>
> always results in a non-zero error code, even with a literal 'foo' as a
> branch name, so clearly it isn't saying what I think it's saying.
> *shrug*
>
> Can someone provide a little clarity here?
>
> --
> "Oh, look: rocks!"
> -- Doctor Who, "Destiny of the Daleks"
>
What version of git are you using? git checkout -b foo/bar/baz works
for me on 1.6.5.2. As far as git check-ref-format, it works (returns
0) if I do 'refs/heads/foo', but returns 1 on 'foo'. This makes
sense, given rule 2 from the manpage: They must contain at least one
/. This enforces the presence of a category like heads/, tags/ etc.
but the actual names are not restricted.
Hope this helps.
-Jacob
^ permalink raw reply
* PEBKAC or bug: unable to create path-like branch names
From: Todd A. Jacobs @ 2009-11-15 5:02 UTC (permalink / raw)
To: git
In-Reply-To: <20091115020605.GE15966@cl.cam.ac.uk>
I want to create a nested feature branch, but git keeps complaining if I
nest more than one level deep:
$ git checkout -b dev/feature/foo
error: unable to resolve reference refs/heads/dev/feature/foo:
Not a directory
fatal: Failed to lock ref for update: Not a directory
Based on my reading of the manual pages, it seems like I should be able
to nest branch names as long as it conforms to certain rules. I read
git-branch(1), which points me to git-check-ref-format(1), which seems
to say that the rules are being followed.
On the other hand, running:
$ git check-ref-format foo; echo $?
always results in a non-zero error code, even with a literal 'foo' as a
branch name, so clearly it isn't saying what I think it's saying.
*shrug*
Can someone provide a little clarity here?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-15 4:34 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: gitster, git
In-Reply-To: <20091114071948.6117@nanako3.lavabit.com>
On Fri, Nov 13, 2009 at 5:19 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>
> The second change is good but why do you remove -v from the
> synopsis section? Why is it a good idea? Manual pages for
> many other commands list --verbose in their synopsis section.
>
After checking other git operations (fetch, pull, clone, commit, merge, etc)
I found that none of these other commands document '-v' in the synopsis.
With that in mind, I wondered why it had been listed for 'git remote'. My best
guess is that only some of the 'git remote' subcommands are affected by '-v'.
However, to me it still seems better to only mention it as a general option.
That way if subcommands add/remote support for '-v', the usage string
and man page don't need to be updated.
Please note that even with the change, '-v' is still printed as one of the
general options in the usage string. I simply removed it from the synopsis
section.
Thank for reviewing,
Tim
^ permalink raw reply
* Preserving empty directories when doing a git-svn clone/rebase
From: Steven J. Murdoch @ 2009-11-15 2:06 UTC (permalink / raw)
To: git; +Cc: normalperson
When git-svn clones a Subversion repository, any empty directories
appear to be silently dropped (tested using git version 1.6.5.2 on Mac
OS X Snow Leopard). This causes problems for using git with software
projects which depend on Subversion's ability to track empty
directories. I was recently caught out by this, and it was difficult
to debug what had gone wrong.
Would it be possible to change git-svn to handle this case? Since git
doesn't have the ability to track empty directories, probably the
simplest thing to do would be to automatically add a file (e.g.
.gitignore) to any empty directories. In theory this could cause
problems, but I would think the chances of this are far lower than
with the current behaviour.
I think this feature would help projects in which some contributors
are transitioning to git. It would especially be useful to novice
users of git, who are not aware of the potential problems with having
empty directories.
I see there was a discussion in 2006:
http://kerneltrap.org/mailarchive/git/2006/11/29/231586
However, since then I haven't seen any updates. The rationale behind
the original request still seems applicable today:
"I think there are many potential git users out there who are
currently svn users. And git-svn is a really nice way to get started,
but this sort of stumbling block could really turn people off. For
example, it made me look pretty dumb when I carelessly complained to
my colleague about his code not working and then it turns out to be
because my super-advanced scm tool "messed things up"."
(git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)]
git-svn: fix output reporting from the delta fetcher))
Thanks,
Steven Murdoch.
--
http://www.cl.cam.ac.uk/users/sjm217/
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Daniel Barkalow @ 2009-11-15 2:49 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911141807q4be6015bjda4805496be6dbb3@mail.gmail.com>
On Sun, 15 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 11, 2009 at 19:45, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Okay, finally got to it just now. This is entirely untested (because I
> > don't have anything that uses it), but it compiles and should be correct.
> > It would be nice to get a clean bill of health on it from valgrind.
>
> After a lot of manual comparison of valgrind traces (comparing cloning
> a local git repo and a local hg repo), I have found the following
> before applying your patch (I removed the ==proc== and "by 0xDEADBEEF"
> noise):
>
> 20 bytes in 1 blocks are definitely lost in loss record 24 of 95
> at : calloc (vg_replace_malloc.c:418)
> by : xcalloc (wrapper.c:75)
> by : get_importer (transport-helper.c:132)
> by : fetch_with_import (transport-helper.c:150)
> by : fetch (transport-helper.c:198)
> by : transport_fetch_refs (transport.c:977)
> by : cmd_clone (builtin-clone.c:538)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
> by : main (git.c:509)
>
> 60 bytes in 1 blocks are definitely lost in loss record 43 of 95
> at : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_getwholeline (strbuf.c:335)
> by : strbuf_getline (strbuf.c:349)
> by : get_helper (transport-helper.c:52)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 65 bytes in 1 blocks are definitely lost in loss record 47 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_addf (strbuf.c:199)
> by : get_helper (transport-helper.c:69)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 65 bytes in 1 blocks are definitely lost in loss record 50 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_addf (strbuf.c:199)
> by : fetch_with_import (transport-helper.c:158)
> by : fetch (transport-helper.c:198)
> by : transport_fetch_refs (transport.c:977)
> by : cmd_clone (builtin-clone.c:538)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost
> in loss record 71 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : get_helper (transport-helper.c:62)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
> by : main (git.c:509)
>
> Annotated with the relevant source and my comments:
> by : get_importer (transport-helper.c:132)
> fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
>
> You never free fastimport->argv.
>
> by : get_helper (transport-helper.c:52)
> if (strbuf_getline(&buf, file, '\n') == EOF)
>
> You never strbuf_release(&buf).
>
> by : get_helper (transport-helper.c:69)
> strbuf_addf(&gitdir, "gitdir %s\n", get_git_dir());
>
> I do strbuf_reset(&gitdir), which should of course be
> strbuf_release(&gitdir), oops.
>
> by : fetch_with_import (transport-helper.c:158)
> strbuf_addf(&buf, "import %s\n", posn->name);
>
> Same here, you never strbuf_release(&buf).
>
> by : get_helper (transport-helper.c:62)
> ALLOC_GROW(refspecs,
> refspec_nr + 1,
> refspec_alloc);
>
> This would of course be fixed by your patch.
>
> However, applying your patch causes:
> error: Trying to write ref refs/heads/tip with nonexistant object
> 0000000000000000000000000000000000000000
> fatal: Cannot update the ref 'HEAD'.
>
> If I comment out both new lines in disonnect_helper like so fixes that:
> //free_refspec(data->refspec_nr, data->refspecs);
> //data->refspecs = NULL;
>
> Commenting out only one of the two makes the error return, any idea's?
Looks like I'm discarding the information before I use it, instead of
after. Try moving those lines to release_helper(), and a "!data->refspecs
&&" to the !prefixcmp(... "refspec ") if condition. (That is, keep the
refspecs from the first call to the helper until the whole thing is
released, and ignore those capabilities in later calls.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Sverre Rabbelier @ 2009-11-15 2:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0911111259520.14365@iabervon.org>
Heya,
On Wed, Nov 11, 2009 at 19:45, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Okay, finally got to it just now. This is entirely untested (because I
> don't have anything that uses it), but it compiles and should be correct.
> It would be nice to get a clean bill of health on it from valgrind.
After a lot of manual comparison of valgrind traces (comparing cloning
a local git repo and a local hg repo), I have found the following
before applying your patch (I removed the ==proc== and "by 0xDEADBEEF"
noise):
20 bytes in 1 blocks are definitely lost in loss record 24 of 95
at : calloc (vg_replace_malloc.c:418)
by : xcalloc (wrapper.c:75)
by : get_importer (transport-helper.c:132)
by : fetch_with_import (transport-helper.c:150)
by : fetch (transport-helper.c:198)
by : transport_fetch_refs (transport.c:977)
by : cmd_clone (builtin-clone.c:538)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
by : main (git.c:509)
60 bytes in 1 blocks are definitely lost in loss record 43 of 95
at : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_getwholeline (strbuf.c:335)
by : strbuf_getline (strbuf.c:349)
by : get_helper (transport-helper.c:52)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
65 bytes in 1 blocks are definitely lost in loss record 47 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_addf (strbuf.c:199)
by : get_helper (transport-helper.c:69)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
65 bytes in 1 blocks are definitely lost in loss record 50 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_addf (strbuf.c:199)
by : fetch_with_import (transport-helper.c:158)
by : fetch (transport-helper.c:198)
by : transport_fetch_refs (transport.c:977)
by : cmd_clone (builtin-clone.c:538)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost
in loss record 71 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : get_helper (transport-helper.c:62)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
by : main (git.c:509)
Annotated with the relevant source and my comments:
by : get_importer (transport-helper.c:132)
fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
You never free fastimport->argv.
by : get_helper (transport-helper.c:52)
if (strbuf_getline(&buf, file, '\n') == EOF)
You never strbuf_release(&buf).
by : get_helper (transport-helper.c:69)
strbuf_addf(&gitdir, "gitdir %s\n", get_git_dir());
I do strbuf_reset(&gitdir), which should of course be
strbuf_release(&gitdir), oops.
by : fetch_with_import (transport-helper.c:158)
strbuf_addf(&buf, "import %s\n", posn->name);
Same here, you never strbuf_release(&buf).
by : get_helper (transport-helper.c:62)
ALLOC_GROW(refspecs,
refspec_nr + 1,
refspec_alloc);
This would of course be fixed by your patch.
However, applying your patch causes:
error: Trying to write ref refs/heads/tip with nonexistant object
0000000000000000000000000000000000000000
fatal: Cannot update the ref 'HEAD'.
If I comment out both new lines in disonnect_helper like so fixes that:
//free_refspec(data->refspec_nr, data->refspecs);
//data->refspecs = NULL;
Commenting out only one of the two makes the error return, any idea's?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: pre-built man pages have ".ft" noise
From: Björn Steinbrink @ 2009-11-15 1:34 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git
In-Reply-To: <1258245915.9650.94.camel@swboyd-laptop>
On 2009.11.14 16:45:15 -0800, Stephen Boyd wrote:
> On Sun, 2009-11-15 at 00:47 +0100, Björn Steinbrink wrote:
> > since 916a3c4b7 "Autogenerated manpages for v1.6.5.1-69-g36942", some of
> > the man pages in the "man" branch have a lot of the ".ft C" and ".ft"
> > noise.
>
> I thought this was already noticed a few days ago by Jonathan Nieder.
>
> From: Jonathan Nieder <jrnieder@gmail.com>
> Subject: [PATCH todo] dodoc: detect doctype-xsl version before making
> docs
> Message-id: <20091112023139.GA1627@progeny.tock>
Ah, sorry for the noise then. I only searched the subject lines for
"man", my fault.
Björn
^ permalink raw reply
* Re: [PATCH] Check the format of more printf-type functions
From: Miklos Vajna @ 2009-11-15 1:10 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, Alex Riesen
In-Reply-To: <1258234393-5093-1-git-send-email-tarmigan+git@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
On Sat, Nov 14, 2009 at 01:33:13PM -0800, Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> it for others to make a proper fix. Looks like Miklos touched that line
> last, so perhaps he knows of a better fix.
I just added struct merge_options, the real change is commit a97e407
(Keep rename/rename conflicts of intermediate merges while doing
recursive merge, 2007-03-31), adding Alex to Cc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: pre-built man pages have ".ft" noise
From: Stephen Boyd @ 2009-11-15 0:45 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20091114234702.GA10708@atjola.homenet>
On Sun, 2009-11-15 at 00:47 +0100, Björn Steinbrink wrote:
> Hi Junio,
>
> since 916a3c4b7 "Autogenerated manpages for v1.6.5.1-69-g36942", some of
> the man pages in the "man" branch have a lot of the ".ft C" and ".ft"
> noise.
I thought this was already noticed a few days ago by Jonathan Nieder.
From:
Jonathan Nieder <jrnieder@gmail.com>
Subject: [PATCH todo] dodoc: detect doctype-xsl version before making
docs
Message-id: <20091112023139.GA1627@progeny.tock>
^ permalink raw reply
* Re: pushing remote branches
From: Sitaram Chamarty @ 2009-11-15 0:45 UTC (permalink / raw)
To: Lorenzo Bettini; +Cc: git
In-Reply-To: <hdneuv$nc8$2@ger.gmane.org>
Hi Lorenzo,
On Sun, Nov 15, 2009 at 5:07 AM, Lorenzo Bettini <bettini@dsi.unifi.it> wrote:
> url = git://...
> isn't this enough to be able to push the experiments branch?
not normally.
The "git://" protocol is a read-only protocol by default. Since it is
completely unauthenticated, enabling push via git:// is not a good idea in
general.
> url = git@...
This is a shortcut for something like ssh://git@..., which then allows write
also.
^ permalink raw reply
* .gitignore polution
From: Sverre Rabbelier @ 2009-11-14 23:57 UTC (permalink / raw)
To: Git List
Heya,
I usually compile git from next (sometimes pu to test out a new
feature), and when I then switch back to a development branch (usually
based off master) I get something like this:
$ git status
# On branch remote-helpers
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# git-http-backend
# git-notes
# git-remote-hg
# test-index-version
Now I can easily do 'git clean -f', but it's somewhat annoying. How do
other developers deal with this?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* pre-built man pages have ".ft" noise
From: Björn Steinbrink @ 2009-11-14 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
since 916a3c4b7 "Autogenerated manpages for v1.6.5.1-69-g36942", some of
the man pages in the "man" branch have a lot of the ".ft C" and ".ft"
noise. Apparently, you upgrade some parts of your system, as the changes
that introduced the noise also show:
-.\" Generator: DocBook XSL Stylesheets v1.73.2 <http://docbook.sf.net/>
+.\" Generator: DocBook XSL Stylesheets v1.74.3 <http://docbook.sf.net/>
And that new version seems to somehow end up producing:
-\.ft C
+\&.ft C
Björn
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Stephen Boyd @ 2009-11-14 23:46 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091114110141.GB1829@progeny.tock>
On Sat, 2009-11-14 at 05:01 -0600, Jonathan Nieder wrote:
> Stephen Boyd wrote:
>
> > I see a small problem, but it can be fixed in another patch. git
> > merge -s <TAB><TAB> the first time when you're not in a git
> > directory will make git merge -s <TAB><TAB> after never complete
> > correctly even in a git directory.
>
> Not good. I think the sanest thing to do is avoid caching the merge
> strategy list entirely. Listing merge strategies takes about 100 ms
> here, which is short enough not to be annoying.
>
I was thinking of adding an option to git merge (like --strategies) to
list the strategies without requiring you to be in a git directory. It
doesn't look that easy at first glance so it might not be worth the
trouble.
^ permalink raw reply
* pushing remote branches
From: Lorenzo Bettini @ 2009-11-14 23:37 UTC (permalink / raw)
To: git
Hi
I recently started to use git, and I experienced problems with branches:
on my machine I did (on an already cloned repo)
git checkout -b experiments origin/experiments
and thus my config reads
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://...
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "experiments"]
remote = origin
merge = refs/heads/experiments
isn't this enough to be able to push the experiments branch?
I tried
git push origin experiments
It tells me that it is a read-only url...
after adding
[remote "experiments"]
url = git@...
fetch =
+refs/heads/experiments:refs/remotes/experiments/experiments
I can now push that branch with
git push experiments experiments
but I was wondering whether the initial config wasn't enough...
many thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
^ permalink raw reply
* Re: git svn fetch loses data
From: Johan 't Hart @ 2009-11-14 23:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Victor Engmark, git
In-Reply-To: <fabb9a1e0911141138r5279650ge57db2413e2321a4@mail.gmail.com>
Sverre Rabbelier schreef:
> Heya,
>
> On Sat, Nov 14, 2009 at 20:29, Victor Engmark <victor.engmark@gmail.com> wrote:
>> Do I need to run something after fetch to see them?
>
> Your working copy is probably not up to date anymore, try:
>
> $ git rebase git-svn
>
Why not just
$ git svn rebase
?
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-14 23:29 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0911141239w2bab7277o66350bc742d985dd@mail.gmail.com>
Francis Moreau schreef:
> hello,
>
> Let's say I'm on a branch called 'foo'.
>
> I tried to rebase this branch by using 'git pull --rebase'.
>
> I first tried the following command:
>
> $ git pull --rebase origin master:foo
> remote: Counting objects: 5, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /dev/shm/git/A
> ! [rejected] master -> foo (non fast forward)
When using a refspec, you usually mean to update a remote tracking
branch, like refs/remotes/origin/master. Internally the refspec
parameter is passed to git fetch, which fast-forwards your local
tracking branch to match the remote branch.
With this command, you make git clear you want to fast-forward your
branch refs/foo to match the remotes master branch, and then rebase your
current branch on that foo branch.
Foo probably is also your current branch. So what you probably want is
to fetch the remotes master branch and rebase your current branch foo on
it. You could do it this way:
> Then I tried:
>
> $ git pull --rebase origin master
>
> which worked.
This does not update any remote tracking branches, but it will rebase
your foo branch on the remote master branch (which is what you want)
It could also be done with:
git pull --rebase origin master:origin/master
This will also update your remote tracking branch
refs/remotes/origin/master to match the master branch on the remote
repo. Your foo branch will then be rebased onto it.
>
> Reading the man git-pull I would assume the 2 commands are equivalent
> but obviously they're not.
>
> So the question is: why ?
So, thats why :) They're not the same. Many words... Hope you
understand... I hope I understood it well too..?
>
> Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox