* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Schindelin @ 2007-09-02 23:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marius Storm-Olsen, Johannes Sixt, git
In-Reply-To: <200709022342.42733.robin.rosenberg.lists@dewire.com>
Hi,
On Sun, 2 Sep 2007, Robin Rosenberg wrote:
> You actually need admin privileges too, but I don't know any windows
> developer who hasn't got that.
Like almost every developer in the corporate world?
Fact is: this support of symlinks is ridiculous. Why not just admit it?
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: David Kågedal @ 2007-09-02 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <87hcmcfzo9.fsf@morpheus.local>
David Kågedal <davidk@lysator.liu.se> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> GIT v1.5.3 Release Notes
>> ========================
>>
>> Updates since v1.5.2
>> --------------------
>>
>> * The commit walkers other than http are officially deprecated,
>> but still supported for now.
>
> As I think I said before, this first bullet point makes no sense to
> git users. Only hardcore git developers know what a "commit walker
> is", and what commit walkers exist (other than html, obviously). How
I'm not trying to make you even more confused. Make that "http",
please. :-)
> will they know if they are using one of the things you just
> deprecated?
--
David Kågedal
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: David Kågedal @ 2007-09-02 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vodglr32i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> GIT v1.5.3 Release Notes
> ========================
>
> Updates since v1.5.2
> --------------------
>
> * The commit walkers other than http are officially deprecated,
> but still supported for now.
As I think I said before, this first bullet point makes no sense to
git users. Only hardcore git developers know what a "commit walker
is", and what commit walkers exist (other than html, obviously). How
will they know if they are using one of the things you just
deprecated?
--
David Kågedal
^ permalink raw reply
* strbuf API
From: Pierre Habouzit @ 2007-09-02 22:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3217 bytes --]
I read the recent thread Timo Sirainen raised about string APIs in
git. ANd I went read the strbuf.[hc] module.
I believe that the choice made in that module are wrong and could be
made better. I actually use to work with a string buffer API (that
interested readers can look at on [0]), that work almost the same
(except for the eof flag, but it's trivial to keep), but have
two significant differences:
First, and that's the most important one: the buffer is always NUL
terminated, after its official "len". That means, in terms of strbuf
API, that "alloc" is always greater or equal to len+1 to be able to
store the ending NUL[1]. The advantages are obvious: you can pass the
buffer to any legacy C string function without any fear of read
overflow. strtol comes to mind, and atm, git has to explicitely use
strbuf_end to put that ending nul to be able to call legacy
applications. But once done, the NUL is accounted into the string (aka
it's in "len") which makes it a non C-string (I mean you cannot append
any more data in it anymore). So current implementations tries to
workaround an issue (the non systematical NUL-termination) but IMHO the
wrong way.
The other shortcoming is that you cannot tell the buffer "Hey, it's
very likely that you'll end up being _that_ long. That's why, in some
parts of the code (see write_tar_entry in archive-tar.c e.g.) the
programmer actually messes with the buffer allocation, outside from the
strbuf module, which makes it well, useless. In my API, I have a
"buffer_ensure" call, that is supposed to do that: "please ensure that
this buffer still has _this_ amount of free and allocated space to put
more data".
So my question is, do people think I raise a valid point, and would
patches that would refactor the strbuf module to have those functions,
and would fix the code that uses strbuf's to interact properly, be
accepted ?
Also, the efficiency of the buffer module API I use has a lot to do
with the fact that copying functions, and length tests are inlined in
the .h, so that the compiler can optimize the ones it already tested 10
calls before. I'm not sure if this is frowned upon or if it makes sense.
[0] http://git.madism.org/?p=pfixtools.git;a=blob;f=buffer.h;hb=HEAD
http://git.madism.org/?p=pfixtools.git;a=blob;f=buffer.c;hb=HEAD
[1] Of course, ensuring the NUL-termination has a cost, though it's
often benign, and for performance-critical places where characters
are copied one by one, it's always possible to use an "unsafe"
addch (that would not maintain the invariant), and then call an
equivalent of strbuf_end (that would not append a \0 like it does
now, but just would fix the invariant that for any strbuf,
buf->buf[buf->len] == '\0') explicitely. For places where the
invariant generate negligible cost (like concatenating two paths
parts with a middle '/' e.g.) then we gain safety without even
having to think about it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* gitk fails to parse git log output in 1.5.3
From: Jing Xue @ 2007-09-02 22:31 UTC (permalink / raw)
To: git
gitk shows an error "Can't parse git log output: {\x1b[33commit..." at
startup and quits.
Obviously it's because my git-log outputs in color mode. But the same
happens (and git-log still outputs in colors) after I set color.pager=false.
What am I missing?
Thanks.
--
Jing Xue
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-02 22:13 UTC (permalink / raw)
To: Sean; +Cc: H. Peter Anvin, David Kastrup, git, linux-kernel
In-Reply-To: <20070902133803.1b46f599.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> On Sun, 02 Sep 2007 10:57:03 +0100
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> From the looks of it, there is still a git-p4, it just moved to contrib
>> and uses fast-import, so removing its rpm package was probably broken in
>> the first place.
> ...
> As an aside, when I sent the patch removing git-p4import from the spec
> file I mentioned that I had no way to test it and asked for testers.
> Git needs a spec file maintainer so that issues like this can be caught
> before release. Without a maintainer, it should probably be demoted
> to contrib itself.
For majority of general public, I thought the spec file _I_
ship, along with RPM files _I_ build, are contrib status
already. Don't distro people do their own RPM packages, instead
of using what I placed on k.org?
Assuming that we do not give the old git-p4import script
packaged in "git-p4 package", would the following patch be all
that is needed, or do we need other things in the spec file?
-- snipsnap clipcrap --
diff --git a/git.spec.in b/git.spec.in
index fe7b3d8..3d56e17 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -13,6 +13,7 @@ Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, perl-Git
+Obsoletes: git-p4
%description
Git is a fast, scalable, distributed revision control system with an
^ permalink raw reply related
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Robin Rosenberg @ 2007-09-02 22:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: Marius Storm-Olsen, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <20070902213856.GB2756@steel.home>
söndag 02 september 2007 skrev Alex Riesen:
> Robin Rosenberg, Sun, Sep 02, 2007 22:27:59 +0200:
> > söndag 02 september 2007 skrev Marius Storm-Olsen:
> > > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
> >
> > It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
> >
>
> Except they fscked it up, as usual for microsoft: it 's got a
> mandatory argument specifying what the target should be, file or
> directory. And they don't tell what happens when the argument is wrong
> or the target does not exists. Typical, too.
Why would this API be an exception?
-- robin
^ permalink raw reply
* Re: Large-scale configuration backup with GIT?
From: Junio C Hamano @ 2007-09-02 21:49 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20070902201724.GB10567@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> I'm just thinking about storing our whole company's configuration into
> GIT, because I'm all too used to it. That is, there are configuration
> ...
> In both cases, I'd be left with a good number of GIT repos, which
> should probably be bound together with the GIT subproject functions.
> However, one really interesting thing would be to be able to get the
> diff of two machine's configuration files. (Think of machines that
> *should* be all identical!) For this, it probably would be easier to
> not put each machine into its own GIT repo, but to use a single one
> with a zillion branches, one for each machine.
>
> Did anybody already try to do something like that and can help me with
> some real-life experience on that topic?
This is something similar to what I and others in my group did
long time before git was even invented. I'd suggest you go in
the opposite direction.
If you have 5 configurations, each of which have 20 machines
that _should_ share that configuration (modulo obvious
differences that come from hostname, IP address assignment,
etc), then
- You keep track of 5 configurations; in git, you would
probably maintain them as 5 branches.
- You have a build mechanism to create systemic variation among
20 machines that shares one configuration; this can be
different per branch. So if you have 20 solaris machines all
should share logically the same configuration, you would:
$ git checkout solarisconf
... tweak the config for machine #27, adjusting for
... hostname, IP address variation, etc...
$ make target=solaris27 output=../solaris27.expect
Make that makefile produce the output in named directory;
- You get the config dump from your machines (your "staging
area"), as you planned. Then after running the above, you
could:
$ cd ..
$ diff -r solaris27.expect solaris27.actual
if your "staging area" for machine #27 is "solaris27.actual".
The difference you would see is something done by *hand* on the
machine, which you would want to propagate back to the solaris
configuration *source* you keep track in git. For some changes,
you may even want to adjust that single manual change done on
machine #27 so that you do not have to do that on other 19
solaris boxes manually, by adjusting the build procedure in the
solarisconf branch.
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Alex Riesen @ 2007-09-02 21:41 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <46DB0F9C.2090306@trolltech.com>
Marius Storm-Olsen, Sun, Sep 02, 2007 21:31:40 +0200:
> + buf->st_ino = 0;
You sure about that? Ever wondered why it is not so on everywhere else?
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Robin Rosenberg @ 2007-09-02 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0709022133190.28586@racer.site>
söndag 02 september 2007 skrev Johannes Schindelin:
> Hi,
>
> On Sun, 2 Sep 2007, Robin Rosenberg wrote:
>
> > s?ndag 02 september 2007 skrev Marius Storm-Olsen:
> > > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
> >
> > It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
>
> Oh? *goes and tries to create one on a USB stick* No. Besides, IIRC you
Set core.symlinks = false for working on a broken file system
> cannot even create symlinks to another partition. Copying a symlink will
That is not the normal use for symlinks. It is a case where it breaks, but symbolic
links in a git repo that points outside the repo is probably not a good idea, especially
if it is a cross platform project. It is far less broken than today anyway.
> copy the _linked_ file. So to call this "symlink" is a little... uhm...
> preposterous.
$ ln -s Makefile x
$ cp x y
$ ls -ld x y
lrwxrwxrwx 1 me me 8 sep 2 23:36 x -> Makefile
-rw-r--r-- 1 me me 32164 sep 2 23:36 y
Same behaviour as on linux.
> Plus, on a page linked from the link you posted, it says that it is
> only supported from Vista onwards. So you must be kidding me.
core.symlinks = false if ithey aren't supported. You actually need
admin privileges too, but I don't know any windows developer who
hasn't got that.
-- robin
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Alex Riesen @ 2007-09-02 21:38 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Marius Storm-Olsen, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <200709022228.00733.robin.rosenberg.lists@dewire.com>
Robin Rosenberg, Sun, Sep 02, 2007 22:27:59 +0200:
> söndag 02 september 2007 skrev Marius Storm-Olsen:
> > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
>
> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
>
Except they fscked it up, as usual for microsoft: it 's got a
mandatory argument specifying what the target should be, file or
directory. And they don't tell what happens when the argument is wrong
or the target does not exists. Typical, too.
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Schindelin @ 2007-09-02 21:26 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marius Storm-Olsen, Johannes Sixt, git
In-Reply-To: <200709022228.00733.robin.rosenberg.lists@dewire.com>
Hi,
On Sun, 2 Sep 2007, Robin Rosenberg wrote:
> s?ndag 02 september 2007 skrev Marius Storm-Olsen:
> > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
>
> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
Oh? *goes and tries to create one on a USB stick* No. Besides, IIRC you
cannot even create symlinks to another partition. Copying a symlink will
copy the _linked_ file. So to call this "symlink" is a little... uhm...
preposterous.
Plus, on a page linked from the link you posted, it says that it is
only supported from Vista onwards. So you must be kidding me.
Ciao,
Dscho
^ permalink raw reply
* Re: Large-scale configuration backup with GIT?
From: Jan-Benedict Glaw @ 2007-09-02 21:24 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85642spzvs.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
On Sun, 2007-09-02 22:37:43 +0200, David Kastrup <dak@gnu.org> wrote:
> Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>
> > I'm just thinking about storing our whole company's configuration into
> > GIT, because I'm all too used to it. That is, there are configuration
> > dumps of n*10000 routers and switches, as well as "regular"
> > configuration files on server machines (mostly Linux and Solaris.)
> > While probably all of the server machines could run GIT natively, we
> > already have some scripts to dump all router's/switch's configuration
> > to a Solaris system, so we could it import/commit from there. There
> > might be a small number of Windows machines, but I guess these will be
> > done by exporting the interesting stuff to Linux/Solaris machines...
> >
> > I initially thought about running a git-init-db on each machine's root
> > directory and adding all interesting files, but that might hurt GIT's
> > usage for single software projects on those machines, no?
>
> It could break shell scripts, since
> cd /;echo `pwd`/filename
> does not return /filename.
Well, I don't think that this is much of a problem.
> I don't think that the root directory is a good place for starting
> git.
Maybe :) But this is why I brought up the discussion, to get other
people's oppinion on this topic.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: http://catb.org/~esr/faqs/smart-questions.html
the second :
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Large-scale configuration backup with GIT?
From: David Kastrup @ 2007-09-02 20:37 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20070902201724.GB10567@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> I'm just thinking about storing our whole company's configuration into
> GIT, because I'm all too used to it. That is, there are configuration
> dumps of n*10000 routers and switches, as well as "regular"
> configuration files on server machines (mostly Linux and Solaris.)
> While probably all of the server machines could run GIT natively, we
> already have some scripts to dump all router's/switch's configuration
> to a Solaris system, so we could it import/commit from there. There
> might be a small number of Windows machines, but I guess these will be
> done by exporting the interesting stuff to Linux/Solaris machines...
>
> I initially thought about running a git-init-db on each machine's root
> directory and adding all interesting files, but that might hurt GIT's
> usage for single software projects on those machines, no?
It could break shell scripts, since
cd /;echo `pwd`/filename
does not return /filename.
I don't think that the root directory is a good place for starting
git.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Robin Rosenberg @ 2007-09-02 20:27 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <46DB0F9C.2090306@trolltech.com>
söndag 02 september 2007 skrev Marius Storm-Olsen:
> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
-- robin
^ permalink raw reply
* Large-scale configuration backup with GIT?
From: Jan-Benedict Glaw @ 2007-09-02 20:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
Hi!
I'm just thinking about storing our whole company's configuration into
GIT, because I'm all too used to it. That is, there are configuration
dumps of n*10000 routers and switches, as well as "regular"
configuration files on server machines (mostly Linux and Solaris.)
While probably all of the server machines could run GIT natively, we
already have some scripts to dump all router's/switch's configuration
to a Solaris system, so we could it import/commit from there. There
might be a small number of Windows machines, but I guess these will be
done by exporting the interesting stuff to Linux/Solaris machines...
I initially thought about running a git-init-db on each machine's root
directory and adding all interesting files, but that might hurt GIT's
usage for single software projects on those machines, no?
Additionally, a lot of configuration files will be common, or at least
very similar. A lot of repos would probably result in worse
compression when starting with packs.
Another idea would be to regularly copy all interesting files into a
staging directory (with the same directory structure as the root
filesystem) and git-init-db'ing this staging directory, to not have a
machine-wide .git/ in the root directory.
In both cases, I'd be left with a good number of GIT repos, which
should probably be bound together with the GIT subproject functions.
However, one really interesting thing would be to be able to get the
diff of two machine's configuration files. (Think of machines that
*should* be all identical!) For this, it probably would be easier to
not put each machine into its own GIT repo, but to use a single one
with a zillion branches, one for each machine.
Did anybody already try to do something like that and can help me with
some real-life experience on that topic?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: http://catb.org/~esr/faqs/smart-questions.html
the second :
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Teach "git remote" a mirror mode
From: Johannes Schindelin @ 2007-09-02 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5r8q1yz.fsf@gitster.siamese.dyndns.org>
When using the "--mirror" option to "git remote add", the refs will not
be stored in the refs/remotes/ namespace, but in the same location as
on the remote side.
This option probably only makes sense in a bare repository.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sun, 2 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When using the "--mirror" option to "git remote add", the refs
> > will not be stored in the refs/remotes/ namespace, but in
> > refs/heads/.
>
> I suspect people'd prefer "+refs/*:refs/*" for a repo truly
> mirroring another.
Yes, you're right.
Documentation/git-remote.txt | 6 +++++-
git-remote.perl | 8 +++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 61a6022..94b9f17 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-remote'
-'git-remote' add [-t <branch>] [-m <branch>] [-f] <name> <url>
+'git-remote' add [-t <branch>] [-m <branch>] [-f] [--mirror] <name> <url>
'git-remote' show <name>
'git-remote' prune <name>
'git-remote' update [group]
@@ -45,6 +45,10 @@ multiple branches without grabbing all branches.
With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
up to point at remote's `<master>` branch instead of whatever
branch the `HEAD` at the remote repository actually points at.
++
+In mirror mode, enabled with `--mirror`, the refs will not be stored
+in the 'refs/remotes/' namespace, but in 'refs/heads/'. This option
+only makes sense in bare repositories.
'show'::
diff --git a/git-remote.perl b/git-remote.perl
index 01cf480..f6f283e 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -278,7 +278,9 @@ sub add_remote {
for (@$track) {
$git->command('config', '--add', "remote.$name.fetch",
- "+refs/heads/$_:refs/remotes/$name/$_");
+ $opts->{'mirror'} ?
+ "+refs/$_:refs/$_" :
+ "+refs/heads/$_:refs/remotes/$name/$_");
}
if ($opts->{'fetch'}) {
$git->command('fetch', $name);
@@ -409,6 +411,10 @@ elsif ($ARGV[0] eq 'add') {
shift @ARGV;
next;
}
+ if ($opt eq '--mirror') {
+ $opts{'mirror'} = 1;
+ next;
+ }
add_usage();
}
if (@ARGV != 3) {
--
1.5.3.2.g46909
^ permalink raw reply related
* Re: Stats in Git
From: Marius Storm-Olsen @ 2007-09-02 20:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070902200218.GA2756@steel.home>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
Alex Riesen wrote:
> Marius Storm-Olsen, Sun, Sep 02, 2007 16:49:55 +0200:
>> By applying the diff below, you can see for yourself what happens when
>
> just use "strace -e fstat,stat,lstat,stat64,lstat64 -f git-status"
> on sane platform.
Right, I was doing this on Windows, where strace is rather.. limited, so
I thought I'd just share the code for all to play with :-)
But, on my linux box:
$ strace -e fstat,stat,lstat,stat64,lstat64 -f git-status 2>&1 | wc -l
300195
(Slightly more stats there, as expected, due to the listings of the
shells stats too, and not just the builtins.)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Stats in Git
From: Alex Riesen @ 2007-09-02 20:02 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Git Mailing List
In-Reply-To: <46DACD93.9000509@trolltech.com>
Marius Storm-Olsen, Sun, Sep 02, 2007 16:49:55 +0200:
> By applying the diff below, you can see for yourself what happens when
just use "strace -e fstat,stat,lstat,stat64,lstat64 -f git-status"
on sane platform.
^ permalink raw reply
* Re: [PATCH] Teach "git remote add" a mirror mode
From: Junio C Hamano @ 2007-09-02 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709021245040.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When using the "--mirror" option to "git remote add", the refs will not
> be stored in the refs/remotes/ namespace, but in refs/heads/.
I suspect people'd prefer "+refs/*:refs/*" for a repo truly
mirroring another.
^ permalink raw reply
* [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Marius Storm-Olsen @ 2007-09-02 19:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin
In-Reply-To: <46DB0478.8050402@trolltech.com>
This gives us a significant speedup when adding, committing and stat'ing files.
(Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
---
Revision #2 of the patch.
For this one I change the filetime_to_time_t function to do the
timestamp conversion inline in the FILETIME struct. That way we
also avoid one assignment, bitshifting and addition.
Sneaky, huh? ;-)
New stats:
-------------------------
Command: git init
-------------------------
real 0m0.047s
user 0m0.031s
sys 0m0.000s
-------------------------
Command: git add .
-------------------------
real 0m12.016s
user 0m0.015s
sys 0m0.000s
-------------------------
Command: git commit -a...
-------------------------
real 0m17.031s
user 0m0.015s
sys 0m0.030s
-------------------------
3x Command: git-status
-------------------------
real 0m5.265s
user 0m0.015s
sys 0m0.015s
real 0m5.297s
user 0m0.015s
sys 0m0.000s
real 0m5.250s
user 0m0.015s
sys 0m0.016s
-------------------------
Command: git commit...
(single file)
-------------------------
real 0m7.859s
user 0m0.015s
sys 0m0.015s
compat/mingw.c | 41 +++++++++++++++++++++++++++++++++--------
git-compat-util.h | 4 ++++
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 7711a3f..86a1419 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -23,19 +23,44 @@ int fchmod(int fildes, mode_t mode)
return -1;
}
-int lstat(const char *file_name, struct stat *buf)
+static inline time_t filetime_to_time_t(const FILETIME *ft)
+{
+ long long *winTime = (long long*)ft;
+ *winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
+ *winTime /= 10000000; /* Nano to seconds resolution */
+ return (time_t)ft->dwLowDateTime;
+}
+
+extern int _getdrive( void );
+int git_lstat(const char *file_name, struct stat *buf)
{
int namelen;
static char alt_name[PATH_MAX];
-
- if (!stat(file_name, buf))
+ WIN32_FILE_ATTRIBUTE_DATA fdata;
+
+ if (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {
+ int fMode = S_IREAD;
+ if (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
+ fMode |= S_IFDIR;
+ else
+ fMode |= S_IFREG;
+ if (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))
+ fMode |= S_IWRITE;
+
+ buf->st_ino = 0;
+ buf->st_gid = 0;
+ buf->st_uid = 0;
+ buf->st_nlink = 1;
+ buf->st_mode = fMode;
+ buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */
+ buf->st_dev = buf->st_rdev = (_getdrive() - 1);
+ buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
+ buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
+ buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
return 0;
+ }
+ errno = ENOENT;
- /* if file_name ended in a '/', Windows returned ENOENT;
- * try again without trailing slashes
- */
- if (errno != ENOENT)
- return -1;
namelen = strlen(file_name);
if (namelen && file_name[namelen-1] != '/')
return -1;
diff --git a/git-compat-util.h b/git-compat-util.h
index 1ba499f..4122465 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -488,6 +488,10 @@ int mingw_rename(const char*, const char*);
extern void quote_argv(const char **dst, const char **src);
extern const char *parse_interpreter(const char *cmd);
+/* Make git on Windows use git_lstat instead of lstat and stat */
+int git_lstat(const char *file_name, struct stat *buf);
+#define lstat(x,y) git_lstat(x,y)
+#define stat(x,y) git_lstat(x,y)
#endif /* __MINGW32__ */
#endif
--
1.5.3.GIT-dirty
^ permalink raw reply related
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Sixt @ 2007-09-02 19:07 UTC (permalink / raw)
To: git; +Cc: Marius Storm-Olsen, Johannes Schindelin
In-Reply-To: <46DB0478.8050402@trolltech.com>
On Sunday 02 September 2007 20:44, Marius Storm-Olsen wrote:
> Johannes Sixt wrote:
> > I'm slightly negative about this. For a native Windows project the
> > executable bit does not matter, and for a cross-platform project this
> > check is not sufficient, but can even become annoying (think of a file
> > named 'www.google.com'). So we can just as well spare the few cycles.
>
> Ok, that's fine by me. It was only added for completeness, and with no
> benefits I'd say we drop it too.
I'll amend the patch accordingly.
> >> return 0;
> >> + }
> >> + errno = ENOENT;
> >
> > Of course we need a bit more detailed error conditions, most importantly
> > EACCES should be distinguished.
>
> Right, you want to do that in a second commit?
Yes, please. Please don't forget to take care of the trailing-slash annoyance.
-- Hannes
^ permalink raw reply
* Re: git clone over http
From: Sean @ 2007-09-02 18:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200709021123.04218.robin.rosenberg.lists@dewire.com>
On Sun, 2 Sep 2007 11:23:03 +0200
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
Hi Robin,
> git clone (1.5.3) with http is somewhat unreliable. I've noticed if can actually give
> me different versions of a branch each time I run it, eventually yielding
> the one I'm expecting. And now this:
Hmmm, that's very odd. Tried it 3 times here and master was always at the
same commit (0421997bfd5).
> (Using master, just after rc7)
> $ git clone http://unix.schottelius.org/git/cLinux/cinit.git
[...]
> /usr/local/bin/git-clone: line 40: 14823 Segmenteringsfel git-http-fetch $v -a -w "$tname" "$sha1" "$1"
>
> It doesn't repeat itself, but I cannot clone because it always crashes.
Using 1.5.3 here and it works just fine. Perhaps it has something to do with
your version of the Curl library? This is what is in use here:
$ curl --version
curl 7.16.4 (i686-pc-linux-gnu) libcurl/7.16.4 OpenSSL/0.9.8e zlib/1.2.3
Protocols: tftp ftp telnet dict http file https ftps
Features: Largefile NTLM SSL libz
Sean
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Marius Storm-Olsen @ 2007-09-02 18:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin
In-Reply-To: <200709022016.54262.johannes.sixt@telecom.at>
[-- Attachment #1: Type: text/plain, Size: 4943 bytes --]
Johannes Sixt wrote:
> On Sunday 02 September 2007 16:51, Marius Storm-Olsen wrote:
>> This gives us a significant speedup when adding, committing and stat'ing
>> files. (Also, since Windows doesn't really handle symlinks, it's fine that
>> stat just uses lstat)
>>
>> Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>
> Your numbers show an improvement of 50% and more. That is terrific!
Yes, I was surprised myself about the impact. Didn't think it would make
_such_ a difference. And if you compare it to the results we had before
Linus' performance fix too, just checkout the performance improvements
we've had (based on Moe's test script):
Before Now
------------------------- -------------------------
Command: git init Command: git init
------------------------- -------------------------
real 0m0.031s real 0m0.078s
user 0m0.031s user 0m0.031s
sys 0m0.000s sys 0m0.000s
------------------------- -------------------------
Command: git add . Command: git add .
------------------------- -------------------------
real 0m19.328s real 0m12.187s
user 0m0.015s user 0m0.015s
sys 0m0.015s sys 0m0.015s
------------------------- -------------------------
Command: git commit -a... Command: git commit -a...
------------------------- -------------------------
real 0m30.937s real 0m17.297s
user 0m0.015s user 0m0.015s
sys 0m0.015s sys 0m0.015s
------------------------- -------------------------
3x Command: git-status 3x Command: git-status
------------------------- -------------------------
real 0m19.531s real 0m5.344s
user 0m0.211s user 0m0.015s
sys 0m0.136s sys 0m0.031s
real 0m19.532s real 0m5.390s
user 0m0.259s user 0m0.031s
sys 0m0.091s sys 0m0.000s
real 0m19.593s real 0m5.344s
user 0m0.211s user 0m0.015s
sys 0m0.152s sys 0m0.016s
------------------------- -------------------------
Command: git commit... Command: git commit...
(single file) (single file)
------------------------- -------------------------
real 0m36.688s real 0m7.875s
user 0m0.031s user 0m0.015s
sys 0m0.000s sys 0m0.000s
> I'll test it out an put the patch into mingw.git. I hope you don't mind if I
> also include your analysis and statistics in the commit message. It's worth
> keeping around! BTW, which of your email addresses would you like registered
> as author?
Sure, include the stats if you'd like. You can use
mstormo_git@storm-olsen.com for email address.
>> + ext = strrchr(file_name, '.');
>> + if (ext && (!_stricmp(ext, ".exe") ||
>> + !_stricmp(ext, ".com") ||
>> + !_stricmp(ext, ".bat") ||
>> + !_stricmp(ext, ".cmd")))
>> + fMode |= S_IEXEC;
>> + }
>
> I'm slightly negative about this. For a native Windows project the executable
> bit does not matter, and for a cross-platform project this check is not
> sufficient, but can even become annoying (think of a file
> named 'www.google.com'). So we can just as well spare the few cycles.
Ok, that's fine by me. It was only added for completeness, and with no
benefits I'd say we drop it too.
>> + buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since
>> it's not a stat64 */
>
> Here's an idea for the future: With this self-made stat() implementation it
> should also be possible to get rid of Windows's native struct stat: Make a
> private definition of it, too, and use all 64 bits.
Yep, that will shave off one assignment, bit-shift and addition. Quick
operations, but still worth while IMO. No point wasting cycles where we
don't have to.
>> return 0;
>> + }
>> + errno = ENOENT;
>
> Of course we need a bit more detailed error conditions, most importantly
> EACCES should be distinguished.
Right, you want to do that in a second commit?
>> +/* Make git on Windows use git_lstat and git_stat instead of lstat and
>> stat */ +int git_lstat(const char *file_name, struct stat *buf);
>> +int git_stat(const char *file_name, struct stat *buf);
>> +#define lstat(x,y) git_lstat(x,y)
>> +#define stat(x,y) git_stat(x,y)
>
> I'd go the short route without git_stat() and
>
> #define stat(x,y) git_lstat(x,y)
Please do, thanks.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* conflict markers not documented
From: Alan M. Feldstein @ 2007-09-02 18:32 UTC (permalink / raw)
To: git
I can't find Git conflict markers documented anywhere. If I do
git pull git://icarus.com/~steve-icarus/verilog v0_8-branch
that results in files marked like this, for example
<<<<<<< HEAD:Attrib.cc
#ident "$Id: Attrib.cc,v 1.5 2002/08/12 01:34:58 steve Exp $"
=======
#ident "$Id: Attrib.cc,v 1.6 2004/02/20 18:53:33 steve Exp $"
>>>>>>> f600e774d54f14d2cc2848ea5ef663233f8a6f6e:Attrib.cc
The git-pull(1) Manual Page
<http://www.kernel.org/pub/software/scm/git/docs/git-pull.html> mentions
conflicts in three places, but fails to document the markers or lead me
to a page that does. The closest thing I've found is Git User's Manual
(for version 1.5.3 or newer)
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html> with
<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
but it fails to explain which is which, only stating that "All you need
to do is edit the files to resolve the conflicts ...". That's not enough
information.
In _Essential CVS_ by Jennifer Vesperman, she documents (even more
clearly than the Cederqvist) CVS conflict markers like this
<<<<<<< filename
sandbox content
=======
repository content
>>>>>>> revision
>From this, I can infer that
#ident "$Id: Attrib.cc,v 1.5 2002/08/12 01:34:58 steve Exp $"
was my Git repository content and
#ident "$Id: Attrib.cc,v 1.6 2004/02/20 18:53:33 steve Exp $"
was the other repository content (from which I fetched).
But I shouldn't need to refer to a CVS book to understand Git. Git's
documentation should have made this clear. So I'm not writing this to
ask for confirmation of my inference from the Git mailing list. I'm
writing this to ask that the Git documentation be improved to adequately
explain conflict markers.
--
Alan Feldstein
Cosmic Horizon logo
http://www.alanfeldstein.com/
+1 585 415 6682
^ 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