* Re: [PATCH (GITK)] gitk: Fix commit encoding support.
From: Paul Mackerras @ 2008-11-10 11:46 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811091806.07550.angavrilov@gmail.com>
Alexander Gavrilov writes:
> +proc do_readcommit {id} {
> + global tclencoding
> +
> + # Invoke git-log to handle automatic encoding conversion
> + set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
> + # Read the results using i18n.logoutputencoding
> + fconfigure $fd -translation lf -eofchar {}
> + if {$tclencoding != {}} {
> + fconfigure $fd -encoding $tclencoding
Does this mean there are two conversions going on, one inside git log
and another inside Tcl? Is there a reason why it's better to do two
conversions than one, or is it just more convenient that way?
Would an alternative approach have been to read the output of git
cat-file with -translation binary, look for an encoding header, and do
an encoding convertfrom based on the encoding header? What would be
the disadvantage of such an approach?
Paul.
^ permalink raw reply
* Re: Install issues
From: Miklos Vajna @ 2008-11-10 11:39 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20081110121739.15f77a01@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Mon, Nov 10, 2008 at 12:17:39PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> git-1.6.0.4 112 > make check
> for i in *.c; do sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__ $i || exit; done
> /bin/sh: sparse: command not found
> make: *** [check] Error 127
>
> Maybe the Makefile could be a little more user-friendly with a message
> like
>
> "Cannot run 'make check', as you do not have 'sparse' installed.
> Did you mean to run 'make test' instead?"
Care to send a patch?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-10 11:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git
In-Reply-To: <alpine.DEB.1.00.0811101125360.30769@pacific.mpi-cbg.de>
On Mon, 10 Nov 2008, Johannes Schindelin wrote:
> On Sat, 8 Nov 2008, Jakub Narebski wrote:
>> On Sat, 8 Nov 2008, David Symonds wrote:
>>> On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>>> Mon, Oct 27, 2008
>>>> -----------------
>>>> * Dscho: Contributing with Git
>>>> http://www.youtube.com/watch?v=j45cs5_nY2k
>>>
>>> It was a good intro, but I was expecting a few more non-GitTogether
>>> people. We had quite a large room, but there was only about a dozen
>>> other people who came along. I don't know whether that was the fault
>>> of the timing, lack of advertising, or a lack of interest.
[...]
>> It would be also nice to have slides for the talk available somewhere,
>> just like slides for "Git Chronicle".
>
> Voila:
>
> http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=f23c1c9868256cae8591bddafd64422f95d67b02
Thanks a lot. Added to http://git.or.cz/gitwiki/GitTogether
P.S. I guess GitTogether wiki page should be perhaps rewritten...
--
Jakub Narebski
Poland
^ permalink raw reply
* Install issues
From: H.Merijn Brand @ 2008-11-10 11:17 UTC (permalink / raw)
To: git
1. OpenSUSE 11.0's yast2 does not have "ignore dependency" anymore in
the gui, which makes installing git from the GIT RPMS to fail as it
seems to depend on openssh-clients, a package that has been
deprecated in SUSE, and is not available anymore
In 10.3 you could still go on after "ignore this dependency
locally", and all worked fine.
So now I have to build from source, or download the rpm and look up the
flags to rpm to make --no-deps work. That feels dirty, so I rather build
Builds fine. Now 'make test', which I often mistype as 'make check'
because the GNU folk refuse to add 'make test' as an alias for 'make
check' and switching between all the sourse distributions that do it
right (perl, git, ...) and those that do it wrong (GNU) I often type
the wrong one
git-1.6.0.4 112 > make check
for i in *.c; do sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__ $i || exit; done
/bin/sh: sparse: command not found
make: *** [check] Error 127
Maybe the Makefile could be a little more user-friendly with a message
like
"Cannot run 'make check', as you do not have 'sparse' installed.
Did you mean to run 'make test' instead?"
FYI
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 3726
failed 0
broken 2
total 3729
rm -f -r 'trash directory' test-results
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Santi Béjar @ 2008-11-10 10:47 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20081110185817.6117@nanako3.lavabit.com>
On Mon, Nov 10, 2008 at 10:58 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
> Documentation/rev-list-options.txt | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index 966276b..977290c 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -456,6 +456,13 @@ Note the major differences in `N` and `P` over '\--full-history':
> removed completely, because it had one parent and is TREESAME.
> --
>
> +The '\--simplify-by-decoration' option can be used to treat commits that
> +are not referenced by tags as TREESAME, and treat commits that are tagged
> +as !TREESAME (even when they have exactly the same tree as their parents).
> +This can be used when you are only interested in the big picture of the
> +topology of the history.
> +
> +
I prefer the other way around, first what it does, and then how it
does it (but it is a general comment about the help in "History
Simplification", at least when viewing the help for "git log"). And
you should rewrite the line 416:
Finally, there is a fourth simplification mode available
as it is no longer "Finally".
Santi
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-10 10:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Symonds, git
In-Reply-To: <200811081631.06229.jnareb@gmail.com>
Hi,
On Sat, 8 Nov 2008, Jakub Narebski wrote:
> On Sat, 8 Nov 2008, David Symonds wrote:
> > On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > > Mon, Oct 27, 2008
> > > -----------------
> > > * Dscho: Contributing with Git
> > > http://www.youtube.com/watch?v=j45cs5_nY2k
> >
> > It was a good intro, but I was expecting a few more non-GitTogether
> > people. We had quite a large room, but there was only about a dozen
> > other people who came along. I don't know whether that was the fault
> > of the timing, lack of advertising, or a lack of interest.
>
> By the way, it would be nice to have transcript for this talk, just
> like there is for Linus talk:
> http://git.or.cz/gitwiki/LinusTalk200705Transcript
> (but this would take some doing).
>
> It would be also nice to have slides for the talk available somewhere,
> just like slides for "Git Chronicle".
Voila:
http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=f23c1c9868256cae8591bddafd64422f95d67b02
Ciao,
Dscho
^ permalink raw reply
* Re: StGit: stgit mail configuration options
From: Karl Hasselström @ 2008-11-10 10:19 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <871vxptasf.fsf@krank.kagedal.org>
On 2008-11-06 11:21:20 +0100, David Kågedal wrote:
> The "stg mail" command uses a couple of configuration options that
> are completely undocumented, and don't fit well together.
I agree that they definitely need documenting.
As for renaming them and/or changing their types, that's probably a
good idea too. And once they are documented, we could e.g. rename and
only mention the new name in the docs, but keep the old name as well
for backward compatibility.
One interesting twist would be to fix StGit's config parser so that it
can automatically generate a man page listing all the config options
it recognizes. It needs updating anyway for other reasons (I believe
it still calls git-config several times instead of just once), and
this could be done at the same time.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-10 10:14 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081110100757.GA12868@diku.dk>
>
>> I noticed that all substitutions "--" -> "—", where "—" is a part of
>> sentence punctuation, match \w--\w pattern (e.g. no spaces on both
>> sides) and probably this is how it should be written in English. But
>> basing on this doesn't seem to me to be fool proof.
>
> So another option is to disable all substitution of "--" and just use
> the "—" character when it is explicitly needed. The documentation is
> using UTF-8 after all. This would also fix the usage of "--" in the
> manpages, e.g.
>
> You've now initialized the working directory--you may notice ...
>
> in gittutorial(7). On my setup, with "--" replaced with "—", I get the
> following nroff code:
On my machine, make gittutorial.7 produces manpage that displays "--"
in this place :)
>
> You've now initialized the working directory\(emyou may notice
Anyway, this may be a good idea to use unambiguous "—" (though people
writing docs may be used to using "--" as a punctuation). I can run
through the Documentation replacing "\w--\w" with m-dash, if you want.
Regards,
Piotr
^ permalink raw reply
* Re: Large media in git (was: How it was at GitTogether'08)?
From: Kai Blin @ 2008-11-10 10:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tim Ansell
In-Reply-To: <200811101030.54070.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Monday 10 November 2008 10:30:53 Jakub Narebski wrote:
> On Sun, 9 Nov 2008, Kai Blin wrote:
> > On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
> > > The workaround is to put all large files for example in 'media/'
> > > folder, and make this folder be submodule. Each clone of repository can
> > > have this 'media' submodule either present (both in object database,
> > > although usually separate from main project object database), or not
> > > present (not cloned and not checked out).
> >
> > Tim was talking about that media/ folder and managing that in git. If you
> > want to work on the media, you might end up getting hundreds of gigabytes
> > of data to get that folder, even if you only need to change one single
> > file.
> >
> > That's the issue we're running into, and I don't thing submodules solve
> > this at all.
>
> Ah, well... Submodules cannot be workaround for _this_ issue. You can
> have only all or nothing: either all files in media/ or none of them,
> both in working directory like in repository object database... well
> unless you subdivide further.
>
> I guess that mentioned work on the media is in remote setting (you
> cannot have main repository on network drive) so Dana How's proposed
> solution would not work for you, is it?
If my google-fu worked, the proposed solution you're talking about involves
simply hiding large blobs from pack files, right? In that case it won't work,
as the users of the repository indeed are remote.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Kai Blin @ 2008-11-10 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, David Symonds, git, Tim Ansell
In-Reply-To: <alpine.DEB.1.00.0811101055020.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
On Monday 10 November 2008 10:58:05 Johannes Schindelin wrote:
Hi Dscho,
> > Tim was talking about that media/ folder and managing that in git. If
> > you want to work on the media, you might end up getting hundreds of
> > gigabytes of data to get that folder, even if you only need to change
> > one single file.
> >
> > That's the issue we're running into, and I don't thing submodules solve
> > this at all.
>
> You'd have to have a single repository for each and every media file, and
> you'd need to use shallow clones and shallow fetches.
>
> However, a push-conflict will probably be beyond any non-programmer
> skillz.
Ok, I agree. But you could work around that by teaching the artists to
fetch/rebase/push instead of just pushing, or hiding this in the GUI. If
there's a conflict on a binary data file you're screwed anyway. :)
> I'd rather propose to have a different interface, like through a web
> server, where the user can say "I have some cool new graphics, in this
> .zip file" together with a commit message.
>
> Kind of a git-gui via browser.
Incidentally I'm currently working on something like this, just aimed at
the "artist side", instead of the VCS side. This certainly is a useable
solution for artists. But at some point a developer will want to check out
the repository to cut a release tarball, and we're back to wanting shallow
and narrow clones. :)
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Jonas Fonseca @ 2008-11-10 10:07 UTC (permalink / raw)
To: Piotr Findeisen; +Cc: git
In-Reply-To: <ddb82bf60811092338m3aad8041w20de23f18aa7d56e@mail.gmail.com>
Piotr Findeisen <piotr.findeisen@gmail.com> wrote Mon, Nov 10, 2008:
> >>> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
> >>> sometimes unwanted -- especially when citing command line options like
> >>> "git diff --cached". This commit includes proper quotes in user-manual.txt.
> >
> > Newer asciidoc versions have the following "workaround". Maybe adding
> > something like this to Documentation/asciidoc.conf would be more
> > future proof.
>
> Well, this doesn't solve the problem -- I'm not talking about
> manpages, the "--" where replaced with single "—" on the
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html page.
Sorry I didn't read your mail carefully enough.
> Yes, we can disable such a replacement in the config file, but take a
> look at the sentence "...how to fetch and study a project using
> git—read these chapters...". In this case "--" in the source file was
> replaced with "—" and this is what we want.
True.
> I noticed that all substitutions "--" -> "—", where "—" is a part of
> sentence punctuation, match \w--\w pattern (e.g. no spaces on both
> sides) and probably this is how it should be written in English. But
> basing on this doesn't seem to me to be fool proof.
So another option is to disable all substitution of "--" and just use
the "—" character when it is explicitly needed. The documentation is
using UTF-8 after all. This would also fix the usage of "--" in the
manpages, e.g.
You've now initialized the working directory--you may notice ...
in gittutorial(7). On my setup, with "--" replaced with "—", I get the
following nroff code:
You've now initialized the working directory\(emyou may notice
...
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Nanako Shiraishi @ 2008-11-10 9:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/rev-list-options.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 966276b..977290c 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -456,6 +456,13 @@ Note the major differences in `N` and `P` over '\--full-history':
removed completely, because it had one parent and is TREESAME.
--
+The '\--simplify-by-decoration' option can be used to treat commits that
+are not referenced by tags as TREESAME, and treat commits that are tagged
+as !TREESAME (even when they have exactly the same tree as their parents).
+This can be used when you are only interested in the big picture of the
+topology of the history.
+
+
ifdef::git-rev-list[]
Bisection Helpers
~~~~~~~~~~~~~~~~~
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH 1/2] Document "git log --source"
From: Nanako Shiraishi @ 2008-11-10 9:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-log.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 93a2a22..34cf4e5 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -40,6 +40,10 @@ include::diff-options.txt[]
--decorate::
Print out the ref names of any commits that are shown.
+--source::
+ Print out the ref name given on the command line by which each
+ commit was reached.
+
--full-diff::
Without this flag, "git log -p <path>..." shows commits that
touch the specified paths, and diffs about the same specified
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-10 9:58 UTC (permalink / raw)
To: Kai Blin; +Cc: Jakub Narebski, David Symonds, git, Tim Ansell
In-Reply-To: <200811091955.19304.kai@samba.org>
Hi,
On Sun, 9 Nov 2008, Kai Blin wrote:
> On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
>
> > The workaround is to put all large files for example in 'media/'
> > folder, and make this folder be submodule. Each clone of repository
> > can have this 'media' submodule either present (both in object
> > database, although usually separate from main project object
> > database), or not present (not cloned and not checked out).
>
> Tim was talking about that media/ folder and managing that in git. If
> you want to work on the media, you might end up getting hundreds of
> gigabytes of data to get that folder, even if you only need to change
> one single file.
>
> That's the issue we're running into, and I don't thing submodules solve
> this at all.
You'd have to have a single repository for each and every media file, and
you'd need to use shallow clones and shallow fetches.
However, a push-conflict will probably be beyond any non-programmer
skillz.
I'd rather propose to have a different interface, like through a web
server, where the user can say "I have some cool new graphics, in this
.zip file" together with a commit message.
Kind of a git-gui via browser.
Ciao,
Dscho
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 9:49 UTC (permalink / raw)
To: dhruva; +Cc: sverre, git
In-Reply-To: <e3f230850811091943k63e4a93n566402458a6947dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
> On Mon, Nov 10, 2008 at 6:46 AM, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> I would like the "$Id$" sequences to be updated automatically after
>> a commit (ie. without the need to check out).
dhruva <dhruvakm@gmail.com> writes:
> There is no direct way to get this $Id$ expansion in git, however you
> can use a simple pre-commit hook (alpha state, more a proof of concept
> that happens to work for me)
>
> #!/usr/bin/env bash
>
> for file in `git diff-index --name-only --diff-filter=AM HEAD` ; do
> perl -pi -e 's/(\$[ \t]*Id)(.*)([ \t]*\$)/"\$Id: git
> ".time()." \$"/e' ${file}
> git add ${file} > /dev/null
> done
In fact the following works just as well:
#v+
files=$(git diff-index --name-only --diff-filter=AM HEAD)
perl -pi -e 's/\$\s*Id.*?\$/\$Id: git '$(TZ=UTC date +%s)' \$/g' $files
git add $files
#v-
But then again, it has two unpleasant side effects: (i) all modified
files are added and (ii) if I abort a commit the file stays modified.
(i) can be fixed by removing "git add" but then again (iii) even files
which are not committed will be modified.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Simon Hausmann @ 2008-11-10 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, John Chapman, git
In-Reply-To: <7vr65kagvm.fsf@gitster.siamese.dyndns.org>
On Sunday 09 November 2008 Junio C Hamano, wrote:
> These are patches to fast-import/git-p4, which you two seem to in charge
> of.
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 1/2] Added support for purged files and also optimised
> memory usage. Date: Sat, 8 Nov 2008 14:22:48 +1100
> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 2/2] Cached the git configuration, which is now
> noticibly faster on windows. Date: Sat, 8 Nov 2008 14:22:49 +1100
> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
>
> It was unfortunately not immediately obvious from the Subject: line what
> these patches are about, and I am guessing you missed them because of that.
Ack on both patches. The second one could be done better, as suggested in the
follow-ups, but both are clearly an improvement :)
Simon
^ permalink raw reply
* Re: Large media in git (was: How it was at GitTogether'08)?
From: Jakub Narebski @ 2008-11-10 9:30 UTC (permalink / raw)
To: Kai Blin; +Cc: git, Tim Ansell
In-Reply-To: <200811091955.19304.kai@samba.org>
On Sun, 9 Nov 2008, Kai Blin wrote:
> On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
>
> > The workaround is to put all large files for example in 'media/' folder,
> > and make this folder be submodule. Each clone of repository can have
> > this 'media' submodule either present (both in object database, although
> > usually separate from main project object database), or not present
> > (not cloned and not checked out).
>
> Tim was talking about that media/ folder and managing that in git. If you want
> to work on the media, you might end up getting hundreds of gigabytes of data
> to get that folder, even if you only need to change one single file.
>
> That's the issue we're running into, and I don't thing submodules solve this
> at all.
Ah, well... Submodules cannot be workaround for _this_ issue. You can
have only all or nothing: either all files in media/ or none of them,
both in working directory like in repository object database... well
unless you subdivide further.
I guess that mentioned work on the media is in remote setting (you
cannot have main repository on network drive) so Dana How's proposed
solution would not work for you, is it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Steve Frécinaux @ 2008-11-10 8:38 UTC (permalink / raw)
To: Arafangion; +Cc: David Symonds, git
In-Reply-To: <1226127130.8252.6.camel@therock.nsw.bigpond.net.au>
Arafangion wrote:
> On Fri, 2008-11-07 at 21:19 -0800, David Symonds wrote:
> <snip>
>> _gitConfig = None
>> def gitConfig(key):
>> if _gitConfig is None:
>> lines = read_pipe("git config -l", ignore_error=True).readlines():
>> _gitConfig = dict([l.strip().split('=', 1) for l in lines])
>> return _gitConfig.get(key, None)
>
> That certainly is better, if one can assume that git's configuration is
> small. (And relative to the memory usage of the script, it will
> definetly be small).
What about using git config --get-regexp to only get the p4-related
settings ?
I don't really know the options used by git-p4, but something like this
seems like a good candidate to address every trade-off concerns?
git-config --get-regexp '^(p4|user)\.'
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Aristotle Pagaltzis @ 2008-11-10 8:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <200811100849.36736.fg@one2team.com>
* Francis Galiegue <fg@one2team.com> [2008-11-10 08:55]:
> Le Monday 10 November 2008 01:38:30 Ian Hilt, vous avez écrit :
> > On Sun, 9 Nov 2008, Junio C Hamano wrote:
> > > Ian Hilt <ian.hilt@gmx.com> writes:
> > > > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> > > >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > > >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > > >>
> > > >> Greedy operators are only supported with perl 5.10 or more... I think
> > > >> it's a bad idea to use them...
Possessive quantification is supported in much earlier versions
of Perl, it’s just more awkward syntactically:
/^To:(?>\s*)(.+)\s*\nCc:/ism
But possessification is not going to make a difference in this
regex, since .+ can match anything that \s* can also match, so
the only difference is that if the regex does happen to
backtrack, it will backtrack over all the spaces after the To:
at once instead of one at a time.
I have only just subscribed so I do not have enough context to
know what the problem is, but based on what I have seen so far it
seems to me that all you want is simply
/^To:\s?(.+)\s*\nCc:/ism
although I have to wonder if the /s modifier here is really what
you want.
> I think the correct term for *+, ++, ?+ etc is "possessive"
> quantifiers, I'm just not sure.
That is correct.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:59 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit, Junio C Hamano
In-Reply-To: <200811100857.10802.fg@one2team.net>
Le Monday 10 November 2008 08:57:10 Francis Galiegue, vous avez écrit :
> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> [...]
>
> > + my @recipients = split(/\s*,\s*/, $match);
>
> This is where it gets complicated, for the "hey, I am" <some@one> case...
>
> But then there is a solution: use a negative lookahead for the split regex.
>
> I thought about splitting against /\s*,\s*(?![^"]+(?:\"[^*]*)*)"/.
>
Oops, that should have been /\s*,\s*(?![^"]+(?:\"[^*]*)*")/, sorry :/
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:57 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit, Junio C Hamano
In-Reply-To: <1226235588-2997-1-git-send-email-ian.hilt@gmx.com>
Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
[...]
> + my @recipients = split(/\s*,\s*/, $match);
This is where it gets complicated, for the "hey, I am" <some@one> case...
But then there is a solution: use a negative lookahead for the split regex.
I thought about splitting against /\s*,\s*(?![^"]+(?:\"[^*]*)*)"/.
A negative lookbehind would have been clearer to write, but perl doesn't
support arbitrary length negative lookbehinds, except by using a very, very
arcane construct.
--
fge
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:49 UTC (permalink / raw)
To: Ian Hilt; +Cc: Junio C Hamano, Git Mailing List, Pierre Habouzit
In-Reply-To: <alpine.LFD.2.00.0811091910570.21142@sys-0.hiltweb.site>
Le Monday 10 November 2008 01:38:30 Ian Hilt, vous avez écrit :
> On Sun, 9 Nov 2008, Junio C Hamano wrote:
> > Ian Hilt <ian.hilt@gmx.com> writes:
> > > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> > >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > >>
> > >> Greedy operators are only supported with perl 5.10 or more... I think
> > >> it's a bad idea to use them...
> > >
> > > The problem here was that a space should follow the field, but it may
> > > not. The user may unwarily backup over it. "\s*" would match this
> > > case.
> > >
> > > But if there is a space, it is included in the "(.+)". So I tried
> > > "\s+", which did not include the space, but it won't include the first
> > > address if there isn't a space after the field.
> > >
> > > The quantified subpattern seemed to do the trick. But, if it could
> > > result in a dependency issue, I would agree this would be a bad idea.
> >
> > You expect something non-blank there anyway, so why not do:
> >
> > To:\s*(\S.*?)\s*\n....
>
> That works. Although, I seem to be missing Francis' point.
No. The _lazy_ quantifiers (*?, ??, *?, +?, {...}?) are supported all right.
But they should be avoided in general.
> According
> to perlre, a quantified subpattern is "greedy". So a "greedy operator"
> is any one of the standard quantified subpatterns. The "+" and "?"
> modify its matching behavior. And it seems to me that it _has_ to use a
> q.s. to work ...
My wording may be bad, then. They're not greedy, they just don't allow for
backtracking. They are more than greedy. Let me explain.
Consider "number 42" for instance. If you match it against:
* .*(\d+) => $1 would be "2": the * eats everything but _has_ to backtrack for
\d+ to get anything, but just one number is enough;
* .*?(\d+) => $1 would be "42": as *? is lazy, this means that after each
match, it looks to see whether the next element in the regex would match
anything; as soon as \d+ matches 4, .*? stops there;
* .*+(\d+) => $1 would match nothing! *+ eats everything, but the + afterwards
_doesn't allow it to backtrack_.
I hope this makes things a little clearer ;) I think the correct term for *+,
++, ?+ etc is "possessive" quantifiers, I'm just not sure.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-10 7:38 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30811091052k77200785j722c8aed2beb7684@mail.gmail.com>
Hi!
>>> The attached file is a result of running `git diff HEAD~1`.
>
> Please read Documentation/SubmittingPatches for the preferred way to
> contribute patches.
Ok, I'll look there, when you tell me this patch is worth anything.
>>> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
>>> sometimes unwanted -- especially when citing command line options like
>>> "git diff --cached". This commit includes proper quotes in user-manual.txt.
>
> Newer asciidoc versions have the following "workaround". Maybe adding
> something like this to Documentation/asciidoc.conf would be more
> future proof.
>
> # -- Spaced and unspaced em dashes (entity reference —)
> # But disallow unspaced in man pages because double-dash option name prefixes
> # are pervasive.
> ifndef::doctype-manpage[]
> (^|[^-\\])--($|[^-])=\1—\2
> endif::doctype-manpage[]
> ifdef::doctype-manpage[]
> (^|\s*[^\S\\])--($|\s+)=\1—\2
> endif::doctype-manpage[]
> \\--(?!-)=--
Well, this doesn't solve the problem -- I'm not talking about
manpages, the "--" where replaced with single "—" on the
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html page.
Yes, we can disable such a replacement in the config file, but take a
look at the sentence "...how to fetch and study a project using
git—read these chapters...". In this case "--" in the source file was
replaced with "—" and this is what we want.
I noticed that all substitutions "--" -> "—", where "—" is a part of
sentence punctuation, match \w--\w pattern (e.g. no spaces on both
sides) and probably this is how it should be written in English. But
basing on this doesn't seem to me to be fool proof.
Best regards,
Piotr
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Johannes Sixt @ 2008-11-10 7:26 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: sverre, git
In-Reply-To: <87hc6gjs7v.fsf@erwin.mina86.com>
Michal Nazarewicz schrieb:
> (Besides I would prefer
> $Date$ more but I can live with $Id$ I guess ;) ).
Just FYI: The $Id$ that git produces is completely different from what CVS
produces and probably not what you expect: 'man gitattributes'
-- Hannes
^ permalink raw reply
* [PATCH 2/3] sha1_file.c: split has_loose_object() into local and non-local counterparts
From: drafnel @ 2008-11-10 5:59 UTC (permalink / raw)
To: gitster; +Cc: git, spearce, nico, ae, Brandon Casey
In-Reply-To: <1226296798-31522-2-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
cache.h | 1 +
sha1_file.c | 19 +++++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index 37ab457..1ec90f1 100644
--- a/cache.h
+++ b/cache.h
@@ -578,6 +578,7 @@ extern int move_temp_to_file(const char *tmpfile, const char *filename);
extern int has_sha1_pack(const unsigned char *sha1, const char **ignore);
extern int has_sha1_file(const unsigned char *sha1);
+extern int has_loose_object_nonlocal(const unsigned char *sha1);
extern int has_pack_file(const unsigned char *sha1);
extern int has_pack_index(const unsigned char *sha1);
diff --git a/sha1_file.c b/sha1_file.c
index f2b25bd..4912205 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -423,23 +423,30 @@ void prepare_alt_odb(void)
read_info_alternates(get_object_directory(), 0);
}
-static int has_loose_object(const unsigned char *sha1)
+static int has_loose_object_local(const unsigned char *sha1)
{
char *name = sha1_file_name(sha1);
- struct alternate_object_database *alt;
+ return !access(name, F_OK);
+}
- if (!access(name, F_OK))
- return 1;
+int has_loose_object_nonlocal(const unsigned char *sha1)
+{
+ struct alternate_object_database *alt;
prepare_alt_odb();
for (alt = alt_odb_list; alt; alt = alt->next) {
- name = alt->name;
- fill_sha1_path(name, sha1);
+ fill_sha1_path(alt->name, sha1);
if (!access(alt->base, F_OK))
return 1;
}
return 0;
}
+static int has_loose_object(const unsigned char *sha1)
+{
+ return has_loose_object_local(sha1) ||
+ has_loose_object_nonlocal(sha1);
+}
+
static unsigned int pack_used_ctr;
static unsigned int pack_mmap_calls;
static unsigned int peak_pack_open_windows;
--
1.6.0.2.588.g3102
^ 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