* Re: subversion-perl missing
From: Michael J Gruber @ 2011-09-26 14:54 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: git
In-Reply-To: <4E80916A.9060809@gjlay.de>
Georg-Johann Lay venit, vidit, dixit 26.09.2011 16:51:
> Michael J Gruber schrieb:
>> Georg-Johann Lay venit, vidit, dixit 26.09.2011 15:41:
>>> Michael J Gruber schrieb:
>>>> Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
>>>>> Hi, I just downloaded git and built from source, version is
>>>>>
>>>>> git version 1.7.6.4
>>>>>
>>>>> I am particularly interested in git-svn, but running it I get complaints
>>>>>
>>>>> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
>>>>> Can't locate SVN/Core.pm in @INC (@INC contains:
>>>>> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>>>>> /usr/local/lib/perl5/site_perl/5.10.0
>>>>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
>>>>> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>>>>> /usr/lib/perl5/site_perl/5.10.0
>>>>> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
>>>>> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
>>>>> /usr/local/libexec/git-core/git-svn line 42
>>>>>
>>>>> I found out that a module like subversion-perl is missing, but installing it
>>>>> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
>>>> So, where did you get your svn from? If you compiled it yourself, you
>>>> should rebuild it with the perl bindings. Make sure you note where you
>>>> install this to - you may have to adjust your PERL5LIB.
>>> Hi Michael
>>>
>>> svn identifies itself as
>>>
>>> > svn --version
>>>
>>> svn, version 1.6.2 (r37639)
>>> compiled Jun 19 2009, 12:21:15
>>>
>>> Copyright (C) 2000-2009 CollabNet.
>>> Subversion is open source software, see http://subversion.tigris.org/
>>> This product includes software developed by CollabNet (http://www.Collab.Net/).
>>>
>>> The following repository access (RA) modules are available:
>>>
>>> * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
>>> - handles 'http' scheme
>>> - handles 'https' scheme
>>> * ra_svn : Module for accessing a repository using the svn network protocol.
>>> - with Cyrus SASL authentication
>>> - handles 'svn' scheme
>>> * ra_local : Module for accessing a repository on local disk.
>>> - handles 'file' scheme
>>>
>>> and its installed in
>>>
>>> > which svn
>>>
>>> /usr/bin/svn
>>>
>>> > echo $PERL5LIB
>>>
>>> <empty>
>>>
>>> so looks like plain vanilla installation/build.
>>>
>>> Is "perl bindings" the "subversion-perl" package (which likes to downgrade my
>>> svn upon installing in yast)?
>>
>> Yes, subversion-perl are the perl bindings, and if your distro has
>> mismatching versions of subversion and subversion perl, then they have a
>> problem, sorry :|
>>> Is it a part of SVN (couln't find it there) or of perl?
>
>
> I could find
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL
> and hope that explains the trick so that a noob like me doesn't get lost...
That requires you to build swig and subversion, which I thought you
wanted to avoid. But if that does not scare you - by all means go ahead :)
> Many, many thanks for your help Michael!
>
> Johann
Cheers,
Michael
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-26 15:11 UTC (permalink / raw)
To: Jeff King
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <20110926110552.GA20796@sigill.intra.peff.net>
On 09/26/2011 01:05 PM, Jeff King wrote:
> On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:
>> There are obviously config options that should not be versioned. These
>> should not be stored in the tree. (Perhaps they should be stored in
>> another branch, as you suggested.) But there's no need to prevent
>> people from versioning *any* config options just because they shouldn't
>> version *all* of them.
>
> Do you have an example of a config option whose old value should be
> respected when looking at an old version? In general, the split between
> attributes and config was meant to split what is tied to a specific
> version, and what should apply to all versions. We may not have followed
> that in all cases, but if so, the right solution may actually be
> migrating the functionality into .gitattributes.
I hadn't realized this point about the split between gitconfig and
gitattributes. It makes sense. I'd been thinking that it would be nice
to be able to share changes to the git config the same way that source
code is shared, but you are right that the git config is versioned
differently than the source code. I can't think of any counterexamples
right now.
>> While we are on the topic of config settings, I have often thought that
>> it would be nice for git's default settings to be set via a
>> well-commented config file, installed along with git, rather than via
>> values compiled into the code. This file and Documentation/config.txt
>> could be generated from a single source file as part of the build
>> process.
>
> I think that can be a nice piece of documentation, but there may be some
> complications. I seem to recall that there may be one or two options
> whose builtin values cannot be replicated via config (i.e., the "unset"
> state means something). But I may be misremembering.
This is more a reason to implement a way to "unset" options than an
argument against storing git's builtin defaults in a gitconfig-formatted
file.
> However, I'm not sure what you mean by "rather than via values compiled
> into the code". Would you somehow generate code that sets the default
> according to your master file? Would git fail to start if the file is
> missing? Or if a specific config option is missing? How would you track
> that?
I think that git should read its "as-installed" config file at runtime
to maximize the transparency. If the file is missing then git should
fail, just as it would if some other important part of git were missing
from an install. The absence of a required config option would be a bug
and might cause git to abort just like any other bug.
I probably shouldn't mention this lest people realize that I'm stupid
and ugly, but...
Subversion installs a file with all of its defaults into your
~/.subversion directory the first time that it runs. I find this
feature to be very helpful as a source of examples and to learn new
features. But they do it a bit differently than I am proposing for
git--the file is written to the user's ~/.subversion, and is
subsequently edited by the user. Because the file lives across
Subversion upgrades, the options in this file are *commented out* to
prevent them causing trouble in the future; i.e., they are for human
consumption only.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 15:15 UTC (permalink / raw)
To: git, Julian Phillips
In-Reply-To: <201109251443.28243.mfick@codeaurora.org>
OK, I have found what I believe is another performance
regression for large ref counts (~100K).
When I run git br on my repo which only has one branch, but
has ~100K refs under ref/changes (a gerrit repo), it takes
normally 3-6mins depending on whether my caches are fresh or
not. After bisecting some older changes, I noticed that
this ref seems to be where things start to get slow:
c774aab98ce6c5ef7aaacbef38da0a501eb671d4
commit c774aab98ce6c5ef7aaacbef38da0a501eb671d4
Author: Julian Phillips <julian@quantumfyre.co.uk>
Date: Tue Apr 17 02:42:50 2007 +0100
refs.c: add a function to sort a ref list, rather then
sorting on add
Rather than sorting the refs list while building it,
sort in one
go after it is built using a merge sort. This has a
large
performance boost with large numbers of refs.
It shouldn't happen that we read duplicate entries into
the same
list, but just in case sort_ref_list drops them if the
SHA1s are
the same, or dies, as we have no way of knowing which
one is the
correct one.
Signed-off-by: Julian Phillips
<julian@quantumfyre.co.uk>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
which is a bit strange since that commit's purpose was to
actually speed things up in the case of many refs. Just to
verify, I reverted the commit on 1.7.7.rc0.73 and sure
enough, things speed up down to the 14-20s range depending
on caching.
If this change does not actually speed things up, should it
be reverted? Or was there a bug in the change that makes it
not do what it was supposed to do?
Thanks,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Sverre Rabbelier @ 2011-09-26 15:21 UTC (permalink / raw)
To: Martin Fick; +Cc: git, Julian Phillips
In-Reply-To: <201109260915.29285.mfick@codeaurora.org>
Heya,
On Mon, Sep 26, 2011 at 17:15, Martin Fick <mfick@codeaurora.org> wrote:
> If this change does not actually speed things up, should it
> be reverted? Or was there a bug in the change that makes it
> not do what it was supposed to do?
It probably looks at the refs in refs/changes while it shouldn't,
hence worsening your performance compared to not looking at those
refs. I assume that it does improve your situation if you have all
those refs under say refs/heads.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Michael Haggerty @ 2011-09-26 15:32 UTC (permalink / raw)
To: Martin Fick; +Cc: git, Christian Couder
In-Reply-To: <201109251443.28243.mfick@codeaurora.org>
On 09/25/2011 10:43 PM, Martin Fick wrote:
> A coworker of mine pointed out to me that a simple
>
> git checkout
>
> can also take rather long periods of time > 3 mins when run
> on a repo with ~100K refs.
>
> While this is not massive like the other problem I reported,
> it still seems like it is more than one would expect. So, I
> tried an older version of git, and to my surprise/delight,
> it was much faster (.2s). So, I bisected this issue also,
> and it seems that the "offending" commit is
> 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
I'm still working on changes to store references hierarchically in the
cache and read them lazily. I hope that it will help some scaling
problems with large number of refs.
Unfortunately I keep getting tangled up in side issues, so it is taking
a lot longer than expected. But there's still hope.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 15:42 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Christian Couder
In-Reply-To: <4E809AFE.6010901@alum.mit.edu>
On Monday, September 26, 2011 09:32:14 am Michael Haggerty
wrote:
> On 09/25/2011 10:43 PM, Martin Fick wrote:
> > A coworker of mine pointed out to me that a simple
> >
> > git checkout
> >
> > can also take rather long periods of time > 3 mins when
> > run on a repo with ~100K refs.
> >
> > While this is not massive like the other problem I
> > reported, it still seems like it is more than one
> > would expect. So, I tried an older version of git,
> > and to my surprise/delight, it was much faster (.2s).
> > So, I bisected this issue also, and it seems that the
> > "offending" commit is
>
> > 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
> I'm still working on changes to store references
> hierarchically in the cache and read them lazily. I
> hope that it will help some scaling problems with large
> number of refs.
>
> Unfortunately I keep getting tangled up in side issues,
> so it is taking a lot longer than expected. But there's
> still hope.
>
> Michael
Thanks Michael, I look forward to those changes. In the
meantime however, I will try to take advantage of the
current inefficiencies of large ref counts to attempt to
find places where there are obvious problems in the code
paths. I suspect that there are several commands in git
which inadvertently scan all the refs when they probably
shouldn't. Since this is likely very slow now, it should be
easy to find those, if it were faster, this might get
overlooked. I feel like git checkout is one of those cases,
it does not seem like git checkout should be affected by the
number of refs in a repo?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 15:48 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Julian Phillips
In-Reply-To: <CAGdFq_iuY0-PBDOmtz1pRvh6J9EDRiRJHsWkTN_cHjGU20PYTQ@mail.gmail.com>
On Monday, September 26, 2011 09:21:30 am Sverre Rabbelier
wrote:
> Heya,
>
> On Mon, Sep 26, 2011 at 17:15, Martin Fick
<mfick@codeaurora.org> wrote:
> > If this change does not actually speed things up,
> > should it be reverted? Or was there a bug in the
> > change that makes it not do what it was supposed to
> > do?
>
> It probably looks at the refs in refs/changes while it
> shouldn't, hence worsening your performance compared to
> not looking at those refs. I assume that it does improve
> your situation if you have all those refs under say
> refs/heads.
Hmm, I was thinking that too, and I just did a test.
Instead of storing the changes under refs/changes, I fetched
them under refs/heads/changes and then ran git 1.7.6 and it
took about 3 mins. Then, I ran the 1.7.7.rc0.73 with
c774aab98ce6c5ef7aaacbef38da0a501eb671d4 reverted and it
only took 13s! So, if this indeed tests what you were
suggesting, I think it shows that even in the intended case
this change slowed things down?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Sverre Rabbelier @ 2011-09-26 15:56 UTC (permalink / raw)
To: Martin Fick; +Cc: git, Julian Phillips
In-Reply-To: <201109260948.25312.mfick@codeaurora.org>
Heya,
On Mon, Sep 26, 2011 at 17:48, Martin Fick <mfick@codeaurora.org> wrote:
> Hmm, I was thinking that too, and I just did a test.
>
> Instead of storing the changes under refs/changes, I fetched
> them under refs/heads/changes and then ran git 1.7.6 and it
> took about 3 mins. Then, I ran the 1.7.7.rc0.73 with
> c774aab98ce6c5ef7aaacbef38da0a501eb671d4 reverted and it
> only took 13s! So, if this indeed tests what you were
> suggesting, I think it shows that even in the intended case
> this change slowed things down?
And if you run 1.7.7 without that commit reverted?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Thomas Rast @ 2011-09-26 16:25 UTC (permalink / raw)
To: Martin Fick; +Cc: Michael Haggerty, git, Christian Couder
In-Reply-To: <201109260942.08299.mfick@codeaurora.org>
Martin Fick wrote:
>
> I suspect that there are several commands in git
> which inadvertently scan all the refs when they probably
> shouldn't. [...] I feel like git checkout is one of those cases,
> it does not seem like git checkout should be affected by the
> number of refs in a repo?
git-checkout checks whether you are leaving any unreferenced
(orphaned) commits behind when you leave a detached HEAD, which
requires that it scan the history of all refs for the commit you just
left.
So unless you disable that warning it'll be pretty expensive
regardless.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] send-email: auth plain/login fix
From: Junio C Hamano @ 2011-09-26 16:38 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: joe, git
In-Reply-To: <1316879367-1182-1-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git send-email was not authenticating properly when communicating over
> TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
> e.g. the standard server setup under debian with exim4 and probably
> everywhere where system accounts are used.
Now that's a solution that makes me feel less dirty than
http://thread.gmane.org/gmane.comp.version-control.git/178818/focus=178824
even though, by forcing Authen::SASL::Perl to be used bypassing XS and
Cyrus variants, this _might_ be introducing regression for others. We'll
find out soon enough if anybody screams ;-)
I see you already researched previous discussion and have Joe Perches in
the loop; Thanks.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 16:38 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Julian Phillips
In-Reply-To: <CAGdFq_hRmSif4=V+9h8=S1fWfPCj+meRY8xGyfgv=SWk+DrBQw@mail.gmail.com>
On Monday, September 26, 2011 09:56:50 am Sverre Rabbelier
wrote:
> Heya,
>
> On Mon, Sep 26, 2011 at 17:48, Martin Fick
<mfick@codeaurora.org> wrote:
> > Hmm, I was thinking that too, and I just did a test.
> >
> > Instead of storing the changes under refs/changes, I
> > fetched them under refs/heads/changes and then ran git
> > 1.7.6 and it took about 3 mins. Then, I ran the
> > 1.7.7.rc0.73 with
> > c774aab98ce6c5ef7aaacbef38da0a501eb671d4 reverted and
> > it only took 13s! So, if this indeed tests what you
> > were suggesting, I think it shows that even in the
> > intended case this change slowed things down?
>
> And if you run 1.7.7 without that commit reverted?
Sorry, I probably confused things by mentioning 1.7.6, the
bad commit was way before that early 1.5 days...
As for 1.7.7, I don't think that exists yet, so did you mean
the 1.7.7.rc0.73 version that I mentioned above without the
revert? Strangely enough, that ends up being
1.7.7.rc0.72.g4b5ea. That is also slow with
refs/heads/changes > 3mins.
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] mergetool: Use args as pathspec to unmerged files
From: Junio C Hamano @ 2011-09-26 16:40 UTC (permalink / raw)
To: David Aguilar; +Cc: Jonathon Mah, git, Dan McGee
In-Reply-To: <20110925004459.GA19780@gmail.com>
David Aguilar <davvid@gmail.com> writes:
>> Ack from mergetool/difftool folks?
> ...
> Acked-by: David Aguilar <davvid@gmail.com>
>
> Being able to do "git mergetool -- subdir" is very nice!
> Thanks guys,
Thanks.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-26 16:49 UTC (permalink / raw)
To: Martin Fick; +Cc: Sverre Rabbelier, git
In-Reply-To: <201109261038.34527.mfick@codeaurora.org>
On Mon, 26 Sep 2011 10:38:34 -0600, Martin Fick wrote:
> On Monday, September 26, 2011 09:56:50 am Sverre Rabbelier
> wrote:
>> Heya,
>>
>> On Mon, Sep 26, 2011 at 17:48, Martin Fick
> <mfick@codeaurora.org> wrote:
>> > Hmm, I was thinking that too, and I just did a test.
>> >
>> > Instead of storing the changes under refs/changes, I
>> > fetched them under refs/heads/changes and then ran git
>> > 1.7.6 and it took about 3 mins. Then, I ran the
>> > 1.7.7.rc0.73 with
>> > c774aab98ce6c5ef7aaacbef38da0a501eb671d4 reverted and
>> > it only took 13s! So, if this indeed tests what you
>> > were suggesting, I think it shows that even in the
>> > intended case this change slowed things down?
>>
>> And if you run 1.7.7 without that commit reverted?
>
> Sorry, I probably confused things by mentioning 1.7.6, the
> bad commit was way before that early 1.5 days...
>
> As for 1.7.7, I don't think that exists yet, so did you mean
> the 1.7.7.rc0.73 version that I mentioned above without the
> revert? Strangely enough, that ends up being
> 1.7.7.rc0.72.g4b5ea. That is also slow with
> refs/heads/changes > 3mins.
Hmm ... something interesting is going on.
I created a little test repo with ~100k unpacked refs.
I tried "time git branch" with three versions of git, and I got (hot
cache times):
git version 1.7.6.1: ~1.2s
git version 1.7.7.rc3: ~1.2s
git version 1.7.7.rc3.1.gbc93f: ~40s
Where the third was with the commit reverted. That was almost 40s of
100% CPU - my poor laptop had to turn the fans up to noisy ...
> -Martin
--
Julian
^ permalink raw reply
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-26 16:49 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <CAP8UFD0PiiA9SxvOuuh4t8P96v+iaJ0TfcBr1-xjMh4TXBEONQ@mail.gmail.com>
Christian Couder schrieb:
> Hi,
>
> On Mon, Sep 26, 2011 at 1:48 PM, Georg-Johann Lay <spam@spam.com> wrote:
>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>> proceed.
>
> Perhaps you can try to install this module from CPAN:
>
> http://search.cpan.org/~mschwern/Alien-SVN-v1.6.12.1/
>
> or from it's github repo:
>
> https://github.com/schwern/alien-svn
Hi Christian,
thanks for that hint.
After getting that piece of software, running ./Build.PL and ./Build I just
don't know what to do next. The README doesn't say anything about how to use
the built modules or how to do an install.
As git-svn complains
...Can't locate SVN/Core.pm in @INC (@INC contains: ...
and
schwern-alien-svn-9298884>find . -name 'Core.pm'
./src/subversion/subversion/bindings/swig/perl/native/Core.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
the question is how to do the final trick of telling git how to use Core.pm
(and which of the two?) and do the connexion between git and alien-svn.
Sorry for the noob questions, never used perl or git before...
Johann
> Regards,
> Christian.
p.s. is it possible not to open quote e-mail addresses in mailing lists?
^ permalink raw reply
* Re: [PATCH/RFC 1/2] is_url: Remove redundant assignment
From: Junio C Hamano @ 2011-09-26 16:52 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Pang Yan Han, git, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin
In-Reply-To: <CALUzUxp-++A7azzimE1mjvPVoGxRM4rzYt9z66CmFb0B3vi7dQ@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Sun, Sep 25, 2011 at 1:06 PM, Pang Yan Han <pangyanhan@gmail.com> wrote:
>> Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
>> ---
>> url.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/url.c b/url.c
>> index 3e06fd3..d2e17e6 100644
>> --- a/url.c
>> +++ b/url.c
>> @@ -22,7 +22,6 @@ int is_url(const char *url)
>>
>> if (!url)
>> return 0;
>> - url2 = url;
>> first_slash = strchr(url, '/');
>>
>> /* Input with no slash at all or slash first can't be URL. */
>
> Looks correct. Perhaps you could mention in the patch message that
>
> There are no operations on url2 until another assignment to it later
> at line 41.
The looks correct, so I'll queue it, but it looks like that the function
is implemented in an overly complicated way.
Why aren't we checking from left to right in a single pass, perhaps like
this?
/* Make sure it is of form "scheme://something" */
int is_url(const char *url)
{
/* Is "scheme" part reasonable? */
if (!url || !is_urlschemechar(1, *url++))
return 0;
while (*url && *url != ':') {
if (!is_urlschemechar(0, *url++))
return 0;
}
/* We've seen "scheme"; we want colon-slash-slash */
return (url[0] == ':' && url[1] == '/' && url[2] == '/');
}
^ permalink raw reply
* Re: [PATCH] send-email: auth plain/login fix
From: Joe Perches @ 2011-09-26 16:59 UTC (permalink / raw)
To: Junio C Hamano, Graham Barr; +Cc: Zbigniew Jędrzejewski-Szmek, git
In-Reply-To: <7v8vpb5kea.fsf@alter.siamese.dyndns.org>
On Mon, 2011-09-26 at 09:38 -0700, Junio C Hamano wrote:
> Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
>
> > git send-email was not authenticating properly when communicating over
> > TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
> > e.g. the standard server setup under debian with exim4 and probably
> > everywhere where system accounts are used.
>
> Now that's a solution that makes me feel less dirty than
>
> http://thread.gmane.org/gmane.comp.version-control.git/178818/focus=178824
Dirty is dirty. I don't see this as better or worse really,
but thanks Zbigniew for bringing it up again.
It'd be best if Graham Barr, the module author (cc'd),
could respond to the issue.
cheers, Joe
> even though, by forcing Authen::SASL::Perl to be used bypassing XS and
> Cyrus variants, this _might_ be introducing regression for others. We'll
> find out soon enough if anybody screams ;-)
>
> I see you already researched previous discussion and have Joe Perches in
> the loop; Thanks.
^ permalink raw reply
* emacs as mergetool
From: Thomas Koch @ 2011-09-26 16:21 UTC (permalink / raw)
To: git
Hi,
would you be so kind and give an emacs newbie (and vim refugee) a hint about
using emacs as mergetool?
- Which one? ediff vs. emerge (I don't bother learning, just give me the best)
- I'd like to have a setup, where I can run mergetool with different options
to
- connect to a running emacs server
- run emacs in X
- or in the terminal (default)
- Is it possible to resolve all conflicting files in one session instead of
having emacs called again for every file?
- Do you know a tutorial on emacs as a mergetool?
Thank you,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: subversion-perl missing
From: Jakub Narebski @ 2011-09-26 17:17 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: Christian Couder, git
In-Reply-To: <4E80AD1B.3080700@gjlay.de>
Georg-Johann Lay writes:
> Christian Couder schrieb:
> > On Mon, Sep 26, 2011 at 1:48 PM, Georg-Johann Lay <spam@spam.com> wrote:
> > > Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
> > > that in subversion.tigris.org, so that I am stuck and need some hints on how to
> > > proceed.
> >
> > Perhaps you can try to install this module from CPAN:
> >
> > http://search.cpan.org/~mschwern/Alien-SVN-v1.6.12.1/
> >
> > or from it's github repo:
> >
> > https://github.com/schwern/alien-svn
>
> Hi Christian,
>
> thanks for that hint.
>
> After getting that piece of software, running ./Build.PL and ./Build I just
> don't know what to do next. The README doesn't say anything about how to use
> the built modules or how to do an install.
If you don't have admin privileges on the box, the best solution would
be to use local::lib[1] to install Perl modules in your home directory
for you (#perl IRC channel on FreeNode, or perlmonks are really helpful).
I really recommend it, together with cpanm[2] (which can configure
local::lib for you, via --local-lib option), though the latter is not
necessary.
[1]: http://search.cpan.org/~apeiron/local-lib-1.008004/lib/local/lib.pm
[2]: http://search.cpan.org/~miyagawa/App-cpanminus-1.4008/bin/cpanm
If you have admin privileges, I think the best solution would be
either find repository which has subversion-perl that matches your
version of Subversion, or compile subversion-perl from a source
package... though this might be more difficult, it has advantage of
being in package management.
> As git-svn complains
>
> ...Can't locate SVN/Core.pm in @INC (@INC contains: ...
>
> and
>
> schwern-alien-svn-9298884>find . -name 'Core.pm'
> ./src/subversion/subversion/bindings/swig/perl/native/Core.pm
> ./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
>
> the question is how to do the final trick of telling git how to use Core.pm
> (and which of the two?) and do the connexion between git and alien-svn.
>
> Sorry for the noob questions, never used perl or git before...
You have to install subversion-perl somewhere, not only build it.
Though you could fiddle with PERL5LIB (which is PATH-like environmtne
variable to specify where to search for Perl modules) to make Perl
find your built but not installed Alien::SVN.
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] send-email: auth plain/login fix
From: Jakub Narebski @ 2011-09-26 17:24 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: gitster, joe, git
In-Reply-To: <1316879367-1182-1-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git send-email was not authenticating properly when communicating over
> TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
> e.g. the standard server setup under debian with exim4 and probably
> everywhere where system accounts are used.
>
> The solution comes from this forum thread:
> http://www.perlmonks.org/?node_id=904354
Signoff?
> ---
> git-send-email.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git git-send-email.perl git-send-email.perl
> index 37dfbe7..100fbd9 100755
> --- git-send-email.perl
> +++ git-send-email.perl
> @@ -27,6 +27,7 @@ use Term::ANSIColor;
> use File::Temp qw/ tempdir tempfile /;
> use File::Spec::Functions qw(catfile);
> use Error qw(:try);
> +use Authen::SASL qw(Perl);
> use Git;
> use MIME::Base64;
Shouldn't we load Authen::SASL only when it is necessary (on demand),
rather than forcing everybody who use send-email (even if via
sendmail, or with other authentication support)?
We load Net::SMTP::SSL only on demand.
It would be:
require Authen::SASL;
Authen::SASL->import(qw(Perl));
--
Jakub Narębski
^ permalink raw reply
* Re: emacs as mergetool
From: Rémi Vanicat @ 2011-09-26 17:28 UTC (permalink / raw)
To: git
In-Reply-To: <201109261821.28382.thomas@koch.ro>
Thomas Koch <thomas@koch.ro> writes:
> Hi,
>
> would you be so kind and give an emacs newbie (and vim refugee) a hint about
> using emacs as mergetool?
In fact, I use magit like that: after the merge, if there was a
conflict, I launch magit (M-x magit) and go on the unmerged file, then I
use "e" (magit-ediff) to merge them. ediff merge tool is self
documented, and I never needed more than its documentation.
Of course for this you need to install magit, and you don't really use
Emacs as mergetool...
--
Rémi Vanicat
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-26 17:47 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Christian Couder
In-Reply-To: <CAP8UFD3TWQHU0wLPuxMDnc3bRSz90Yd+yDMBe03kofeo-nr7yA@mail.gmail.com>
On Monday, September 26, 2011 06:41:04 am Christian Couder
wrote:
> On Sun, Sep 25, 2011 at 10:43 PM, Martin Fick
<mfick@codeaurora.org> wrote:
> > A coworker of mine pointed out to me that a simple
> >
> > git checkout
> >
> > can also take rather long periods of time > 3 mins when
> > run on a repo with ~100K refs.
>
> Are all these refs packed?
I think so, is there a way to find out for sure?
-Martin
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Jakub Narebski @ 2011-09-26 17:48 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git, Linux Kernel
In-Reply-To: <CACBZZX77ZhdS1cyiYpjJcuvSnJsv15FUumPWeZOcwh_b41c2FQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
>
> > Also the following public repositories all have a copy of the v1.7.7-rc3
> > tag and the master branch that the tag points at:
>
> The 1.7.7-rc* series still doesn't compile on older Red Hat machines
> because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
> in it.
>
> Could you please include that in the final 1.7.7? It would be a PITA
> to have to work around that.
It looks like I was too optimistic in
"Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)"
http://thread.gmane.org/gmane.comp.version-control.git/181885/focus=181935
JN> Yes, that is what I mean... but that it is only because I use old
JN> version of asciidoc (7.1.2).
JN>
JN> "make doc" (which is part of "make rpm") fails on my box with
JN>
JN> ASCIIDOC gitnamespaces.html
JN> ERROR: gitnamespaces.txt: line 9: second section must be named SYNOPSIS
JN> make[1]: *** [gitnamespaces.html] Error 1
JN>
JN> > If the reason the documentation fix for "master" is needed is because a
JN> > new feature scheduled for the upcoming release has broken documentation,
JN> > then wouldn't we need the fix before the release, whether you are working
JN> > on your patch or not? How can it be not urgent if that is the case?
JN> >
JN> > On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
JN> > the lack of the workaround, but if distros need the workaround, then the
JN> > time to apply it is now, not post release.
JN>
JN> I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
JN> which fixed the issue with "Synopsis" section was released 2009-05-24:
JN>
JN> http://www.methods.co.nz/asciidoc/CHANGELOG.html
JN>
JN> Version 8.4.5 (2009-05-24)
JN> --------------------------
JN> Additions and changes
JN> ~~~~~~~~~~~~~~~~~~~~~
JN>
JN> * Added manpage "Name" and "Synopsis" section title customization to
JN> languages configuration files.
JN> * "Synopsis" manpage section no longer mandatory.
JN> [...]
--
Jakub Narębski
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Junio C Hamano @ 2011-09-26 17:49 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX77ZhdS1cyiYpjJcuvSnJsv15FUumPWeZOcwh_b41c2FQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Also the following public repositories all have a copy of the v1.7.7-rc3
>> tag and the master branch that the tag points at:
>
> The 1.7.7-rc* series still doesn't compile on older Red Hat machines
> because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
> in it.
>
> Could you please include that in the final 1.7.7? It would be a PITA
> to have to work around that.
I somehow got an impression from an other earlier thread that this only
affect ancient and abandoned releases of some distros.
Will merge. Thanks for prodding.
^ permalink raw reply
* Re: [PATCH 2/2] templates/hooks--*: don't refer to contrib hooks
From: Junio C Hamano @ 2011-09-26 17:52 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20110926125932.27854.qmail@804c778e7e6607.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Simplify the sample post-receive hook to not refer to some location of a
> contrib hook that might be installed in different locations on different
> systems. Instead simply provide a sample file that does nothing just as
> the post-commit sample hook.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--post-receive.sample | 12 ++----------
> 1 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
> index 7a83e17..5b1771f 100755
> --- a/templates/hooks--post-receive.sample
> +++ b/templates/hooks--post-receive.sample
> @@ -2,14 +2,6 @@
> #
> # An example hook script for the "post-receive" event.
> #
> +# To enable this hook, rename this file to "post-receive".
>
> +: Nothing
I removed the "-" lines above. Looking at the result, I really have to
wonder if it makes much sense to keep the file here. It is not even an
example anymore, and the user does not gain anything by enabling it,
following the suggestion.
Let's instead remove the file altogether, Ok?
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-26 18:03 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1aec7c1qq0n56.sxybjnsj6ngr$.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Konstantin Khomoutov wrote:
>
>>>>> From what I read, detached heads are subject to garbage collection.
>>>>
>>>> No, HEAD is protected against garbage collecting. To be sure you
>>>> should name a branch when switching branches, though reflog would
>>>> protect you for 30 days (by default) even if you don't do that.
>>>
>>> So Git doesn't really support anonymous branching as part of a normal
>>> workflow.
>>
>> I perceive a certain logical fallacy here: you cannot switch between
>> anything anonymous because to switch, you should somehow identify
>> something to switch to--a name in whatever sense we put into this word.
>
> In Mercurial, you can just update to a particular changeset (and you
> identify that changeset by repository-local revision number or globally
> unique ID) and then commit again. The point is that there's no need to
> give a label to a head in Mercurial (although you can if you want to, using
> Mercurial bookmarks, which are basically the same as what Git uses).
>
> Here's an example of anonymous branching:
>
> c:\test>hg init
>
> c:\test>echo test>foo
>
> c:\test>hg commit --addremove -m initial
> adding foo
>
> c:\test>echo first>>foo
>
> c:\test>hg commit -m first
>
> c:\test>hg log
> changeset: 1:3e895ec28d6c
> tag: tip
> user: tactical
> date: Mon Sep 26 01:39:46 2011 +0100
> summary: first
>
> changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> c:\test>hg update 0
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> c:\test>echo second>>foo
>
> c:\test>hg commit -m second
> created new head
>
> c:\test>hg glog
> @ changeset: 2:35c82a7e7de1
> | tag: tip
> | parent: 0:b51644bb3450
> | user: tactical
> | date: Mon Sep 26 01:40:10 2011 +0100
> | summary: second
> |
> | o changeset: 1:3e895ec28d6c
> |/ user: tactical
> | date: Mon Sep 26 01:39:46 2011 +0100
> | summary: first
> |
> o changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> I now have two anonymous branches, and these will never be garbage
> collected. I can easily update to either branch with "hg update 1" or "hg
> update 2" (or "hg update 0" again, if i want to create yet another
> anonymous branch).
In my opinion the need to examine either log ('hg glog') or heads
('hg heads'?) to see how to switch to anonymous branch is a PITA
that far outweights the need to name branches (to give a temporary,
local-only branch name) in Git.
Nb. by using "detached HEAD" for anonymous branch I meant the
following:
$ git checkout --detach
$ ...
$ <work on detached head>
worth saving?
Y. $ git branch -b t foo/temp
$ git checkout <other branch>
N. $ git checkout <other branch>
> > The branch names is just a way to not mess with
> > SHA-1 names of commits (and to have references to those commits to keep
> > them out of consideration for garbage collection).
> > Hence the idea to demand support for anonymous branches in Git's model
> > is just unfounded.
>
> I think it's simply a weakness of Git. There are zero problems with
> anonymous branching in Mercurial, and it's a very powerful and simple
> system.
IMVVVHO it is just remains of bad initial design decision of Mercurial
about representing branches ;-PPPPPPP
Only now Mercurial has something (transferable bookmarks) which
approaches flexibility and usability of Git branches. It took them
how long... and even then there is a [supposedly] user-friendly but
flexibility-reducing notion that branch (bookmark) names are global.
Not that Git didn't and doesn't have its share of bad design decisions
(like autimatically committing a merge).
--
Jakub Narębski
^ 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