* Bad URL passed to RA lay
From: m.skoric @ 2009-10-13 7:35 UTC (permalink / raw)
To: git
Hi List,
i have a problem with git-svn clone / fetch. I get following error while doing one of previous command -> "Bad URL passed to RA lay"
This happens because a branch doesn't exists in svn anymore and git wants to retrieve data from it. Here is the complete error message
Initializing parent: Abo-Uebernahme (Bug #994)@341
Found possible branch point: "quoted"..trunk => "quoted"...Abo-Uebernahme (Bug #994), 203
Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
git version 1.6.3.3
Aynone else has this Problem?
Can anyone help me?
Thanks in advance
Majk
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Johannes Sixt @ 2009-10-13 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Kaseorg, git
In-Reply-To: <7v3a5n3hgn.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Half of the time, the commit you test in your "git bisect" section would
> be a "good" one, and immediately after you tell it "bisect good", it tells
> you that some _other_ commit you marked "bad" is the first bad commit. In
> such a case, you won't be on the commit that the bisect has found.
Oh, yes, very true; but it is very close. But the commit that git bisect
reset warps me to is perhaps 1000 steps in history away. I certainly do
not want to go there, ever, because I want to go back near the bad commit
right away. (Think of fewer files changed means less build time.) If git
bisect reset would check out the bad commit, this would be *very* convenient.
-- Hannes
^ permalink raw reply
* Re: Questions about the new
From: Sergio Callegari @ 2009-10-13 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v8wfge2zu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sergio Callegari <sergio.callegari@gmail.com> writes:
>
>
>> If I want to replace some commit X by some commit X' I merely need to
>> modify the
>> parent information of all the commits that are child of X so that they
>> pretend
>> to be child of X', or am I missing something?
>>
>
> You need to find all the commits that are child of X in the first place.
> What should happen if your colleague has such a commit in his repository
> (which you haven't fetched from yet), you enumerated all children of X
> known to you in your graft file and then you fetch from him? You need to
> enumerate all children of X again to keep the graft file up to date.
>
Ok, that is enlightening. When trying to sort out the differences,
advantages and disadvantages of
operating on arcs (grafts like) or on nodes (replacements like) I was
thinking local, rather than
distributed. Now the advantage of working on nodes is much clearer to me.
Thanks as usual for the very clear explanation.
Sergio
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-13 8:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Anders Kaseorg, git
In-Reply-To: <4AD43002.5080003@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> Half of the time, the commit you test in your "git bisect" section would
>> be a "good" one, and immediately after you tell it "bisect good", it tells
>> you that some _other_ commit you marked "bad" is the first bad commit. In
>> such a case, you won't be on the commit that the bisect has found.
>
> Oh, yes, very true; but it is very close. But the commit that git bisect
> reset warps me to is perhaps 1000 steps in history away. I certainly do
> not want to go there, ever, because I want to go back near the bad commit
> right away. (Think of fewer files changed means less build time.) If git
> bisect reset would check out the bad commit, this would be *very* convenient.
I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make
a lot of sense.
In my workflow, after I chased a bug in frotz, I often do
$ git name-rev $the_bad_one_that_was_found
to learn what was the first tagged release that has the bug, and create a
topic from there:
$ git checkout -b jc/maint-X.Y.Z-fix-frotz $the_bad_one_that_was_found
so that the fix I'd build on the commit can be merged initially to 'pu',
then 'next', then 'maint-X.Y.Z' and upwards to 'master', but all of that
is done after "git bisect reset" to switch back to the 'master' branch.
It is cumbersome to have to type (actually, I use the cut buffer in screen)
the commit object name of the first bad one twice.
It certainly sounds attractive if we can do:
$ git bisect reset-and-detach-at-the-first-bad-one
$ git name-rev HEAD
$ git checkout -b jc/maint-X.Y.Z-fix-frotz
$ hack hack hack
$ git commit
But at that point we are not talking about switching to arbitrary commit
anymore.
^ permalink raw reply
* Re: [RFC PATCH v2 16/16] Smart HTTP fetch: gzip requests
From: Junio C Hamano @ 2009-10-13 8:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow
In-Reply-To: <1255400715-10508-17-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> diff --git a/remote-curl.c b/remote-curl.c
> index 31d1d34..d53215d 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -261,11 +261,12 @@ static size_t rpc_in(const void *ptr, size_t eltsize,
> return size;
> }
>
> -static int post_rpc(struct rpc_state *state)
> +static int post_rpc(struct rpc_state *state, int use_gzip)
> {
> struct active_request_slot *slot;
> struct slot_results results;
> struct curl_slist *headers = NULL;
> + unsigned char *gzip_body = NULL;
> int err = 0, large_request = 0;
>
> /* Try to load the entire request, if we can fit it into the
> @@ -311,6 +313,48 @@ static int post_rpc(struct rpc_state *state)
> ...
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, gzip_body);
cc1: warnings being treated as errors
In function 'post_rpc',
inlined from 'one_shot_rpc_service' at remote-curl.c:433:
remote-curl.c:350: error: call to '_curl_easy_setopt_err_postfields' declared with attribute warning: curl_easy_setopt expects a void* or char* argument for this option
make: *** [remote-curl.o] Error 1
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 8:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> So we need the set of new rules, say, for 1.7.0 release. A strawman?
>
> Assume that these are the only refs that exist:
>
> refs/remotes/origin/{master,next,nitfol}
> refs/remotes/xyzzy/{frotz,nitfol}
> refs/heads/master
Sorry, I had this as refs/heads/{master,mine} in my initial draft but
removed the 'mine' branch by mistake; the first item in #0 does not make
sense without it.
> refs/tags/v1.0.0
>
> #0. These will stay as is:
>
> $ git checkout mine ;# switches to the branch
> $ git checkout $any_committish^0 ;# detaches
>
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> #2. These are allowed only when unambiguous and there is no local branch yet.
>
> $ git checkout next ;# ok
> $ git checkout frotz ;# ok (origin is not special)
> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
>
> #3. These used to detach, but what should we do?
>
> $ git checkout v1.0.0 ;# detach, or refuse???
> $ git checkout origin/master ;# detach, or refuse???
>
> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
>
> Did I cover all cases?
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-13 8:51 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> What it means is that -t was a broken attempt to help the users at the UI
> level, and I can surely see that.
>
> So we need the set of new rules, say, for 1.7.0 release. A strawman?
I feel somewhat uneasy commenting on this because I have a history of
writing just-barely-workable UIs. That being said:
> Assume that these are the only refs that exist:
>
> refs/remotes/origin/{master,next,nitfol}
> refs/remotes/xyzzy/{frotz,nitfol}
> refs/heads/master
> refs/tags/v1.0.0
>
> #0. These will stay as is:
>
> $ git checkout mine ;# switches to the branch
> $ git checkout $any_committish^0 ;# detaches
>
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
Agreed, though I'm still in favour of a cleaner syntax for explicit
detaching. (Cleaner in the sense that ^0 is documented as having a
completely different purpose and only works by accident.)
> #2. These are allowed only when unambiguous and there is no local branch yet.
>
> $ git checkout next ;# ok
> $ git checkout frotz ;# ok (origin is not special)
> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
I'm weakly leaning towards refusing all three, as the user should be
required to explicitly say a remote branch should be involved.
(Weakly because there's also a certain DWIM advantage to 'git checkout
sometopic'...)
> #3. These used to detach, but what should we do?
>
> $ git checkout v1.0.0 ;# detach, or refuse???
Refuse, on the grounds that the main goal here is not detaching unless
specifically told to. (Having a branch called v1.0.0 is worse, as it
would just cause a lot of confusion and/or a refusal at the next
checkout.)
> $ git checkout origin/master ;# detach, or refuse???
This seems to be the trickiest of them. Maybe check out 'master', to
make the process repeatable. Imagine, in your setting,
git checkout origin/next ;# creates 'next' as with -t
git checkout - ;# back
git checkout origin/next ;# should go to 'next' again
Then again, that would trade the confusion of detaching for the
confusion of not checking out the exact commit that the user
specified. Worse, 'next' could conceivably be tracking (as per
branch.next.merge) some entirely different branch, making the "Your
branch is behind..." message misleading.
> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
>
> Did I cover all cases?
Some that come to mind:
#3a. Other refs apart from tags that currently detach:
git fetch origin master ;# or even sillier, 'git fetch . master'
git checkout FETCH_HEAD ;# used to detach; refuse?
#3b. Full specifiers that currently detach:
git checkout refs/heads/master ;# could eventually attach
git checkout heads/master ;# same
#0a. Should probably detach if the previous checkout was detached:
git checkout - ;# detach if previous was detached?
git checkout @{-1} ;# same
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 9:24 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910131051.47117.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> #0. These will stay as is:
>>
>> $ git checkout mine ;# switches to the branch
>> $ git checkout $any_committish^0 ;# detaches
>>
>> #1. These used to detach, but will create a local branch
>>
>> $ git checkout origin/next ;# as if with -t
>> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> Agreed, though I'm still in favour of a cleaner syntax for explicit
> detaching. (Cleaner in the sense that ^0 is documented as having a
> completely different purpose and only works by accident.)
Oh, ^0 was just one way to make sure a committish is not a refname. If
you have an abbreviated hexadecimal commit object name, that would also
detach, which should fall into category #0. Sorry for the omission.
>> #2. These are allowed only when unambiguous and there is no local branch yet.
>>
>> $ git checkout next ;# ok
>> $ git checkout frotz ;# ok (origin is not special)
>> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
>
> I'm weakly leaning towards refusing all three, as the user should be
> required to explicitly say a remote branch should be involved.
>
> (Weakly because there's also a certain DWIM advantage to 'git checkout
> sometopic'...)
I thought this was the primary point of what Dscho has been advocating.
>> #3. These used to detach, but what should we do?
>>
>> $ git checkout v1.0.0 ;# detach, or refuse???
>
> Refuse, on the grounds that the main goal here is not detaching unless
> specifically told to. (Having a branch called v1.0.0 is worse, as it
> would just cause a lot of confusion and/or a refusal at the next
> checkout.)
>
>> $ git checkout origin/master ;# detach, or refuse???
>
> This seems to be the trickiest of them. Maybe check out 'master', to
> make the process repeatable. Imagine, in your setting,
>
> git checkout origin/next ;# creates 'next' as with -t
> git checkout - ;# back
> git checkout origin/next ;# should go to 'next' again
>
> Then again, that would trade the confusion of detaching for the
> confusion of not checking out the exact commit that the user
> specified. Worse, 'next' could conceivably be tracking (as per
> branch.next.merge) some entirely different branch, making the "Your
> branch is behind..." message misleading.
As I said already in the thread, I think that is a misguided attempt to
half-hide the fact that there are origin/next (tracking branch) and next
(a fork of it), that are two separate entities. It is misguided because
the user needs to understand and take advantage of the distinction to do
anything; in other words, it is not even an unnecessary complexity.
So I am very doubtful about the benefit of checking out 'master' when
the user explicitly tells us to check out 'origin/master', only because
the former forked from the latter.
> Some that come to mind:
>
> #3a. Other refs apart from tags that currently detach:
>
> git fetch origin master ;# or even sillier, 'git fetch . master'
> git checkout FETCH_HEAD ;# used to detach; refuse?
> #3b. Full specifiers that currently detach:
>
> git checkout refs/heads/master ;# could eventually attach
> git checkout heads/master ;# same
I'd throw both of these into category #3.
Anything that is valid "ref" (i.e. what dwim_ref() groks) that is not
a remote tracking branch (which creates a corresponding local branch)
can refuse to avoid unintended detachment by newbies.
> #0a. Should probably detach if the previous checkout was detached:
>
> git checkout - ;# detach if previous was detached?
> git checkout @{-1} ;# same
Perhaps.
So to recap, "git checkout $token" would:
* If dwim_ref() groks $token, and
- if it resolves to refs/heads/*, that is checking out a local branch;
- if it resolves to refs/remotes/*, and if there is no corresponding
local branch, create one forked from there, as if -t was given;
- everything else we used to detach, but we refuse in 1.7.0, to make it
harder for newbies to detach.
* If check_ref_format() is happy with $token, get_sha1() does not grok
$token, and there is only one ref of the form refs/remotes/$o/$token
then we pretend as if -t $o/$token was given and create a local branch
$token forked from it.
* Otherwise, we always detach.
Note that "checkout -" and "checkout @{-4}" are part of dwim_ref() family.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Sixt @ 2009-10-13 9:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
If I did 'git checkout origin/next' last week, I will already have a
branch next. What should happen if I do it again today?
I think that it should DWIM: If last week's next fast-fowards to this
week's origin/next (*and* next is the branch that tracks origin/next),
then the fast foward should happen. Otherwise 'git checkout origin/next'
should fail.
This way, if I built on last week's next, I will be notified; but if I
only want to browse history, then I won't be impeded by the existence of next.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-13 10:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4AD427AD.3010701@drmicha.warpmail.net>
On Tue, Oct 13, 2009 at 10:09 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 19:14:
>> On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>>>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>>
>>>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>>>> specify the value type, just how it is interpreted. For example: a value
>>>>>> of '1' can be interpreted as 'true'.
>>>>>
>>>>> It is not really about "interpreting", but about showing, isn't it?
>>>>
>>>> Unless you are setting it, instead of reading it.
>>>>
>>>
>>> I'd still suggest fixing the typo ("interpreted") and spelling out
>>> "boolean".
>>
>> Oops! You mean s/intepreted/interpreted/?
>
> Yep :)
>
>>
>> If we spell 'boolean' we might as well spell 'integer'; I think bool
>> and int are fine.
>>
>
> "int" is at least a standard type name in C, whereas "bool" is not; but,
> yes, feel free to spell out "integer", or use "--int or --bool" as it
> is, which is a back reference to the corresponding entries for "--int"
> and "--bool", where things should be spelled out.
'bool' is also a standard type, in C99.
--
Felipe Contreras
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Michael Wookey @ 2009-10-13 10:10 UTC (permalink / raw)
To: eduard stefan; +Cc: Tay Ray Chuan, Git Mailing List, msysgit, Junio C Hamano
In-Reply-To: <4AD0BBCB.8000306@gmail.com>
2009/10/11 eduard stefan <eduard.stefan@gmail.com>:
> Tay Ray Chuan wrote:
>> I suspect, as you do, it's got to do with remote-curl.
>>
>> Could you try this command?
>>
>> echo list | git remote-curl http://github.com/loudej/spark.git
>
> Inside an empty repository it crashes the same way,
> without any additional information.
> "git remote-curl" crashes in the same way,
> but "git remote-curl --help" tries to launch the browser.
>
> Is there any way to obtain more information from this crash?
> Some debug mode?
Using the above repository, I see the same crash with msysGit at git
revision 1.6.5. Using windbg as the post-mortem debugger, the
following information is captured:
(a14.e8c): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=00000000 ecx=ffffffff edx=0046cc00 esi=0046f98f edi=00000000
eip=00420354 esp=0022fd80 ebp=0022fda8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
...and the faulting instruction is:
git_remote_curl+0x20354:
00420354 f2ae repne scas byte ptr es:[edi]
so, a NULL dereference. The initial disassembly of the function is this:
0:000> u 0042033C
git_remote_curl+0x2033c:
0042033c 55 push ebp
0042033d 89e5 mov ebp,esp
0042033f 57 push edi
00420340 56 push esi
00420341 53 push ebx
00420342 83ec1c sub esp,1Ch
00420345 8b5d08 mov ebx,dword ptr [ebp+8]
00420348 8b750c mov esi,dword ptr [ebp+0Ch]
0042034b 31c0 xor eax,eax
0042034d b9ffffffff mov ecx,0FFFFFFFFh
00420352 89df mov edi,ebx
00420354 f2ae repne scas byte ptr es:[edi]
00420356 f7d1 not ecx
00420358 8d51ff lea edx,[ecx-1]
0042035b b9ffffffff mov ecx,0FFFFFFFFh
00420360 89f7 mov edi,esi
00420362 f2ae repne scas byte ptr es:[edi]
00420364 f7d1 not ecx
00420366 49 dec ecx
00420367 7466 je git_remote_curl+0x203cf (004203cf)
00420369 85d2 test edx,edx
0042036b 0f84b1000000 je git_remote_curl+0x20422 (00420422)
00420371 89f7 mov edi,esi
00420373 89de mov esi,ebx
...
So its the first parameter that is NULL. The second parameter is:
0:000> da poi(ebp+c)
0046f98f "libexec/git-core"
I don't know how to build msysGit so that symbols are generated so
I've attempted to reconstruct the source code; which ends up looking
something like the following:
int some_unknown_func(char *arg1, char *arg2)
{
len1 = strlen(arg1) - 1; // <- crash here
len2 = strlen(arg2);
len3 = len2 - 1;
if (len2 != 1) {
if (!len1)
return 0;
for (;;) {
x = arg1[len1 - 1];
if (x != '/' && x != '\\') {
--len1;
--len3;
if (arg1[len1] != arg2[len3])
return 0;
} else {
...
}
}
}
}
Perhaps those more familiar with git's sources might recognise code
that looks similar to the above sequence.
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-13 10:19 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091013021616.GA10554@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
On Tue, Oct 13, 2009 at 10:16:17AM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> > ASCIIDOC_NO_ROFF?
> >
> > Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
>
> I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
>
> # Platform specific tweaks
> #
>
> # We choose to avoid "if .. else if .. else .. endif endif"
> # because maintaining the nesting to match is a pain. If
> # we had "elif" things would have been much nicer...
>
> ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
> ifeq ($(uname_S),Linux)
>
> However, the man page still display the same
Don't edit the Makefile, just use the command 'make
ASCIIDOC_NO_ROFF=YesPlease'. Also make sure to do a 'make clean' in the
Documentation dir to get the manpages rebuilt.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Giuseppe Bilotta @ 2009-10-13 10:26 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta, Stephen Boyd, Jakub Narebski
In-Reply-To: <1255328340-28449-1-git-send-email-bebarino@gmail.com>
On Monday 12 October 2009 08:19, Stephen Boyd wrote:
> The problem is I can't get it to work with UTF-8 characters. I'm not sure
> if it's my system or not, so I'm just posting here to see if others
> experience the same problem and if there's interest.
Does it work if you use CGI::escape() on the author names when filling
the searchtext?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Changing branches in supermodule does not affect submodule?
From: Peter Krefting @ 2009-10-13 10:29 UTC (permalink / raw)
To: Git Mailing List
Hi!
If I have a repository with submodules that is in a clean state, and switch
branches in the super repository, the submodules are left in the state they
were in before I switched branches (with 1.6.4, at least). Is this the
expected behaviour?
--->8--8<---
#!/bin/bash
# Create supermodule.
mkdir super-$$
cd super-$$
git init
# Create submodule with commit.
mkdir sub
cd sub
git init
echo C > c.txt
echo D > d.txt
git add c.txt d.txt
git commit -m Created.
cd ..
# Create commit and branch in supermodule.
echo A > a.txt
echo B > b.txt
git add a.txt b.txt sub
git commit -m Created.
git tag branchpoint
git checkout -b branch1
# Create branch1 in submodule and commit.
cd sub
git checkout -b branch1
echo E > c.txt
echo F > d.txt
git add c.txt d.txt
git commit -m Branched.
cd ..
# Commit to a branch in the supermodule.
git add sub
git commit -m Sub-update.
# Status should now be clean.
git status
# Create a new branch in supermodule, from the original commit.
git checkout -b branch2 branchpoint
# I now expect the submodule to be up-to-date and the state clean.
git status
--->8--8<---
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Johannes Sixt @ 2009-10-13 10:53 UTC (permalink / raw)
To: Michael Wookey, Junio C Hamano
Cc: eduard stefan, Tay Ray Chuan, Git Mailing List, msysgit
In-Reply-To: <d2e97e800910130310wa9731a6j9b9bdd25047ade85@mail.gmail.com>
Michael Wookey schrieb:
> Using the above repository, I see the same crash with msysGit at git
> revision 1.6.5. Using windbg as the post-mortem debugger, the
> following information is captured:
>
> (a14.e8c): Access violation - code c0000005 (!!! second chance !!!)
> eax=00000000 ebx=00000000 ecx=ffffffff edx=0046cc00 esi=0046f98f edi=00000000
> eip=00420354 esp=0022fd80 ebp=0022fda8 iopl=0 nv up ei pl zr na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
>
> ...and the faulting instruction is:
>
> git_remote_curl+0x20354:
> 00420354 f2ae repne scas byte ptr es:[edi]
>
> so, a NULL dereference. The initial disassembly of the function is this:
>
> 0:000> u 0042033C
> git_remote_curl+0x2033c:
> 0042033c 55 push ebp
> 0042033d 89e5 mov ebp,esp
> 0042033f 57 push edi
> 00420340 56 push esi
> 00420341 53 push ebx
> 00420342 83ec1c sub esp,1Ch
> 00420345 8b5d08 mov ebx,dword ptr [ebp+8]
> 00420348 8b750c mov esi,dword ptr [ebp+0Ch]
> 0042034b 31c0 xor eax,eax
> 0042034d b9ffffffff mov ecx,0FFFFFFFFh
> 00420352 89df mov edi,ebx
> 00420354 f2ae repne scas byte ptr es:[edi]
> 00420356 f7d1 not ecx
> 00420358 8d51ff lea edx,[ecx-1]
> 0042035b b9ffffffff mov ecx,0FFFFFFFFh
> 00420360 89f7 mov edi,esi
> 00420362 f2ae repne scas byte ptr es:[edi]
> 00420364 f7d1 not ecx
> 00420366 49 dec ecx
> 00420367 7466 je git_remote_curl+0x203cf (004203cf)
> 00420369 85d2 test edx,edx
> 0042036b 0f84b1000000 je git_remote_curl+0x20422 (00420422)
> 00420371 89f7 mov edi,esi
> 00420373 89de mov esi,ebx
> ...
>
> So its the first parameter that is NULL. The second parameter is:
>
> 0:000> da poi(ebp+c)
> 0046f98f "libexec/git-core"
>
> I don't know how to build msysGit so that symbols are generated so
> I've attempted to reconstruct the source code; which ends up looking
> something like the following:
>
> int some_unknown_func(char *arg1, char *arg2)
> {
> len1 = strlen(arg1) - 1; // <- crash here
> len2 = strlen(arg2);
> len3 = len2 - 1;
>
> if (len2 != 1) {
> if (!len1)
> return 0;
> for (;;) {
> x = arg1[len1 - 1];
>
> if (x != '/' && x != '\\') {
> --len1;
> --len3;
> if (arg1[len1] != arg2[len3])
> return 0;
> } else {
> ...
> }
> }
> }
> }
>
> Perhaps those more familiar with git's sources might recognise code
> that looks similar to the above sequence.
Wow, this is great work, thank you very much! The function is
strip_path_suffix(). And here is a patch that fixes the crash.
--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] remote-curl: add missing initialization of argv0_path
All programs, in particular also the stand-alone programs (non-builtins)
must call git_extract_argv0_path(argv[0]) in order to help builds that
derive the installation prefix at runtime, such as the MinGW build.
Without this call, the program segfaults (or raises an assertion
failure).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
remote-curl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index ad6a163..d8d276a 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -82,6 +82,7 @@ int main(int argc, const char **argv)
const char *url;
struct walker *walker = NULL;
+ git_extract_argv0_path(argv[0]);
setup_git_directory();
if (argc < 2) {
fprintf(stderr, "Remote needed\n");
--
1.6.5.1024.g31034.dirty
^ permalink raw reply related
* Re: [RFC PATCH v2 10/16] Git-aware CGI to provide dumb HTTP transport
From: Johannes Sixt @ 2009-10-13 10:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255400715-10508-11-git-send-email-spearce@spearce.org>
Shawn O. Pearce schrieb:
> +int main(int argc, char **argv)
> +{
> + char *dir = getenv("PATH_TRANSLATED");
> + char *input_method = getenv("REQUEST_METHOD");
> + struct service_cmd *cmd = NULL;
> + char *cmd_arg = NULL;
> + int i;
> +
Please insert here:
git_extract_argv0_path(argv[0]);
> + set_die_routine(die_webcgi);
> ...
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH v2 14/16] Smart push over HTTP: client side
From: Felipe Contreras @ 2009-10-13 11:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow
In-Reply-To: <1255400715-10508-15-git-send-email-spearce@spearce.org>
On Tue, Oct 13, 2009 at 5:25 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> The git-remote-curl backend detects if the remote server supports
> the git-receive-pack service, and if so, runs git-send-pack in a
> pipe to dump the command and pack data as a single POST request.
>
> The advertisements from the server that were obtained during the
> discovery are passed into git-send-pack before the POST request
> starts. This permits git-send-pack to operate largely unmodified.
>
> For smaller packs (those under 1 MiB) a tranditional POST with a
Traditional?
> Content-Length is used, permitting interaction with any HTTP/1.0
> compliant server. The 1 MiB limit is arbitrary, but is sufficent
> to fit most deltas created by human authors against text sources
> with the occasional small binary file (e.g. few KiB icon image).
>
> For larger packs which cannot be spooled entirely into the
> helper's memory space, the POST request requires HTTP/1.1 and
> Transfer-Encoding: chunked. This permits the client to upload an
> unknown amount of data in one HTTP transaction without needing to
> pregenerate the entire pack file locally.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> CC: Daniel Barkalow <barkalow@iabervon.org>
> ---
> Documentation/config.txt | 8 ++
> builtin-send-pack.c | 116 ++++++++++++++++++++-
> remote-curl.c | 258 +++++++++++++++++++++++++++++++++++++++++++++-
> send-pack.h | 3 +-
> sideband.c | 11 ++-
> transport.c | 1 +
> 6 files changed, 384 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index cd17814..7130d07 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1089,6 +1089,14 @@ http.maxRequests::
> How many HTTP requests to launch in parallel. Can be overridden
> by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
>
> +http.postBuffer::
> + Maximum size in bytes of the buffer used by smart HTTP
> + transports when POSTing data to the remote system.
> + For requests larger than this buffer size, HTTP/1.1 and
> + Transfer-Encoding: chunked is used to avoid creating a
> + massive pack file locally. Default is 1 MiB, which is
> + sufficient for most requests.
> +
> http.lowSpeedLimit, http.lowSpeedTime::
> If the HTTP transfer speed is less than 'http.lowSpeedLimit'
> for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index 37e528e..654c3d4 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -2,9 +2,11 @@
> #include "commit.h"
> #include "refs.h"
> #include "pkt-line.h"
> +#include "sideband.h"
> #include "run-command.h"
> #include "remote.h"
> #include "send-pack.h"
> +#include "quote.h"
>
> static const char send_pack_usage[] =
> "git send-pack [--all | --mirror] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
> @@ -59,7 +61,7 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> memset(&po, 0, sizeof(po));
> po.argv = argv;
> po.in = -1;
> - po.out = fd;
> + po.out = args->one_shot_rpc ? -1 : fd;
> po.git_cmd = 1;
> if (start_command(&po))
> die_errno("git pack-objects failed");
> @@ -83,6 +85,20 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> }
>
> close(po.in);
> +
> + if (args->one_shot_rpc) {
> + char *buf = xmalloc(LARGE_PACKET_MAX);
> + while (1) {
> + ssize_t n = xread(po.out, buf, LARGE_PACKET_MAX);
> + if (n <= 0)
> + break;
> + send_sideband(fd, -1, buf, n, LARGE_PACKET_MAX);
> + }
> + free(buf);
> + close(po.out);
> + po.out = -1;
> + }
> +
> if (finish_command(&po))
> return error("pack-objects died with strange error");
> return 0;
> @@ -303,6 +319,59 @@ static int refs_pushed(struct ref *ref)
> return 0;
> }
>
> +static void print_helper_status(struct ref *ref)
> +{
> + struct strbuf buf = STRBUF_INIT;
> +
> + for (; ref; ref = ref->next) {
> + const char *msg = NULL;
> + const char *res;
> +
> + switch(ref->status) {
> + case REF_STATUS_NONE:
> + res = "error";
> + msg = "no match";
> + break;
> +
> + case REF_STATUS_OK:
> + res = "ok";
> + break;
> +
> + case REF_STATUS_UPTODATE:
> + res = "ok";
> + msg = "up to date";
> + break;
> +
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + res = "error";
> + msg = "non-fast forward";
> + break;
> +
> + case REF_STATUS_REJECT_NODELETE:
> + case REF_STATUS_REMOTE_REJECT:
> + res = "error";
> + break;
> +
> + case REF_STATUS_EXPECTING_REPORT:
> + default:
> + continue;
> + }
> +
> + strbuf_reset(&buf);
> + strbuf_addf(&buf, "%s %s", res, ref->name);
> + if (ref->remote_status)
> + msg = ref->remote_status;
> + if (msg) {
> + strbuf_addch(&buf, ' ');
> + quote_two_c_style(&buf, "", msg, 0);
> + }
> + strbuf_addch(&buf, '\n');
> +
> + safe_write(1, buf.buf, buf.len);
> + }
> + strbuf_release(&buf);
> +}
> +
> int send_pack(struct send_pack_args *args,
> int fd[], struct child_process *conn,
> struct ref *remote_refs,
> @@ -310,6 +379,7 @@ int send_pack(struct send_pack_args *args,
> {
> int in = fd[0];
> int out = fd[1];
> + struct strbuf req_buf = STRBUF_INIT;
> struct ref *ref;
> int new_refs;
> int ask_for_status_report = 0;
> @@ -391,14 +461,14 @@ int send_pack(struct send_pack_args *args,
> char *new_hex = sha1_to_hex(ref->new_sha1);
>
> if (ask_for_status_report) {
> - packet_write(out, "%s %s %s%c%s",
> + packet_buf_write(&req_buf, "%s %s %s%c%s",
> old_hex, new_hex, ref->name, 0,
> "report-status");
> ask_for_status_report = 0;
> expect_status_report = 1;
> }
> else
> - packet_write(out, "%s %s %s",
> + packet_buf_write(&req_buf, "%s %s %s",
> old_hex, new_hex, ref->name);
> }
> ref->status = expect_status_report ?
> @@ -406,7 +476,17 @@ int send_pack(struct send_pack_args *args,
> REF_STATUS_OK;
> }
>
> - packet_flush(out);
> + if (args->one_shot_rpc) {
> + if (!args->dry_run) {
> + packet_buf_flush(&req_buf);
> + send_sideband(out, -1, req_buf.buf, req_buf.len, LARGE_PACKET_MAX);
> + }
> + } else {
> + safe_write(out, req_buf.buf, req_buf.len);
> + packet_flush(out);
> + }
> + strbuf_release(&req_buf);
> +
> if (new_refs && !args->dry_run) {
> if (pack_objects(out, remote_refs, extra_have, args) < 0) {
> for (ref = remote_refs; ref; ref = ref->next)
> @@ -414,11 +494,15 @@ int send_pack(struct send_pack_args *args,
> return -1;
> }
> }
> + if (args->one_shot_rpc && !args->dry_run)
> + packet_flush(out);
>
> if (expect_status_report)
> ret = receive_status(in, remote_refs);
> else
> ret = 0;
> + if (args->one_shot_rpc)
> + packet_flush(out);
>
> if (ret < 0)
> return ret;
> @@ -478,6 +562,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> struct extra_have_objects extra_have;
> struct ref *remote_refs, *local_refs;
> int ret;
> + int helper_status = 0;
> int send_all = 0;
> const char *receivepack = "git-receive-pack";
> int flags;
> @@ -523,6 +608,14 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> args.use_thin_pack = 1;
> continue;
> }
> + if (!strcmp(arg, "--one-shot-rpc")) {
> + args.one_shot_rpc = 1;
> + continue;
> + }
> + if (!strcmp(arg, "--helper-status")) {
> + helper_status = 1;
> + continue;
> + }
> usage(send_pack_usage);
> }
> if (!dest) {
> @@ -551,7 +644,14 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> }
> }
>
> - conn = git_connect(fd, dest, receivepack, args.verbose ? CONNECT_VERBOSE : 0);
> + if (args.one_shot_rpc) {
> + conn = NULL;
> + fd[0] = 0;
> + fd[1] = 1;
> + } else {
> + conn = git_connect(fd, dest, receivepack,
> + args.verbose ? CONNECT_VERBOSE : 0);
> + }
>
> memset(&extra_have, 0, sizeof(extra_have));
>
> @@ -575,12 +675,16 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
>
> ret = send_pack(&args, fd, conn, remote_refs, &extra_have);
>
> + if (helper_status)
> + print_helper_status(remote_refs);
> +
> close(fd[1]);
> close(fd[0]);
>
> ret |= finish_connect(conn);
>
> - print_push_status(dest, remote_refs);
> + if (!helper_status)
> + print_push_status(dest, remote_refs);
>
> if (!args.dry_run && remote) {
> struct ref *ref;
> diff --git a/remote-curl.c b/remote-curl.c
> index 42fd06c..529df42 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -5,17 +5,33 @@
> #include "walker.h"
> #include "http.h"
> #include "pkt-line.h"
> +#include "sideband.h"
> #include "run-command.h"
>
>
> +static size_t post_buffer_size = 16 * LARGE_PACKET_MAX;
> static struct remote *remote;
> static const char *url;
> static struct walker *walker;
>
> +static int http_options(const char *var, const char *value, void *cb)
> +{
> + if (!strcmp("http.postbuffer", var)) {
> + post_buffer_size = git_config_int(var, value);
> + if (post_buffer_size < LARGE_PACKET_MAX)
> + post_buffer_size = LARGE_PACKET_MAX;
> + return 0;
> + }
> +
> + return 0;
> +}
> +
> static void init_walker(void)
> {
> - if (!walker)
> + if (!walker) {
> walker = get_http_walker(url, remote);
> + git_config(http_options, NULL);
> + }
> }
>
> struct discovery {
> @@ -200,6 +216,193 @@ static void output_refs(struct ref *refs)
> free_refs(refs);
> }
>
> +struct rpc_state {
> + const char *service_name;
> + char *service_url;
> + char *hdr_content_type;
> + char *hdr_accept;
> + char *buf;
> + size_t alloc;
> + size_t len;
> + size_t pos;
> + int in;
> + int out;
> + unsigned verbose : 1;
> +};
> +
> +static size_t rpc_out(void *ptr, size_t eltsize,
> + size_t nmemb, void *buffer_)
> +{
> + size_t max = eltsize * nmemb;
> + struct rpc_state *state = buffer_;
> + size_t avail = state->len - state->pos;
> +
> + if (!avail) {
> + avail = packet_read_line(state->out, state->buf, state->alloc);
> + if (!avail)
> + return 0;
> + state->pos = 0;
> + state->len = avail;
> + }
> +
> + if (max < avail);
> + avail = max;
> + memcpy(ptr, state->buf + state->pos, avail);
> + state->pos += avail;
> + return avail;
> +}
> +
> +static size_t rpc_in(const void *ptr, size_t eltsize,
> + size_t nmemb, void *buffer_)
> +{
> + size_t size = eltsize * nmemb;
> + struct rpc_state *state = buffer_;
> + write_or_die(state->in, ptr, size);
> + return size;
> +}
> +
> +static int post_rpc(struct rpc_state *state)
> +{
> + struct active_request_slot *slot;
> + struct slot_results results;
> + struct curl_slist *headers = NULL;
> + int err = 0, large_request = 0;
> +
> + /* Try to load the entire request, if we can fit it into the
> + * allocated buffer space we can use HTTP/1.0 and avoid the
> + * chunked encoding mess.
> + */
> + while (1) {
> + size_t left = state->alloc - state->len;
> + char *buf = state->buf + state->len;
> + int n;
> +
> + if (left < LARGE_PACKET_MAX) {
> + large_request = 1;
> + break;
> + }
> +
> + n = packet_read_line(state->out, buf, left);
> + if (!n)
> + break;
> + state->len += n;
> + }
> +
> + slot = get_active_slot();
> + slot->results = &results;
> +
> + curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
> + curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
> + curl_easy_setopt(slot->curl, CURLOPT_URL, state->service_url);
> +
> + headers = curl_slist_append(headers, state->hdr_content_type);
> + headers = curl_slist_append(headers, state->hdr_accept);
> +
> + if (large_request) {
> + /* The request body is large and the size cannot be predicted.
> + * We must use chunked encoding to send it.
> + */
> + headers = curl_slist_append(headers, "Expect: 100-continue");
> + headers = curl_slist_append(headers, "Transfer-Encoding: chunked");
> + curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);
> + curl_easy_setopt(slot->curl, CURLOPT_INFILE, state);
> + if (state->verbose) {
> + fprintf(stderr, "POST %s (chunked)\n", state->service_name);
> + fflush(stderr);
> + }
> +
> + } else {
> + /* We know the complete request size in advance, use the
> + * more normal Content-Length approach.
> + */
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, state->buf);
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDSIZE, state->len);
> + if (state->verbose) {
> + fprintf(stderr, "POST %s (%lu bytes)\n",
> + state->service_name, (unsigned long)state->len);
> + fflush(stderr);
> + }
> + }
> +
> + curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
> + curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> + curl_easy_setopt(slot->curl, CURLOPT_FILE, state);
> +
> + if (start_active_slot(slot)) {
> + run_active_slot(slot);
> + if (results.curl_result != CURLE_OK) {
> + err |= error("RPC failed; result=%d, HTTP code = %ld",
> + results.curl_result, results.http_code);
> + }
> + }
> + curl_slist_free_all(headers);
> + return err;
> +}
> +
> +static int one_shot_rpc_service(const char *service,
> + int verbose,
> + const char **client_argv,
> + struct discovery *heads,
> + struct strbuf *result)
> +{
> + struct child_process client;
> + struct rpc_state state;
> + struct strbuf buf = STRBUF_INIT;
> + int err = 0;
> +
> + init_walker();
> + memset(&client, 0, sizeof(client));
> + client.in = -1;
> + client.out = -1;
> + client.git_cmd = 1;
> + client.argv = client_argv;
> + if (start_command(&client))
> + die("%s failed to execute", client_argv[0]);
> + if (heads)
> + write_or_die(client.in, heads->buf, heads->len);
> +
> + memset(&state, 0, sizeof(state));
> + state.alloc = post_buffer_size;
> + state.buf = xmalloc(state.alloc);
> + state.in = client.in;
> + state.out = client.out;
> + state.service_name = service;
> + state.verbose = !!verbose;
> +
> + strbuf_addf(&buf, "%s/%s", url, service);
> + state.service_url = strbuf_detach(&buf, NULL);
> +
> + strbuf_addf(&buf, "Content-Type: application/x-%s-request", service);
> + state.hdr_content_type = strbuf_detach(&buf, NULL);
> +
> + strbuf_addf(&buf, "Accept: application/x-%s-response", service);
> + state.hdr_accept = strbuf_detach(&buf, NULL);
> +
> + while (!err) {
> + int n = packet_read_line(state.out, state.buf, state.alloc);
> + if (!n)
> + break;
> + state.pos = 0;
> + state.len = n;
> + err |= post_rpc(&state);
> + }
> + if (result)
> + strbuf_read(result, client.out, 0);
> +
> + close(client.in);
> + close(client.out);
> + client.in = -1;
> + client.out = -1;
> +
> + err |= finish_command(&client);
> + free(state.service_url);
> + free(state.hdr_content_type);
> + free(state.hdr_accept);
> + free(state.buf);
> + strbuf_release(&buf);
> + return err;
> +}
> +
> struct fetch_args {
> unsigned verbose : 1;
> };
> @@ -289,7 +492,8 @@ static void parse_fetch(struct strbuf *buf, int multiple)
>
> struct push_args {
> unsigned dry_run : 1,
> - verbose : 1;
> + verbose : 1,
> + thin : 1;
> };
>
> static int push_dav(struct push_args *args, int nr_spec, char **specs)
> @@ -314,6 +518,51 @@ static int push_dav(struct push_args *args, int nr_spec, char **specs)
> return 0;
> }
>
> +static int push_git(struct discovery *heads,
> + struct push_args *args, int nr_spec, char **specs)
> +{
> + struct strbuf res = STRBUF_INIT;
> + const char **argv;
> + int argc = 0, i, err;
> +
> + argv = xmalloc((10 + nr_spec) * sizeof(char*));
> + argv[argc++] = "send-pack";
> + argv[argc++] = "--one-shot-rpc";
> + argv[argc++] = "--helper-status";
> + if (args->thin)
> + argv[argc++] = "--thin";
> + if (args->dry_run)
> + argv[argc++] = "--dry-run";
> + if (args->verbose)
> + argv[argc++] = "--verbose";
> + argv[argc++] = url;
> + for (i = 0; i < nr_spec; i++)
> + argv[argc++] = specs[i];
> + argv[argc++] = NULL;
> +
> + err = one_shot_rpc_service("git-receive-pack",
> + args->verbose,
> + argv, heads, &res);
> + if (res.len)
> + safe_write(1, res.buf, res.len);
> + strbuf_release(&res);
> + free(argv);
> + return err;
> +}
> +
> +static int push(struct push_args *args, int nr_spec, char **specs)
> +{
> + struct discovery *heads = discover_refs("git-receive-pack");
> + int ret;
> +
> + if (heads->proto_git)
> + ret = push_git(heads, args, nr_spec, specs);
> + else
> + ret = push_dav(args, nr_spec, specs);
> + free_discovery(heads);
> + return ret;
> +}
> +
> static void parse_push(struct strbuf *buf)
> {
> char **specs = NULL;
> @@ -330,6 +579,8 @@ static void parse_push(struct strbuf *buf)
> args.dry_run = 1;
> else if (!strcmp(buf->buf, "option verbose"))
> args.verbose = 1;
> + else if (!strcmp(buf->buf, "option thin"))
> + args.thin = 1;
> else
> die("http transport does not support %s", buf->buf);
>
> @@ -340,7 +591,7 @@ static void parse_push(struct strbuf *buf)
> break;
> } while (1);
>
> - if (push_dav(&args, nr_spec, specs))
> + if (push(&args, nr_spec, specs))
> exit(128); /* error already reported */
> for (i = 0; i < nr_spec; i++)
> free(specs[i]);
> @@ -395,6 +646,7 @@ int main(int argc, const char **argv)
> printf("fetch-multiple\n");
> printf("push\n");
> printf("option dry-run\n");
> + printf("option thin\n");
> printf("option verbose\n");
> printf("\n");
> fflush(stdout);
> diff --git a/send-pack.h b/send-pack.h
> index 8b3cf02..a7f4abf 100644
> --- a/send-pack.h
> +++ b/send-pack.h
> @@ -8,7 +8,8 @@ struct send_pack_args {
> force_update:1,
> use_thin_pack:1,
> use_ofs_delta:1,
> - dry_run:1;
> + dry_run:1,
> + one_shot_rpc:1;
> };
>
> int send_pack(struct send_pack_args *args,
> diff --git a/sideband.c b/sideband.c
> index 899b1ff..d5ffa1c 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -135,9 +135,14 @@ ssize_t send_sideband(int fd, int band, const char *data, ssize_t sz, int packet
> n = sz;
> if (packet_max - 5 < n)
> n = packet_max - 5;
> - sprintf(hdr, "%04x", n + 5);
> - hdr[4] = band;
> - safe_write(fd, hdr, 5);
> + if (0 <= band) {
> + sprintf(hdr, "%04x", n + 5);
> + hdr[4] = band;
> + safe_write(fd, hdr, 5);
> + } else {
> + sprintf(hdr, "%04x", n + 4);
> + safe_write(fd, hdr, 4);
> + }
> safe_write(fd, p, n);
> p += n;
> sz -= n;
> diff --git a/transport.c b/transport.c
> index 6d9652d..2ff1650 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -731,6 +731,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
> NULL);
> }
>
> + memset(&args, 0, sizeof(args));
> args.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);
> args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
> args.use_thin_pack = data->thin;
> --
> 1.6.5.52.g0ff2e
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Felipe Contreras
^ permalink raw reply
* [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
From: Tom G. Christensen @ 2009-10-13 11:14 UTC (permalink / raw)
To: git
This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
by installing the modules into the perl libdir and not $(prefix)/lib.
It will default to sitelib but will allow the user to choose by setting
the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.
Signed-off-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
---
perl/Makefile | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..264cfc1 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -20,7 +20,12 @@ clean:
$(RM) $(makfile).old
ifdef NO_PERL_MAKEMAKER
-instdir_SQ = $(subst ','\'',$(prefix)/lib)
+perllib = site
+ifdef INSTALLDIRS
+perllib = $(INSTALLDIRS)
+endif
+perlinstdir := $(shell sh -c "$(PERL_PATH_SQ) -V:install$(perllib)lib | cut -d\' -f2")
+instdir_SQ = $(subst ','\'',$(perlinstdir))
$(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
--
1.6.4.4
^ permalink raw reply related
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Michael Wookey @ 2009-10-13 11:43 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, eduard stefan, Tay Ray Chuan, Git Mailing List,
msysgit
In-Reply-To: <4AD45C28.4080501@viscovery.net>
2009/10/13 Johannes Sixt <j.sixt@viscovery.net>:
> Michael Wookey schrieb:
>> Using the above repository, I see the same crash with msysGit at git
>> revision 1.6.5. Using windbg as the post-mortem debugger, the
>> following information is captured:
>> [ ... snip ... ]
> Wow, this is great work, thank you very much! The function is
> strip_path_suffix(). And here is a patch that fixes the crash.
>
> --- >8 ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] remote-curl: add missing initialization of argv0_path
>
> All programs, in particular also the stand-alone programs (non-builtins)
> must call git_extract_argv0_path(argv[0]) in order to help builds that
> derive the installation prefix at runtime, such as the MinGW build.
> Without this call, the program segfaults (or raises an assertion
> failure).
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> remote-curl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index ad6a163..d8d276a 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -82,6 +82,7 @@ int main(int argc, const char **argv)
> const char *url;
> struct walker *walker = NULL;
>
> + git_extract_argv0_path(argv[0]);
> setup_git_directory();
> if (argc < 2) {
> fprintf(stderr, "Remote needed\n");
> --
> 1.6.5.1024.g31034.dirty
No more crashes for me :)
Tested-by: Michael Wookey <michaelwookey@gmail.com>
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Sebastian Pipping @ 2009-10-13 12:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <4AC0CBBE.7020603@hartwork.org>
Petr, any news on this one?
I just check and it still seems broken.
Sebastian
^ permalink raw reply
* Re: Changing branches in supermodule does not affect submodule?
From: Jens Lehmann @ 2009-10-13 13:11 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0910131115160.14223@ds9.cixit.se>
Peter Krefting schrieb:
> If I have a repository with submodules that is in a clean state, and
> switch branches in the super repository, the submodules are left in the
> state they were in before I switched branches (with 1.6.4, at least). Is
> this the expected behaviour?
Yup, submodules have to be updated separatly.
When they are cloned from a remote with "git submodule add" followed by
a "git submodule init", just calling "git submodule update" every time
you want the submodule to be updated according to the state committed
in the superproject will do the trick (but keep in mind that all
referenced commits have to be accessible in the local clone of your
submodule, so you might have to do a fetch there once in a while).
Jens
^ permalink raw reply
* Re: quote in help code example
From: bill lam @ 2009-10-13 14:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091013101916.GV23777@genesis.frugalware.org>
On Tue, 13 Oct 2009, Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:16:17AM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > > Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> > > ASCIIDOC_NO_ROFF?
> > >
> > > Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
> >
> > I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
> >
> > # Platform specific tweaks
> > #
> >
> > # We choose to avoid "if .. else if .. else .. endif endif"
> > # because maintaining the nesting to match is a pain. If
> > # we had "elif" things would have been much nicer...
> >
> > ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
> > ifeq ($(uname_S),Linux)
> >
> > However, the man page still display the same
>
> Don't edit the Makefile, just use the command 'make
> ASCIIDOC_NO_ROFF=YesPlease'. Also make sure to do a 'make clean' in the
> Documentation dir to get the manpages rebuilt.
I run these commands
make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr all doc info
sudo make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr install install-doc install-html install-info
1. did I need to set ASCIIDOC_NO_ROFF in both lines?
2. now the .ft pair fixed but it still displayed incorrect quote.
git filter-branch --tree-filter ´rm filename´ HEAD
it should be 'rm filename' not ´rm filename´
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 14:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vtyy3zo9m.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make
> a lot of sense.
Under my patch, that’s ‘git bisect reset bisect/bad’. Similar arguments
may be made as to whether that should or shouldn’t be a separate command
(although it’s less clear what to call it, in this case).
Anders
^ permalink raw reply
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Shawn O. Pearce @ 2009-10-13 15:15 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <7bfdc29a0910121830y4dc9b3efpe17860e04457988d@mail.gmail.com>
Imran M Yousuf <imyousuf@gmail.com> wrote:
> Firstly, I am sorry but I am not intelligent enough to perceive, how
> do the user decide which instance of Config to use? I personally think
> that there is no API to achieve what you just mentioned :(; i.e. the
> user will have know CassandraConfig directly.
Yes. Well, almost.
The user will have to know that s/he wants a CassandraRepository or
a JdbcRepository in order to obtain the abstract Repository handle.
Each of these will need different configuration, possibly data which
is too complex to simply cram into a URL string, so I was expecting
the application would construct the concrete Repository class and
configure it with the proper arguments required for contact with
the underlying storage.
Since the Repository wants several things associated with it, each
concrete Repository class knows what concrete Config, ObjectDatabase
and RefDatabase it should create. Those concrete classes know how
to read a repository stored on that medium.
> Secondly, I instead was
> thinking of porting JGit for that matter to any system supporting
> streams (not any specific sub-class of them), such HBase/BigTable or
> HDFS anything.... Thirdly, I think we actually have several task in
> hand and I would state them as -
>
> 1. First introduce the I/O API such that it completely replaces java.io.File
> 2. Secondly segregate persistence of for config (or config like
> objects) and introduce a SPI for them for smarter storage.
Supporting streams on an arbitrary backend is difficult. DHTs like
BigTable/Cassandra aren't very good at providing streams, they tend
to have a limit on how big a row can be. They tend to have very
slow read latencies, but can return a small block of consecutive
rows in one reply.
I want to talk about the DHT backend more with Scott Chacon at the
GitTogether, but I have this feeling that just laying a pack file
into a stream in a DHT is going to perform very poorly.
Likewise JDBC has similar performance problems, you can only store
so much in a row before performance of the RDBMS drops off sharply.
You can get a handful of rows in a single reply pretty efficiently,
but each query takes longer than you'd like. Yes, there is often
a BLOB type that allows large file storage, but different RDBMS
support these differently and have different performance when it
comes to accessing the BLOB types. Some don't support random access,
some do. Even if they do support random access read, writing a large
2 GiB repository's pack file after repacking it would take ages.
Once you get outside of the pack file, *everything* else git stores
is either a loose object, or very tiny text files (aka refs, their
logs, config). The loose object case should be handled by the same
thing that handles the bulk of the object store, loose objects are
a trivial thing compared to packed objects.
The refs, the ref logs, and the config are all structured text.
If you lay a Git repository down into a database of some sort,
I think its reasonable to expect that the schema for these items
in that database permits query and update using relatively native
primitives in that database. E.g. if you put this in SQL I would
expect a schema like:
CREATE TABLE refs (
repository_id INT NOT NULL
,name VARCHAR(255) NOT NULL
,id CHAR(40)
,target VARCHAR(255)
,PRIMARY KEY (repository_id, name)
,CHECK (id IS NOT NULL OR target IS NOT NULL));
CREATE TABLE reflogs (
repository_id INT NOT NULL
,name VARCHAR(255) NOT NULL
,old_id CHAR(40) NOT NULL
,new_id CHAR(40) NOT NULL
,committer_name VARCHAR(255)
,committer_email VARCHAR(255)
,committer_date TIMESTAMP NOT NULL
,message VARCHAR(255)
,PRIMARY KEY (repository_id, name, committer_date));
CREATE TABLE config (
repository_id INT NOT NULL
,section VARCHAR(255) NOT NULL
,group VARCHAR(255)
,name VARCHAR(255) NOT NULL
,value VARCHAR(255)
,PRIMARY KEY(repository_id, section, group, name, value))
This makes it easier to manipulate settings, you can use direct
SQL UPDATE to modify the configuration, or SELECT to scan through
reflogs. Etc.
If we just threw everything as streams into the database this
would be a lot more difficult to work with through the database's
own native query and update interface. You'd lose alot of the
benefits of using a database, but still be paying the massive price
in performance.
> I am not thinking of storing "only" the bare content of a git
> repository, but I intent to be able to also store the versioned
> contents it self as well.
When I say "bare repository" I only mean a repository without a
working directory. It still holds the complete revision history.
If you wanted a git repository on Cassandra but wanted to actually
have a working directory checkout, you'd need the local filesystem
for the checkout and .git/index, but could otherwise keep the objects
and refs in Cassandra. Its nuts... but in theory one could do it.
--
Shawn.
^ permalink raw reply
* [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 15:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaazw6uyi.fsf@alter.siamese.dyndns.org>
‘git bisect reset’ accepts an optional argument specifying a branch to
check out after cleaning up the bisection state. This lets you
specify an arbitrary commit.
In particular, this provides a way to clean the bisection state
without moving HEAD: ‘git bisect reset HEAD’. This may be useful if
you are not interested in the state before you began a bisect,
especially if checking out the old commit would be expensive and
invalidate most of your compiled tree.
Clarify the ‘git bisect reset’ documentation to explain this optional
argument, which was previously mentioned only in the usage message.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
Documentation/git-bisect.txt | 23 +++++++++++++++++------
git-bisect.sh | 7 +++----
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 63e7a42..d2ffae0 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -20,7 +20,7 @@ on the subcommand:
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [(<rev>|<range>)...]
- git bisect reset [<branch>]
+ git bisect reset [<commit>]
git bisect visualize
git bisect replay <logfile>
git bisect log
@@ -81,16 +81,27 @@ will have been left with the first bad kernel revision in "refs/bisect/bad".
Bisect reset
~~~~~~~~~~~~
-To return to the original head after a bisect session, issue the
-following command:
+After a bisect session, to clean up the bisection state and return to
+the original HEAD, issue the following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
-This resets the tree to the original branch instead of being on the
-bisection commit ("git bisect start" will also do that, as it resets
-the bisection state).
+By default, this will return your tree to the commit that was checked
+out before `git bisect start`. (A new `git bisect start` will also do
+that, as it cleans up the old bisection state.)
+
+With an optional argument, you can return to a different commit
+instead:
+
+------------------------------------------------
+$ git bisect reset <commit>
+------------------------------------------------
+
+For example, `git bisect reset HEAD` will leave you on the current
+bisection commit and avoid switching commits at all, while `git bisect
+reset bisect/bad` will check out the first bad revision.
Bisect visualize
~~~~~~~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..0c56c26 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -13,8 +13,8 @@ git bisect skip [(<rev>|<range>)...]
mark <rev>... untestable revisions.
git bisect next
find next bisection to test and check it out.
-git bisect reset [<branch>]
- finish bisection search and go back to branch.
+git bisect reset [<commit>]
+ finish bisection search and go back to commit.
git bisect visualize
show bisect status in gitk.
git bisect replay <logfile>
@@ -311,8 +311,7 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --verify "$1^{commit}" || exit
branch="$1" ;;
*)
usage ;;
--
1.6.5
^ permalink raw reply related
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