* Re: Windows support
From: Stephen Cuppett @ 2007-07-25 16:58 UTC (permalink / raw)
To: Steffen Prohaska, git
In-Reply-To: <693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de>
On 7/25/07, Steffen Prohaska <prohaska@zib.de> wrote:
> Is it just that windows developer hate cygwin because it's to
> complex to install or is there any severe limitation?
> functionality? stability? performance?
I actually have no problems with cygwin and find it works pretty well
with git repositories. Starting the xserver to run git-gui is pretty
annoying though. Windows-based development teams are going to expect
easy access to those kinds of tooling. Otherwise, the champion will
be pushing a type of workflow change that would hinder adoption anyway
and leave a sour taste for a long time.
In addition, performance is atrocious. In my particular case I have
an older P4 running F7 and a newer machine running Windows and cygwin.
On a pserver based cvsimport of a large, enterprise project, Linux
was able to generate the full history in 4 hours, cygwin took 3 and a
half days. When I sync up every now and then, typical times for
windows are 25 minutes and Linux is around 4. That should give you an
idea of what kind of multiplier we are talking about.
I don't know if the performance problems are cygwin or not. More
knowledgeable people might be able to answer, it's just what I'm
observing right now. It could be more fundamental to the types of
access being performed en masse on inode-based versus NTFS systems.
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-25 17:13 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707250715p7c183a81vc78f641eef493777@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > FYI, I'm working on getting rid of msys requirement from mingw port. I
> > > can't tell you how long it would take though. Could be one month or two.
> >
> > Is there a repo out there?
>
> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox
>
> There are some patches on mob I have not merged to gitbox branch yet.
Thanks,
Dscho
^ permalink raw reply
* Re: Windows support
From: Daniel Barkalow @ 2007-07-25 17:41 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com>
On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> How serious are you guys about Windows support?
> I'm talking fully-functional port, not Cygwin.
> I did a lot of searching for a new SCM to switch to (from Perforce).
> And Git is my #1 choice. I love it's internals design and it's
> expressive power. I've also tested git-p4 and it has worked like a
> charm with my depot (with few tweaks that I may contribute later).
> But I do all my work on Windows so I need Git-For-Windows-Done-Right :-).
> The current mingw port is not there yet.
>
> Transition to the new SCM must happen now, so basically I have 2 choices:
> 1. Survive for a few months with the current CygWin port of Git
> knowing that Windows support is coming
> 2. Use another SCM (#2 is Mercurial, #3 is Monotone)
>
> I'd realy love to do #1, but I need to know how long do I have to wait.
If the issue is the shell scripts, replacing those with C code is coming
along nicely; there's a big section (fetch and everything it uses) which
is ready to go after 1.5.3 comes out, and I believe a number of the other
core parts are being taken care of in the same sort of time frame by the
GSoC people.
I've also been working on reducing the fork/exec usage, if that's the
issue, but I'm not sure how much of that is left to do or how long it will
take.
(Personally, I don't touch windows at all, but I have been working on
fixing things that seem to be problems for porting to windows, which may
be relevant)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Windows support
From: Russ Dill @ 2007-07-25 17:56 UTC (permalink / raw)
To: git
In-Reply-To: <316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com>
Stephen Cuppett <cuppett <at> gmail.com> writes:
> I actually have no problems with cygwin and find it works pretty well
> with git repositories. Starting the xserver to run git-gui is pretty
> annoying though. Windows-based development teams are going to expect
> easy access to those kinds of tooling. Otherwise, the champion will
> be pushing a type of workflow change that would hinder adoption anyway
> and leave a sour taste for a long time.
I have the version of git that came with cygwin, and I never have to run an X
server to run git-gui or gitk.
Personally, I can't imagine running git without cygwin. Course, I want my
desktop to feel as much like unix as possible. My experience with git under
cygwin has been excellent. My only gripe has to do with CRLF. The repository has
everything checked in with dos line endings, I'd like to check everything out
with unix line endings, and then check it back in with dos line endings. I hate
seeing the ^M's everywhere.
> In addition, performance is atrocious. In my particular case I have
> an older P4 running F7 and a newer machine running Windows and cygwin.
> On a pserver based cvsimport of a large, enterprise project, Linux
> was able to generate the full history in 4 hours, cygwin took 3 and a
> half days. When I sync up every now and then, typical times for
> windows are 25 minutes and Linux is around 4. That should give you an
> idea of what kind of multiplier we are talking about.
Granted, the performance isn't equal to git running on a real unix, but compared
to working with SVN under win32, I would say it performs quite well.
^ permalink raw reply
* Re: Windows support
From: Linus Torvalds @ 2007-07-25 18:43 UTC (permalink / raw)
To: Stephen Cuppett; +Cc: Steffen Prohaska, git
In-Reply-To: <316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com>
On Wed, 25 Jul 2007, Stephen Cuppett wrote:
>
> I don't know if the performance problems are cygwin or not. More
> knowledgeable people might be able to answer, it's just what I'm
> observing right now. It could be more fundamental to the types of
> access being performed en masse on inode-based versus NTFS systems.
I think cygwin may add some overhead, but people should really realize
that Linux is quite often an order of magnitude faster (or more) than
other systems on some very basic operations.
That's especially true for filesystem operations. We really are just that
good.
Really simple things like stat/open/read/write/close are just damn fast on
Linux. To the point where you really do notice it when you compare to
other systems. If something takes hours on Linux, and it's very
filesystem-intensive, I'm not at all surprised that it might take days on
Windows.
(OS X is probably better than Windows when it comes to filesystem ops, but
their memory management absolutely sucks, and I can pretty much guarantee
that their filesystem operation latency doesn't hold a candle to Linux,
so while I'd expect git to perform "pretty well" on OS X, it's still
going to be slower than on Linux)
Linux really *can* be that much faster. You may not see it as much on some
other loads, where most of the load is about normal user code, and system
call performance is likely to be just a small fraction, but for git, most
of what it does is filesystem interactions (I used to think that SHA1's
would be noticeable - they're not, and while zlib overhead *can* be
noticeable, it usually isn't a big deal except for some very specific
cases).
But I bet that git ends up being faster on Windows than many other SCM's
are (on Windows). Going native will help, and avoiding things like shell
scripting will help a *lot*, but it's still always going to be slower on
Windows than it is on Linux. And that is not about anything else than the
fact that Linux simply kicks *ss on filesystem ops.
So for doing things like big imports, you might well want to do them on
Linux. But that doesn't mean that git will suck on Windows for normal
operations.
(It will just not be so *blazingly* fast, ie things like "git status" will
generally not be instantaneous).
Linus
^ permalink raw reply
* RE: Re: Windows support
From: Medve Emilian-EMMEDVE1 @ 2007-07-25 19:04 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070725T195200-46@post.gmane.org>
Hi Russ,
Try playing with the core.autocrlf config option.
Cheers,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Russ Dill
Sent: Wednesday, July 25, 2007 12:56 PM
To: git@vger.kernel.org
Subject: Re: Windows support
Stephen Cuppett <cuppett <at> gmail.com> writes:
> I actually have no problems with cygwin and find it works pretty well
> with git repositories. Starting the xserver to run git-gui is pretty
> annoying though. Windows-based development teams are going to expect
> easy access to those kinds of tooling. Otherwise, the champion will
> be pushing a type of workflow change that would hinder adoption anyway
> and leave a sour taste for a long time.
I have the version of git that came with cygwin, and I never have to run
an X
server to run git-gui or gitk.
Personally, I can't imagine running git without cygwin. Course, I want
my
desktop to feel as much like unix as possible. My experience with git
under
cygwin has been excellent. My only gripe has to do with CRLF. The
repository has
everything checked in with dos line endings, I'd like to check
everything out
with unix line endings, and then check it back in with dos line endings.
I hate
seeing the ^M's everywhere.
> In addition, performance is atrocious. In my particular case I have
> an older P4 running F7 and a newer machine running Windows and cygwin.
> On a pserver based cvsimport of a large, enterprise project, Linux
> was able to generate the full history in 4 hours, cygwin took 3 and a
> half days. When I sync up every now and then, typical times for
> windows are 25 minutes and Linux is around 4. That should give you an
> idea of what kind of multiplier we are talking about.
Granted, the performance isn't equal to git running on a real unix, but
compared
to working with SVN under win32, I would say it performs quite well.
^ permalink raw reply
* Re: Re: Windows support
From: Russ Dill @ 2007-07-25 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27012EDD12@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 <Emilian.Medve <at> freescale.com> writes:
>
> Hi Russ,
>
> Try playing with the core.autocrlf config option.
>
It seems to do the exact opposite of what I would like. My repository is
imported from SVN with git-svn and all the text files have dos line endings. I
would like to checkout with unix line endings, and checkin with dos line endings.
^ permalink raw reply
* Re: [ANNOUNCE]: PyGit and libgit-thin
From: Yann Dirson @ 2007-07-25 19:50 UTC (permalink / raw)
To: Luiz Fernando N. Capitulino; +Cc: git, Shawn O. Pearce
In-Reply-To: <e28f90730707230535q33658efevf665d795cf1df87c@mail.gmail.com>
On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:
> Now I need to know whether this' really useful to other people and
> if so, what would be missing for you to start using it.
The python module would really be useful to StGIT. Currently, an
stgit commands typically has to fork several git commands at least,
and using library calls instead would surely help with the
performance.
I had a quick look at the current pygit API (as described in the
README), and I find the current revlist one somewhat confusing. Why
using post-contructor methods, and not using named args in the
constructor itself ?
That is, the example reading:
>>> rv = repo.revlist()
>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
>>> rv.count = 10
>>> rv.show_merges()
>>> for commit in rv:
... print commit.id()
...
would be IMHO much nicer to use as:
>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),
... count = 10,
... show_merges = true)
...
>>> for commit in rv:
... print commit.id()
...
What do you think ?
Best regards,
--
Yann
^ permalink raw reply
* Re: [ANNOUNCE]: PyGit and libgit-thin
From: David Kastrup @ 2007-07-25 19:57 UTC (permalink / raw)
To: Yann Dirson; +Cc: Luiz Fernando N. Capitulino, git, Shawn O. Pearce
In-Reply-To: <20070725195010.GA30277@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> I had a quick look at the current pygit API (as described in the
> README), and I find the current revlist one somewhat confusing. Why
> using post-contructor methods, and not using named args in the
> constructor itself ?
>
> That is, the example reading:
>
>>>> rv = repo.revlist()
>>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
>>>> rv.count = 10
>>>> rv.show_merges()
>>>> for commit in rv:
> ... print commit.id()
> ...
>
>
> would be IMHO much nicer to use as:
>
>>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),
> ... count = 10,
> ... show_merges = true)
> ...
>>>> for commit in rv:
> ... print commit.id()
> ...
>
>
> What do you think ?
Nicer to use if the commands and their options originate from withing
Python. But if Python parses arguments from somewhere else and passes
them on, the former interface leads to much cleaner code AFAICS.
Pasting together a named argument call piecemeal is not going to be
pretty, I should think.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Wrong time in git-log when using right/ timezone
From: Jan Hudec @ 2007-07-25 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Peter Hartlich, git
In-Reply-To: <7vk5sx77me.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
On Wed, Jul 18, 2007 at 13:57:13 -0700, Junio C Hamano wrote:
> No, I do not think the wackiness is from Germans.
>
> Using right/ perhaps without realizing the differences between
> TZ=right/Europe/Berlin and TZ=Europe/Berlin is probably the
> source of confusion.
>
> I do not offhand know what role "leap second adjustment" should
> play in the context of converting from Unix time we store in git
> commit objects to human readable role. As far as I understand,
> the returned timestamp from time(2), which we record in commit
> objects, is already "leap second adjusted".
I can attempt a brief explanation if anyone is (still) interested.
Leap seconds are added iregularly, because Earth rotation is slightly
irregular. Therefore some time calculations require lookup into a table of
leap seconds:
- If you include leap seconds in the timer, converting to date+time does,
while time difference does not. This is what the right/ timezones use.
- If you exclude leap seconds from the timer, time difference does, but
converting to date+time does not. This is what the normal timezones use.
Obviously, the two approaches don't play well together. POSIX chose the
later, likely because it's much more common to want to know date+time for
some moment, than to calculate several year long time interval with second
precision (because so far there have been at most 2 seconds difference per
year).
Note, that the former approach allows you to talk about time 65936023 seconds
from now, but not what date and time it will be, while the later allows you
to talk about 2437-11-05 16:12:05, but not how many seconds are left until
than.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* easy repository initialization that turned out not to be that easy
From: Steffen Prohaska @ 2007-07-25 20:05 UTC (permalink / raw)
To: Git Mailing List
I stumbled about some tasks that I expected to be easy but
turned out not to be that easy ...
(with git version 1.5.3.rc2.29.gc4640f)
1) How can I switch a private repository to shared as if it
was created by 'git-init --shared' in the first place?
Just executing 'git-init --shared' in the repo doesn't
adjust permissions as needed.
Cloning it to shared doesn't work either because the meaning
of 'git-clone --bare --shared' is different from
'git-init --shared'.
So I created a fresh repository
mkdir shared.git
cd shared.git
git --bare init --shared
and tried to naively fetch all by executing
git fetch ../private.git
Hmm... it does a lot of things, but I ended without branches.
fetch apparently has nothing like '--all'.
... but push has, so I finally did
cd ../private.git
git push --all ../shared.git
git push --tags ../shared.git
Note, 'git push --all --tags' refused to work, so I needed
to push branches and tags separately.
Is it really that hard, or did I miss something?
2) How can I set up an empty bare repository that shares
objects with an existing repository? I'd like to do that
to save space and bandwidth.
I started to search for something like 'git init --reference'
or 'git init -l', similar to what 'git clone' provides.
I don't remember all approaches I tried, but finally I used
git clone --bare -l existing.git new.git
cd new.git
mv refs/head/master .
rm -rf refs/heads/* refs/tags/*
mv master refs/heads
I remember that I needed to leave the master in place because
otherwise a 'git push' didn't recognize that objects are already
present and transferred everything, which is quite annoying over
a slower network connection. With master in place the first push
to new.git worked as expected. Only the additional objects were
sent.
Did I miss something?
Steffen
^ permalink raw reply
* Re: index-pack died on pread
From: Michal Rokos @ 2007-07-25 20:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: GIT
In-Reply-To: <81b0412b0707230832w438613d0rdaa8dc97013962a6@mail.gmail.com>
Alex,
On 7/23/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/23/07, Michal Rokos <michal.rokos@gmail.com> wrote:
> > fatal: cannot pread pack file: No such file or directory (n=0,
> > errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
> > fatal: index-pack died with error code 128
>
> strange. pread(2) should not return ENOENT. Not in HP-UX
> not anywhere.
>
> Could you recompile with NO_PREAD=1 and try again?
> Maybe HP-UX pread(2) implementation is just broken.
When I tried to recompile with NO_PREAD=1 the problem disappeared.
Do you want me to try something more with it?
Michal
^ permalink raw reply
* Re: easy repository initialization that turned out not to be that easy
From: Johannes Schindelin @ 2007-07-25 20:15 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <0EAD32C5-11DA-4B99-919D-87C0006A389C@zib.de>
Hi,
On Wed, 25 Jul 2007, Steffen Prohaska wrote:
> Cloning it to shared doesn't work either because the meaning of
> 'git-clone --bare --shared' is different from 'git-init --shared'.
Yes, I lamented on that already. But we cannot change that. Too many
users.
> mkdir shared.git
> cd shared.git
> git --bare init --shared
>
> and tried to naively fetch all by executing
>
> git fetch ../private.git
Almost. "git fetch" does not store anything by default, so you have to do
something like
$ git config remote.origin.url ../private.git
$ git config remote.origin.fetch 'refs/*:refs/*'
$ git fetch
Eventually, I would like that to be available with
$ git remote add --mirror fetch ../private.git
If nobody beats me to it, I'll do it later today.
Ciao,
Dscho
^ permalink raw reply
* Re: submodule init problem
From: Lars Hjemli @ 2007-07-25 20:25 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, Johannes Schindelin, git, Ricky Nite,
Chris Larson
In-Reply-To: <20070725081508.GN1591MdfPADPa@greensroom.kotnet.org>
On 7/25/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
> > Ok, this appears it most likely to be related to the fact that
> > one is a prefix of the other in problematic case.
>
> Yes, this has been noted before and Chris Larson sent in a patch,
> but he didn't follow up on it.
The following seems to work (in my limitied testing):
eol='$'
git config --get-regexp '^submodule\..*\.path$' "^$1$eol"
--
larsh
^ permalink raw reply
* Re: submodule init problem
From: Johannes Schindelin @ 2007-07-25 20:31 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Junio C Hamano, git, Ricky Nite, Chris Larson
In-Reply-To: <8c5c35580707251325i2633777pdd7604b541506533@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Lars Hjemli wrote:
> On 7/25/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> > On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
> > > Ok, this appears it most likely to be related to the fact that
> > > one is a prefix of the other in problematic case.
> >
> > Yes, this has been noted before and Chris Larson sent in a patch,
> > but he didn't follow up on it.
>
> The following seems to work (in my limitied testing):
>
> eol='$'
> git config --get-regexp '^submodule\..*\.path$' "^$1$eol"
Ah, now I get it. You are looking for the _key_ whose value is "$1". But
then you really should use "^$1$", and not just "$1", otherwise you will
get unintended behaviour when one submodule's name is a substring of
another submodule's name.
And you do not need the eol hack.
Ciao,
Dscho
^ permalink raw reply
* Re: submodule init problem
From: Lars Hjemli @ 2007-07-25 20:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, Junio C Hamano, git, Ricky Nite, Chris Larson
In-Reply-To: <Pine.LNX.4.64.0707252129150.14781@racer.site>
On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 25 Jul 2007, Lars Hjemli wrote:
> > eol='$'
> > git config --get-regexp '^submodule\..*\.path$' "^$1$eol"
>
> Ah, now I get it. You are looking for the _key_ whose value is "$1".
Yes
> And you do not need the eol hack.
Hmm, I tried misc. quoting/escaping without success, care to educate me?
--
larsh
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Linus Torvalds @ 2007-07-25 20:40 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Johannes Schindelin, Marius Storm-Olsen, Alex Riesen,
Junio C Hamano, Shawn O. Pearce, Julian Phillips
In-Reply-To: <200707251205.48235.andyparkins@gmail.com>
On Wed, 25 Jul 2007, Andy Parkins wrote:
>
> I don't disagree with you at all - it is completely ridiculous for Windows
> users to moan about lack of Windows support without contributing any help.
> However, I think there is a good reason.
>
> I think it's a chicken and egg problem. The only reason I started making
> (small) contributions to git was because I was using it already.
I think this is 100% true, and worth repeating.
A lot of people seem to think that open source is about having lots of
people help with the project, and that development happens much faster
that way.
But what people often seem to miss is that pretty much all projects
didn't start out "open source". They *all* started out as somebodys
personal project (where "somebody" could be a small group, not just an
individual, of course), and while maybe the _license_ was open source from
the beginning, you cannot get away from the fact that in order to actually
be developed as open source, in the end some *individual* has to just do
it.
No project ever gets useful help until it's already useful. Being open
source doesn't get you past that hump - it only helps you *after* you've
already gotten past it.
Now, admittedly, I think one issue with Windows is that the "hump" is
simply much bigger. The initial cost (not necessarily in money, but in
effort) of getting involved in a development process is just a *lot*
higher for Windows users than it is for just about any UNIX.
If you're on some unix platform, the cost of getting involved is basically
that the project should already work to some degree, and then there may be
some relatively *trivial* issues with making sure that you've got a
compiler installed and the basic libraries. But that's really quite easy
on just about any UNIX, to the point that most people don't even have to
think about it.
In contrast, on Windows that "hump" is a whole lot harder. You don't just
have to have a compiler, you have to have some *specific* compiler,
because under Windows, they all have different development environments,
and few projects support them all.
So you have a double whammy: not only are people doing less development on
Windows to start with (so the project itself is likely not as usable), but
something as totally *trivial* as getting a simple C development
environment isn't even trivial. And git makes it worse by requiring a very
odd component (in Windows terms): the shell.
I really hope we'll get the the C rewrite merged soon. Especially the big
ones, ie commit / merge / am / clone / fetch. Those are the complex ones
that it's hard to get excited about when they don't work. Once those work
well, you could probably use git pretty completely even without shell,
even if you'd be missing a few features - and those features would now be
small enough that a relative beginner can cut their teeth on them.
The good news seems to be that most of those big scripts already exist in
a C version, so it's not like it's some utopian dream any more.
But getting a development environment is still much more painful under
Windows than just about anywhere else.
Linus
^ permalink raw reply
* Re: index-pack died on pread
From: Alex Riesen @ 2007-07-25 20:48 UTC (permalink / raw)
To: Michal Rokos; +Cc: GIT, Junio C Hamano, Linus Torvalds
In-Reply-To: <333e1ca10707251307k21b5f58bjb8e5803173e3d9b3@mail.gmail.com>
Michal Rokos, Wed, Jul 25, 2007 22:07:50 +0200:
> On 7/23/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> >On 7/23/07, Michal Rokos <michal.rokos@gmail.com> wrote:
> >> fatal: cannot pread pack file: No such file or directory (n=0,
> >> errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
> >> fatal: index-pack died with error code 128
> >
> >strange. pread(2) should not return ENOENT. Not in HP-UX
> >not anywhere.
> >
> >Could you recompile with NO_PREAD=1 and try again?
> >Maybe HP-UX pread(2) implementation is just broken.
>
> When I tried to recompile with NO_PREAD=1 the problem disappeared.
I think that's a fair indication for HP-UX has a broken pread(2).
> Do you want me to try something more with it?
No. Put NO_PREAD=1 in your config.mak on HP-UX.
^ permalink raw reply
* Re: submodule init problem
From: Johannes Schindelin @ 2007-07-25 20:50 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Junio C Hamano, git, Ricky Nite, Chris Larson
In-Reply-To: <8c5c35580707251340n2f1a9fd2j5fdf322277d68d26@mail.gmail.com>
Hi,
On Wed, 25 Jul 2007, Lars Hjemli wrote:
> On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 25 Jul 2007, Lars Hjemli wrote:
> > > eol='$'
> > > git config --get-regexp '^submodule\..*\.path$' "^$1$eol"
> >
> > Ah, now I get it. You are looking for the _key_ whose value is "$1".
>
> Yes
>
> > And you do not need the eol hack.
>
> Hmm, I tried misc. quoting/escaping without success, care to educate me?
I already did ;-I "^$1$"
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE]: PyGit and libgit-thin
From: Luiz Fernando N. Capitulino @ 2007-07-25 20:55 UTC (permalink / raw)
To: Yann Dirson; +Cc: git, Shawn O. Pearce
In-Reply-To: <20070725195010.GA30277@nan92-1-81-57-214-146.fbx.proxad.net>
Hi Yann,
On 7/25/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:
> > Now I need to know whether this' really useful to other people and
> > if so, what would be missing for you to start using it.
>
> The python module would really be useful to StGIT. Currently, an
> stgit commands typically has to fork several git commands at least,
> and using library calls instead would surely help with the
> performance.
Cool.
> I had a quick look at the current pygit API (as described in the
> README), and I find the current revlist one somewhat confusing. Why
> using post-contructor methods, and not using named args in the
> constructor itself ?
>
> That is, the example reading:
>
> >>> rv = repo.revlist()
> >>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
> >>> rv.count = 10
> >>> rv.show_merges()
> >>> for commit in rv:
> ... print commit.id()
> ...
>
>
> would be IMHO much nicer to use as:
>
> >>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),
> ... count = 10,
> ... show_merges = true)
> ...
> >>> for commit in rv:
> ... print commit.id()
> ...
>
>
> What do you think ?
I think you're right, that'd be nicer.
The problem is that the revlist operation accepts a lot of options,
and to change
all (or a big amount of them) would force one to build a very length list of
arguments.
Currently we have just a few, but we'll add more in the future.
Also, I think that it won't be that nice to play with include() and exclude(),
since you can call them more than once.
I'm not sure whether in its current state the module (plus the library) is
useful for stgit.
Please, feel to make questions and to ask for what'd be missing for you
to adopt it.
I'm a quilt user and completely forgot that stgit is written in python. I'll
take a look.
Thanks for your comments,
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* Re: [ANNOUNCE]: PyGit and libgit-thin
From: Jan Hudec @ 2007-07-25 21:21 UTC (permalink / raw)
To: David Kastrup
Cc: Yann Dirson, Luiz Fernando N. Capitulino, git, Shawn O. Pearce
In-Reply-To: <85odi08ddk.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
On Wed, Jul 25, 2007 at 21:57:59 +0200, David Kastrup wrote:
> Nicer to use if the commands and their options originate from withing
> Python. But if Python parses arguments from somewhere else and passes
> them on, the former interface leads to much cleaner code AFAICS.
> Pasting together a named argument call piecemeal is not going to be
> pretty, I should think.
You just put all the arguments in a dict and use the ** syntax. And if you
already get the arguments in a dict from the parser, it's even nicer.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git stash apply segfaulting when called in subdir
From: Uwe Kleine-König @ 2007-07-25 21:23 UTC (permalink / raw)
To: Git Mailing List
Hello,
I did not do much testing and didn't look into the issue yet:
zeisberg@cassiopeia:/tmp$ mkdir repo; cd repo; git init
Initialized empty Git repository in .git/
zeisberg@cassiopeia:/tmp/repo$ mkdir dir; echo one > file; echo two > dir/file
zeisberg@cassiopeia:/tmp/repo$ git add file dir/file
zeisberg@cassiopeia:/tmp/repo$ git commit -m tralala
Created initial commit 265b7d7: tralala
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 dir/file
create mode 100644 file
zeisberg@cassiopeia:/tmp/repo$ echo three >> file
zeisberg@cassiopeia:/tmp/repo$ git stash
Saved "WIP on master: 265b7d7... tralala"
HEAD is now at 265b7d7... tralala
zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
/home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
^ permalink raw reply
* [RFC/PATCH] gitweb: Enable transparent compression form HTTP output
From: Jakub Narebski @ 2007-07-25 18:39 UTC (permalink / raw)
To: Luben Tuikov, git
In-Reply-To: <513314.51284.qm@web31813.mail.mud.yahoo.com>
Check if PerlIO::gzip is available, and if it is make it possible to
enable (via 'compression' %feature) transparent compression of HTML
output. Error messages and any non-HTML output are excluded from
transparent compression.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
On Thu, 19 July 2007, Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > Luben Tuikov wrote:
> >
> > > I wouldn't mind an improvement in the snapshot area of gitweb.
> > > I wasn't really happy with the snapshot feature as it was originally
> > > implemented, as it would generate a tar file with ".tar.bz2"
> > > name extension, but the file was NOT bz2, and I had to always
> > > manually rename, bz2, and rename back.
> >
> > This was a *bug*, but it is now corrected (in 9aa17573). Gitweb used
> > Content-Encoding, which is meant for _transparent_ compression.
>
> Yeah, that's what I suspected, since there was nothing obviously
> wrong with the code.
And _this_ patch adds support for true, intentional transparent
compression.
gitweb/gitweb.perl | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0acd0ca..d48a193 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -20,8 +20,12 @@ binmode STDOUT, ':utf8';
BEGIN {
CGI->compile() if $ENV{'MOD_PERL'};
+
+ eval { require PerlIO::gzip; }; # needed for transparent compression
}
+our $enable_transparent_compression = !! $PerlIO::gzip::VERSION;
+
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
@@ -238,6 +242,22 @@ our %feature = (
'override' => 0,
'default' => [1]},
+ # Enable transparent compression, for now only for HTML output;
+ # this reduces network bandwidth at the cost of CPU usage.
+ # You need to have PerlIO::gzip for that, and browser has to accept
+ # (via Accept-Encoding: HTTP request header) 'gzip' encoding.
+ # Transparent compression is not used for error messages.
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'compression'}{'default'} = [1];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'compression'}{'override'} = 1;
+ # and in project config gitweb.compression = 0|1;
+ 'compression' => {
+ 'sub' => \&feature_compression,
+ 'override' => 0,
+ 'default' => [0]},
+
# Make gitweb use an alternative format of the URLs which can be
# more readable and natural-looking: project name is embedded
# directly in the path and the query string contains other
@@ -336,6 +356,18 @@ sub feature_pickaxe {
return ($_[0]);
}
+sub feature_compression {
+ my ($val) = git_get_project_config('compression', '--bool');
+
+ if ($val eq 'true') {
+ return (1);
+ } elsif ($val eq 'false') {
+ return (0);
+ }
+
+ return ($_[0]);
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -2238,9 +2270,24 @@ sub git_header_html {
} else {
$content_type = 'text/html';
}
+ # transparent compression has to be supported, enabled, and accepted
+ # explicitely by UA; note that qvalue of 0 means "not acceptable."
+ my %content_encoding = ();
+ if ($enable_transparent_compression &&
+ gitweb_check_feature('compression') &&
+ defined $cgi->http('HTTP_ACCEPT_ENCODING') &&
+ $cgi->http('HTTP_ACCEPT_ENCODING') =~ m/(^|,|;|\s)gzip(,|;|\s|$)/ &&
+ $cgi->http('HTTP_ACCEPT_ENCODING') !~ m/(^|,|;|\s)gzip\s*;q=0(,|\s|$)/) {
+ %content_encoding = (-content_encoding => 'gzip');
+ }
print $cgi->header(-type=>$content_type, -charset => 'utf-8',
+ %content_encoding,
-status=> $status, -expires => $expires);
my $mod_perl_version = $ENV{'MOD_PERL'} ? " $ENV{'MOD_PERL'}" : '';
+ if (%content_encoding) {
+ # implies $enable_transparent_compression
+ binmode STDOUT, ':gzip';
+ }
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -2375,6 +2422,7 @@ sub die_error {
my $status = shift || "403 Forbidden";
my $error = shift || "Malformed query, file missing or permission denied";
+ $enable_transparent_compression = 0;
git_header_html($status);
print <<EOF;
<div class="page_body">
--
1.5.2.4
^ permalink raw reply related
* [PATCH] gitweb: Fix error in generating snapshot
From: Jakub Narebski @ 2007-07-25 22:17 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <30e4a070707250627l29ce4794x97d03b8232352cae@mail.gmail.com>
There was an error while generating cmmandline to run git-archive:
there were no whitespace between two options.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0acd0ca..b381692 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4343,7 +4343,7 @@ sub git_snapshot {
my $cmd;
$filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
$cmd = "$git_command archive " .
- "--format=$known_snapshot_formats{$format}{'format'}" .
+ "--format=$known_snapshot_formats{$format}{'format'} " .
"--prefix=\'$name\'/ $hash";
if (exists $known_snapshot_formats{$format}{'compressor'}) {
$cmd .= ' | ' . join ' ', @{$known_snapshot_formats{$format}{'compressor'}};
--
1.5.2.4
^ permalink raw reply related
* Re: submodule init problem
From: Junio C Hamano @ 2007-07-25 22:20 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, Lars Hjemli, git, Ricky Nite, Chris Larson
In-Reply-To: <20070725081508.GN1591MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
>> Ok, this appears it most likely to be related to the fact that
>> one is a prefix of the other in problematic case.
>
> Yes, this has been noted before and Chris Larson sent in a patch,
> but he didn't follow up on it.
Ok, I re-read the thread and came up with a different solution.
How does this look?
-- >8 --
git-submodule module_name: avoid using unwieldy "value_regexp" feature.
"module_name $path" function wants to look up a configuration
variable "submodule.<modulename>.path" whose value is $path, and
return the <modulename> found. "git-config --get-regexp" is the
natural thing to use for this, but (1) its value matching has an
unfortunate "feature" that takes leading '!' specially, and (2)
its output needs to be parsed with sed to extract <modulename>
part anyway.
This changes the call to "git-config --get-regexp" not to use
the value-regexp part, and moves the "pick the one whose value
is $path" part to the downstream sed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-submodule.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 1f0cb99..afbaec7 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -46,8 +46,11 @@ get_repo_base() {
#
module_name()
{
- name=$(GIT_CONFIG=.gitmodules git config --get-regexp '^submodule\..*\.path$' "$1" |
- sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
+ # Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
+ re=$(printf '%s' "$1" | sed -e 's/\([^a-zA-Z0-9_]\)/\\\1/g')
+ name=$( GIT_CONFIG=.gitmodules \
+ git config --get-regexp '^submodule\..*\.path$' |
+ sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
test -z "$name" &&
die "No submodule mapping found in .gitmodules for path '$path'"
echo "$name"
^ 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