* Re: How it was at GitTogether'08 ?
From: Jonas Fonseca @ 2008-11-11 22:05 UTC (permalink / raw)
To: Jakub Narebski
Cc: Steven Grimm, Shawn O. Pearce, Robin Rosenberg, git, Jeff King,
Petr Baudis, Tim Ansell
In-Reply-To: <200811100052.16740.jnareb@gmail.com>
On Mon, Nov 10, 2008 at 00:52, Jakub Narebski <jnareb@gmail.com> wrote:
> Would it be possible to publish PDF version sowehere, for example
> as attachement to http://git.or.cz/gitwiki/GitTogether? My old
> web browser doesn't support Google Docs...
http://docs.google.com/MiscCommands?command=saveasdoc&docID=dhhs72s2_1wtzbnsnj&exportFormat=pdf
--
Jonas Fonseca
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-11 22:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Farrukh Najmi, git
In-Reply-To: <20081111214434.GS2932@spearce.org>
On Tue, Nov 11, 2008 at 22:44, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>> I would also like to have a public available maven repository for
>> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
>> area of the Google Code project page. Given the lack of a real release
>> cycle it probably only makes sense to have a snapshot repository.
>
> I have an account on kernel.org and was planning on hosting snapshots
> there, but I haven't had time to think about setting up a jgit area
> and pushing something into it. ;-)
If you prefer that ...
> We could also just host it in SVN in Google Code. I can give
> you admin rights on the egit project if you want to set it up and
> maintain it there. The downside is you need to use svn or git-svn
> to upload files to it, right?
I don't think admin rights are necessary as long as I have
"commit"/webdav access. And no svn or git-svn interaction should be
needed to upload to the maven repository.
Take a look at the distributionManagement section of the
google-maven-repository:
- http://google-maven-repository.googlecode.com/svn/repository/com/google/google/1/google-1.pom
Looks pretty easy to set up. About maintaining it, I don't mind doing
"mvn deploy" once in a while, but some kind of update policy should
probably be worked out in any case.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH v2] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-11 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Current git versions ignore everything after # (called <head> in the
following) when pushing. Older versions (before cf818348f1ab57),
interpret #<head> as part of the URL, which make git bail out.
As branches origin from Cogito, it is the best to correct this by
using the behaviour of cg-push:
push HEAD to remote refs/heads/<head>
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
Rebased to maint. One line dropped from commit message. Fixed typo,
reported by Mike Ralphson.
urls-remote.txt is unchanged between maint and next.
remote.c contains no changes in read_branches_file.
t5516 needed a manual invention.
Apart from merge problems (test ordering) in t5516, it should apply
to master or next too.
Documentation/urls-remotes.txt | 19 +++++++++++----
remote.c | 11 ++++++++
t/t5516-fetch-push.sh | 50 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 504ae8a..41ec777 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -68,13 +68,22 @@ This file should have the following format:
------------
`<url>` is required; `#<head>` is optional.
-When you do not provide a refspec on the command line,
-git will use the following refspec, where `<head>` defaults to `master`,
-and `<repository>` is the name of this file
-you provided in the command line.
+
+Depending on the operation, git will use one of the following
+refspecs, if you don't provide one on the command line.
+`<branch>` is the name of this file in `$GIT_DIR/branches` and
+`<head>` defaults to `master`.
+
+git fetch uses:
+
+------------
+ refs/heads/<head>:refs/heads/<branch>
+------------
+
+git push uses:
------------
- refs/heads/<head>:<repository>
+ HEAD:refs/heads/<head>
------------
diff --git a/remote.c b/remote.c
index 7688f3b..91f1b7c 100644
--- a/remote.c
+++ b/remote.c
@@ -298,6 +298,17 @@ static void read_branches_file(struct remote *remote)
}
add_url_alias(remote, p);
add_fetch_refspec(remote, strbuf_detach(&branch, 0));
+ /*
+ * Cogito compatible push: push current HEAD to remote #branch
+ * (master if missing)
+ */
+ strbuf_init(&branch, 0);
+ strbuf_addstr(&branch, "HEAD");
+ if (frag)
+ strbuf_addf(&branch, ":refs/heads/%s", frag);
+ else
+ strbuf_addstr(&branch, ":refs/heads/master");
+ add_push_refspec(remote, strbuf_detach(&branch, 0));
remote->fetch_tags = 1; /* always auto-follow */
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 598664c..f9e8780 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -494,4 +494,54 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'fetch with branches' '
+ mk_empty &&
+ git branch second $the_first_commit &&
+ git checkout second &&
+ echo ".." > testrepo/.git/branches/branch1 &&
+ (cd testrepo &&
+ git fetch branch1 &&
+ r=$(git show-ref -s --verify refs/heads/branch1) &&
+ test "z$r" = "z$the_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'fetch with branches containing #' '
+ mk_empty &&
+ echo "..#second" > testrepo/.git/branches/branch2 &&
+ (cd testrepo &&
+ git fetch branch2 &&
+ r=$(git show-ref -s --verify refs/heads/branch2) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'push with branches' '
+ mk_empty &&
+ git checkout second &&
+ echo "testrepo" > .git/branches/branch1 &&
+ git push branch1 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/master) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ )
+'
+
+test_expect_success 'push with branches containing #' '
+ mk_empty &&
+ echo "testrepo#branch3" > .git/branches/branch2 &&
+ git push branch2 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/branch3) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* Re: Newbie questions regarding jgit
From: Shawn O. Pearce @ 2008-11-11 21:44 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Farrukh Najmi, git
In-Reply-To: <2c6b72b30811111337v2fe23c75v25251838f721a007@mail.gmail.com>
Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>
> I would also like to have a public available maven repository for
> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
> area of the Google Code project page. Given the lack of a real release
> cycle it probably only makes sense to have a snapshot repository.
I have an account on kernel.org and was planning on hosting snapshots
there, but I haven't had time to think about setting up a jgit area
and pushing something into it. ;-)
We could also just host it in SVN in Google Code. I can give
you admin rights on the egit project if you want to set it up and
maintain it there. The downside is you need to use svn or git-svn
to upload files to it, right?
--
Shawn.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-11 21:37 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <4919EECB.7070408@wellfleetsoftware.com>
On Tue, Nov 11, 2008 at 21:44, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
> Hi all,
Hello,
> I am git newbie and looking to use jgit in a servlet endpoint.
Sounds interesting. I have been thinking about how hard it would be to
write a very simpe jgitweb kind of thing and am very interested to
hear more about your experiences.
> Where can I find a public maven repo for gjit? It seems there is one
> somewhere because of the following file in src tree:
I would also like to have a public available maven repository for
JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
area of the Google Code project page. Given the lack of a real release
cycle it probably only makes sense to have a snapshot repository.
> Now I am wondering where to begin to learn how to do the equivalent of the
> following commands via the gjit Java API:
>
> * git add /file/
> * git rm /file/
> * git mv /file
> * Whatever is the git way to get a specific version of a file
JGit currently has two APIs for working with the index, which will
allow you to add, remove and move data around in the tree. In nbgit I
ended up using GitIndex, which I found easier to figure out. As I
understand it, in the long run you want to use the DirCache API, but
it is still a work in progress.
> I am hoping that there aremore docs, samples, tutorials etc. somewhere that
> I am missing. Thanks for any help you can provide. Some pointers or code
> fragments would be terrific.
I started working on a tutorial for JGit, but didn't get very far so
it mostly consists of stub pages.
- http://code.google.com/docreader/#p=egit&s=egit&t=JGitTutorial
I have been working on moving the tutorial to maven project before
starting to write the more code heavy topics. This would make it
possible to include code snippets in the tutorial, while also allowing
to compile and test the examples.
--
Jonas Fonseca
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Junio C Hamano @ 2008-11-11 21:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> * David Brown: Life with Git
> http://www.davidb.org/git/git-corp.pdf
I really enjoyed this talk, which was in a weird sense very encouraging.
By the way, one thing David talked about that is not in the PDF slides but
I found quite good to stress was the importance of good commit messages.
"Write in present tense, it will read much nicer and you'll appreciate it
after reading hundreds of them".
I'd actually say "imperative mood" instead of "present tense" (but they
look almost always the same in English), but in any case, it really gets
on my nerve to read commit message that talks things in past tense and I
often end up rewriting other people's commit log messages.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-11 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <4919EECB.7070408@wellfleetsoftware.com>
I should clarify that I am not using eclipse nor am I using any GUI. My
objective is to have Java API access to git from within a servlet using
jgit. At present, all I have to go on is javadoc and its not clear where
to begin if I simply wish to create, read and update files in a git repo
from within the servlet java code.
TIA for your help.
Farrukh Najmi wrote:
>
> Hi all,
>
> I am git newbie and looking to use jgit in a servlet endpoint.
>
> Where can I find a public maven repo for gjit? It seems there is one
> somewhere because of the following file in src tree:
>
> jgit-maven/jgit/pom.xml
>
> For now I have built the jar using /make_jgit.sh and installed the pom
> manually using m
>
> mvn install:install-file -DpomFile=jgit-maven/jgit/pom.xml
> -Dfile=jgit.jar
>
> I have added the following dependency to my maven project's pom.xml:
>
> <dependency>
> <groupId>org.spearce</groupId>
> <artifactId>jgit</artifactId>
> <version>0.4-SNAPSHOT</version>
> </dependency>
>
> Now I am wondering where to begin to learn how to do the equivalent of
> the following commands via the gjit Java API:
>
> * git add /file/
> * git rm /file/
> * git mv /file
> * Whatever is the git way to get a specific version of a file
>
>
> I am hoping that there aremore docs, samples, tutorials etc. somewhere
> that I am missing. Thanks for any help you can provide. Some pointers
> or code fragments would be terrific.
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Install issues
From: Junio C Hamano @ 2008-11-11 21:11 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Miklos Vajna, git
In-Reply-To: <20081110173101.3d76613b@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> ./test-sha1.sh
>
> check: common-cmds.h
> + @`sparse </dev/null 2>/dev/null` || (\
> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> + echo "Did you mean 'make test' instead?" ;\
> + exit 1 )
When you mean "grouping", using {} is much clearer to convey your
intention. Use of needless (subshell) forces the reader to wonder if you
wanted to do something that affects the environment for later commands
inside, and in this case you didn't.
Why do you have sparse check inside a backtick to produce a string to be
interpreted as a command to be executed?
How about doing this instead? 'sparse' without any parameter exits with
success status silently; when you do not have the command, the shell will
complain with "sparse: command not found" anyway, so you only need to
suggest "make 'test'" and nothing else.
-- >8 --
Subject: Makefile: help people who run 'make check' by mistake
The target to run self test is 'make test', but there are people who try
'make check' and worse yet do not have sparse installed.
Suggest 'make test' target when they do not have 'sparse'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git c/Makefile w/Makefile
index 40309e1..d3137ca 100644
--- c/Makefile
+++ w/Makefile
@@ -1355,7 +1355,16 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
- for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
+ if sparse; \
+ then \
+ for i in *.c; \
+ do \
+ sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; \
+ done; \
+ else \
+ echo 2>&1 "Did you mean 'make test'?"; \
+ exit 1; \
+ fi
remove-dashes:
./fixup-builtins $(BUILT_INS) $(PROGRAMS) $(SCRIPTS)
^ permalink raw reply related
* [PATCH] git-submodule: Avoid printing a spurious message.
From: Alexandre Julliard @ 2008-11-11 21:09 UTC (permalink / raw)
To: git
Fix 'git submodule update' to avoid printing a spurious "Maybe you want
to use 'update --init'?" once for every uninitialized submodule it
encounters.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index b63e5c3..220d94e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -323,7 +323,7 @@ cmd_update()
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
- say "Submodule path '$path' not initialized"
+ say "Submodule path '$path' not initialized" &&
say "Maybe you want to use 'update --init'?"
continue
fi
--
1.6.0.4.637.ga2ff4
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Alexander Gavrilov @ 2008-11-11 20:55 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Transient windows cause problems on these platforms:
- On Win32 the windows appear in the top left corner
of the screen. In order to fix it, this patch causes
them to be explicitly centered on their parents by
an idle handler.
- On MacOS with Tk 8.4 they appear without a title bar.
Since it is clearly unacceptable, this patch disables
transient on that platform.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
NOTE: This patch DEPRECATES the earlier one, called
"Explicitly position popup windows"
Alexander
gitk | 44 +++++++++++++++++++++++++++++++-------------
1 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/gitk b/gitk
index 9b2a6e5..e6aafe8 100755
--- a/gitk
+++ b/gitk
@@ -1739,6 +1739,24 @@ proc removehead {id name} {
unset headids($name)
}
+proc make_transient {window origin} {
+ global have_tk85
+
+ # In MacOS Tk 8.4 transient appears to work by setting
+ # overrideredirect, which is utterly useless, since the
+ # windows get no border, and are not even kept above
+ # the parent.
+ if {!$have_tk85 && [tk windowingsystem] eq {aqua}} return
+
+ wm transient $window $origin
+
+ # Windows fails to place transient windows normally, so
+ # schedule a callback to center them on the parent.
+ if {[tk windowingsystem] eq {win32}} {
+ after idle [list tk::PlaceWindow $window widget $origin]
+ }
+}
+
proc show_error {w top msg} {
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
@@ -1754,7 +1772,7 @@ proc show_error {w top msg} {
proc error_popup {msg {owner .}} {
set w .error
toplevel $w
- wm transient $w $owner
+ make_transient $w $owner
show_error $w $w $msg
}
@@ -1763,7 +1781,7 @@ proc confirm_popup {msg {owner .}} {
set confirm_ok 0
set w .confirm
toplevel $w
- wm transient $w $owner
+ make_transient $w $owner
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
button $w.ok -text [mc OK] -command "set confirm_ok 1; destroy $w"
@@ -2558,7 +2576,7 @@ proc about {} {
}
toplevel $w
wm title $w [mc "About gitk"]
- wm transient $w .
+ make_transient $w .
message $w.m -text [mc "
Gitk - a commit viewer for git
@@ -2587,7 +2605,7 @@ proc keys {} {
}
toplevel $w
wm title $w [mc "Gitk key bindings"]
- wm transient $w .
+ make_transient $w .
message $w.m -text "
[mc "Gitk key bindings:"]
@@ -3669,7 +3687,7 @@ proc vieweditor {top n title} {
toplevel $top
wm title $top $title
- wm transient $top .
+ make_transient $top .
# View name
frame $top.nfr
@@ -7912,7 +7930,7 @@ proc mkpatch {} {
set patchtop $top
catch {destroy $top}
toplevel $top
- wm transient $top .
+ make_transient $top .
label $top.title -text [mc "Generate patch"]
grid $top.title - -pady 10
label $top.from -text [mc "From:"]
@@ -7999,7 +8017,7 @@ proc mktag {} {
set mktagtop $top
catch {destroy $top}
toplevel $top
- wm transient $top .
+ make_transient $top .
label $top.title -text [mc "Create tag"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -8102,7 +8120,7 @@ proc writecommit {} {
set wrcomtop $top
catch {destroy $top}
toplevel $top
- wm transient $top .
+ make_transient $top .
label $top.title -text [mc "Write commit to file"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -8159,7 +8177,7 @@ proc mkbranch {} {
set top .makebranch
catch {destroy $top}
toplevel $top
- wm transient $top .
+ make_transient $top .
label $top.title -text [mc "Create new branch"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -8322,7 +8340,7 @@ proc resethead {} {
set confirm_ok 0
set w ".confirmreset"
toplevel $w
- wm transient $w .
+ make_transient $w .
wm title $w [mc "Confirm reset"]
message $w.m -text \
[mc "Reset branch %s to %s?" $mainhead [string range $rowmenuid 0 7]] \
@@ -8502,7 +8520,7 @@ proc showrefs {} {
}
toplevel $top
wm title $top [mc "Tags and heads: %s" [file tail [pwd]]]
- wm transient $top .
+ make_transient $top .
text $top.list -background $bgcolor -foreground $fgcolor \
-selectbackground $selectbgcolor -font mainfont \
-xscrollcommand "$top.xsb set" -yscrollcommand "$top.ysb set" \
@@ -9844,7 +9862,7 @@ proc choosefont {font which} {
font create sample
eval font config sample [font actual $font]
toplevel $top
- wm transient $top $prefstop
+ make_transient $top $prefstop
wm title $top [mc "Gitk font chooser"]
label $top.l -textvariable fontparam(which)
pack $top.l -side top
@@ -9961,7 +9979,7 @@ proc doprefs {} {
}
toplevel $top
wm title $top [mc "Gitk preferences"]
- wm transient $top .
+ make_transient $top .
label $top.ldisp -text [mc "Commit list display options"]
grid $top.ldisp - -sticky w -pady 10
label $top.spacer -text " "
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-11 20:53 UTC (permalink / raw)
To: Ian Hilt; +Cc: Tait, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811111542230.24205@sys-0.hiltweb.site>
Le Tuesday 11 November 2008 21:47:55 Ian Hilt, vous avez écrit :
> On Tue, 11 Nov 2008, Francis Galiegue wrote:
> > Le Tuesday 11 November 2008 02:49:19 Tait, 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 "(.+)".
> > >
> > > Not in any version of Perl to which I have access.
> >
> > And if you see a space in (.+), your regex engine is buggy anyway.
>
> So what does this script produce on your systems?
>
>
> #!/usr/bin/perl -Tw
> --8<--
> use strict;
> my $ws = "To: \nCc:";
>
> $ws =~ /^To:\s*(.+)\s*\nCc:/ism;
>
> if ($1 eq ' ') {
> print "\$1 is equal to a space.\n";
> }
> -->8--
>
> On mine, it prints the message. So it seems it is matching _a_ space.
Which is perfectly normal. The first \s* wanted spaces, it got them. But it
left nothing for the capturing .+ behind. And any quantifier (except when it
is possessive) _MUST_ backtrack in order for the full regex to complete. This
is why the .+ captured the space: the first \s* was perfectly fine with no
space at all, and the second, well, didn't find any space but it didn't care
either.
--
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: Ian Hilt @ 2008-11-11 20:53 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Tait, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811111542230.24205@sys-0.hiltweb.site>
On Tue, 11 Nov 2008, Ian Hilt wrote:
Hm, how about keeping the path to perl in the snippet,
--8<--
#!/usr/bin/perl -Tw
use strict;
my $ws = "To: \nCc:";
$ws =~ /^To:\s*(.+)\s*\nCc:/ism;
if ($1 eq ' ') {
print "\$1 is equal to a space.\n";
}
-->8--
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-11 20:47 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Tait, Git Mailing List
In-Reply-To: <200811111230.28076.fg@one2team.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1116 bytes --]
On Tue, 11 Nov 2008, Francis Galiegue wrote:
> Le Tuesday 11 November 2008 02:49:19 Tait, 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 "(.+)".
> >
> > Not in any version of Perl to which I have access.
> >
>
> And if you see a space in (.+), your regex engine is buggy anyway.
So what does this script produce on your systems?
#!/usr/bin/perl -Tw
--8<--
use strict;
my $ws = "To: \nCc:";
$ws =~ /^To:\s*(.+)\s*\nCc:/ism;
if ($1 eq ' ') {
print "\$1 is equal to a space.\n";
}
-->8--
On mine, it prints the message. So it seems it is matching _a_ space.
This resulted in an illegal recipient field. Junio's suggestion to
change this to
/^To:\s*(\S.+?)\s*\nCc:/ism
worked beautifully.
^ permalink raw reply
* Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-11 20:44 UTC (permalink / raw)
To: git
Hi all,
I am git newbie and looking to use jgit in a servlet endpoint.
Where can I find a public maven repo for gjit? It seems there is one
somewhere because of the following file in src tree:
jgit-maven/jgit/pom.xml
For now I have built the jar using /make_jgit.sh and installed the pom
manually using m
mvn install:install-file -DpomFile=jgit-maven/jgit/pom.xml -Dfile=jgit.jar
I have added the following dependency to my maven project's pom.xml:
<dependency>
<groupId>org.spearce</groupId>
<artifactId>jgit</artifactId>
<version>0.4-SNAPSHOT</version>
</dependency>
Now I am wondering where to begin to learn how to do the equivalent of
the following commands via the gjit Java API:
* git add /file/
* git rm /file/
* git mv /file
* Whatever is the git way to get a specific version of a file
I am hoping that there aremore docs, samples, tutorials etc. somewhere
that I am missing. Thanks for any help you can provide. Some pointers or
code fragments would be terrific.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [take 2] git send-email updates
From: Junio C Hamano @ 2008-11-11 20:30 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1226361242-2516-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> The last patch is dropped for now (the automatic --compose stuff)
> because I'm not sure which option to add, and that I don't care enough
> about it to spend more time on it.
>
> I think I've incorporated most of the stuff people asked about in this
> series.
>
> [PATCH 1/4] git send-email: make the message file name more specific.
> [PATCH 2/4] git send-email: interpret unknown files as revision lists
> [PATCH 3/4] git send-email: add --annotate option
> [PATCH 4/4] git send-email: ask less questions when --compose is used.
Thanks.
It is somewhat unfortunate that an explicit --no-format-patch works
exactly the same way as not giving the option at all. I would have
expected that it would guess and warn if you did not give either, and it
would not even guess (i.e. file is mbox, dir is maildir) and error out if
there is a leftover option in @rev_list_opts if the user explicitly asked
the command not act as a frontend to format patch.
I will queue the series in 'pu' because I suspect you would like a chance
to amend out a "print foo" from the second commit ;-)
^ permalink raw reply
* Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Constantine Plotnikov @ 2008-11-11 19:12 UTC (permalink / raw)
To: git
If encoding is forced for git log with "--encoding=UTF-8", it seems to
be ineffective for the formatted output. Is it intentional?
Lets consider the following scenario (script is for bash, git 1.5.4.3
and 1.6.0.2):
git init
echo initial >test.txt
git add test.txt
echo -e \\0320\\0242\\0320\\0265\\0321\\0201\\0321\\0202 >msg-UTF-8.txt
git commit -F msg-UTF-8.txt
echo updated >test.txt
git add test.txt
echo -e \\0322\\0345\\0361\\0362 >msg-windows-1251.txt
git config i18n.commitencoding Windows-1251
git commit -F msg-windows-1251.txt
git log --encoding=Windows-1251 >log1.txt
git log --encoding=UTF-8 >log2.txt
git log --encoding=Windows-1251 --pretty=format:%e%n%s%n >log3.txt
git log --encoding=UTF-8 --pretty=format:%e%n%s%n >log4.txt
In the both cases the string is the russian string meaning test in
different encoding.
If we compare log1.txt and log2.txt, we will see that the same
encoding specified is used for both commits in the log.
If we compare log3.txt and log4.txt, we will see that the same the
contents of the file is completely identical. The native encoding is
used for each commit. So the first listed commit
is encoded using Windows-1251 and the second one using UTF-8. However
in the description of the %s %b options nothing is said about which
encoding is used and implied behavior is that they are affected by
--encoding option.
I suggest documenting that the placeholders %s and %b use native
commit encoding and introducing the placeholders %S and %B options
that use encoding specified on the command line or the default log
encoding.
I also suggest adding %g and %G placeholders (%m placeholder is
already occupied) that print the entire commit message instead of just
the subject or the body. Currently the tools have to join the entire
message from two parts when they are just interested in the entire
message.
Regards,
Constantine
^ permalink raw reply
* Re: [EGIT PATCH 6/7] Add tags to the graphical history display.
From: Shawn O. Pearce @ 2008-11-11 18:32 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226095664-13759-7-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Both the SWT (Eclipse) drawing and Swing versions are updated.
> The coloring and shapes are intentionally not the same as for gitk.
Despite my comments about the series, I really like the rendering
in SWT. I'm looking forward to getting this in-tree, but I would
like to get a better definition of the Ref peeling API.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 6/7] Add tags to the graphical history display.
From: Shawn O. Pearce @ 2008-11-11 18:28 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226095664-13759-7-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -92,7 +104,64 @@ protected void drawText(final String msg, final int x, final int y) {
> g.drawString(msg, cellX + x, cellY + texty, true);
> }
My SWTPlotRenderer doesn't have this context line. Am I missing
a patch in the series?
> + @Override
> + protected int drawLabel(int x, int y, Ref ref) {
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 5/7] Add a method to get refs by object Id
From: Shawn O. Pearce @ 2008-11-11 18:26 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226095664-13759-6-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -952,6 +955,37 @@ public Ref peel(final Ref ref) {
> }
>
> /**
> + * @return a map with all objects referenced by a peeled ref.
> + */
> + public Map<AnyObjectId, Set<Ref>> getAllRefsByPeeledObjectId() {
> + Map<String, Ref> allRefs = getAllRefs();
> + Map<AnyObjectId, Set<Ref>> ret = new HashMap<AnyObjectId, Set<Ref>>(allRefs.size());
> + for (Ref ref : allRefs.values()) {
> + if (ref == null)
> + continue;
How did we get a null Ref inside the allRefs collection?
> + if (!ref.isPeeled()) {
> + ref = peel(ref);
> + allRefs.put(ref.getOrigName(), ref);
Hmm. Mutating a HashMap while you are traversing it with an Iterator
is *not* a good idea. Its a ConcurrentModificationException waiting
to happen.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 4/7] Handle peeling of loose refs.
From: Shawn O. Pearce @ 2008-11-11 18:23 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226095664-13759-5-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -238,10 +235,19 @@ public ObjectId getObjectId() {
> * refer to an annotated tag.
> */
> public ObjectId getPeeledObjectId() {
> + if (peeledObjectId == ObjectId.zeroId())
> + return null;
> return peeledObjectId;
> }
>
> /**
> + * @return whether the Ref represents a peeled tag
> + */
> + public boolean isPeeled() {
> + return peeledObjectId != null && peeledObjectId != ObjectId.zeroId();
> + }
Huh. So peeledObjectId == ObjectId.zeroId() means what, exactly?
That we tried to peel this but we cannot because its not a tag?
What does a packed-refs record which has no peel data but which
is in a packed-refs with-peeled file have for peeledObjectId?
null or ObjectId.zeroId()?
> @@ -288,6 +289,28 @@ private void readOneLooseRef(final Map<String, Ref> avail,
> }
> }
>
> + Ref peel(final Ref ref) {
> + if (ref.isPeeled())
> + return ref;
I think you mean something more like:
if (ref.peeledObjectId != null)
return ref;
as the ref is already peeled, or at least attempted.
> + try {
> + Object tt = db.mapObject(ref.getObjectId(), ref.getName());
> + if (tt != null && tt instanceof Tag) {
> + Tag t = (Tag)tt;
> + while (t != null && t.getType().equals(Constants.TYPE_TAG))
> + t = db.mapTag(t.getTag(), t.getObjId());
> + if (t != null)
> + ref.setPeeledObjectId(t.getObjId());
> + else
> + ref.setPeeledObjectId(null);
> + } else
> + ref.setPeeledObjectId(ref.getObjectId());
> + } catch (IOException e) {
> + // Serious error. Caller knows a ref should never be null
> + ref.setPeeledObjectId(null);
> + }
> + return ref;
This whole block is simpler to write as:
try {
Object target = db.mapObject(ref.getObjectId(), ref.getName());
while (target instanceof Tag) {
final Tag tag = (Tag)target;
ref.setPeeledObjectId(tag.getObjId());
if (Constants.TYPE_TAG.equals(tag.getType()))
target = db.mapObject(tag.getObjId(), ref.getName());
else
break;
}
} catch (IOException e) {
// Ignore a read error. Callers will also get the same error
// if they try to use the result of getPeeledObjectId.
}
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> index 26748e2..4d6e6fd 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> @@ -939,6 +939,19 @@ public String getBranch() throws IOException {
> }
>
> /**
> + * Peel a possibly unpeeled ref and updates it. If the ref cannot be peeled
> + * the peeled id is set to {@link ObjectId#zeroId()}
But applications never see ObjectId.zeroId() because you earlier defined
getPeeledObjectId() to return null in that case. So why is this part of
the documentation relevant?
> + *
> + * @param ref
> + * The ref to peel
> + * @return The same, an updated ref with peeled info or a new instance with
> + * more information
> + */
> + public Ref peel(final Ref ref) {
> + return refs.peel(ref);
Can we tighten this contract? Are we always going to update the
current ref in-place, or are we going to return the caller a new
Ref instance? I'd like it to be consistent one way or the other.
If we are updating in-place then the caller needs to realize there
may be some cache synchronization issues when using multiple threads
to access the same Ref instances and peeling them. I.e. they may
need to go through their own synchornization barrier to ensure the
processor caches are coherent.
Given that almost everywhere else we treat the Ref as immutable
I'm tempted to say this should always return a new Ref object if we
peeled; but return the parameter if the parameter is already peeled
(or is known to be unpeelable, e.g. a branch head).
--
Shawn.
^ permalink raw reply
* Re: problem with git gui on cygwin.
From: Alex Riesen @ 2008-11-11 18:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jim Jensen, git
In-Reply-To: <20081111170557.GI2932@spearce.org>
Shawn O. Pearce, Tue, Nov 11, 2008 18:05:57 +0100:
> Jim Jensen <jhjjhjjhj@gmail.com> wrote:
> > I have been trying to use git for a small project using cygwin. I copied my
> > repository from one windows XP system to a Vista system using a usb drive. On
> > the new system when I use "git gui" I get a pop up that says "Git directory not
> > found: .git"
> >
> > This happens with git gui and gitk. The command line programs I tried, git show
> > and git status appear to work.
>
> Huh. Sounds like the Tcl/Tk process isn't spawning the Cygwin git
> process in the right directory or something. Weird that both git-gui
> and gitk are giving you errors; usually its git-gui that is being
> paranoid about the repository structure and gitk works just fine.
>
> You can try starting `git gui --trace` and see if that tells you
> any more detail, but it doesn't show cwd so it may not be all that
> useful to help you debug it.
>
Maybe the fact that wish is not a cygwin application (doesn't use use
cygwin1.dll) is a hint?
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-11 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vhc6e17fv.fsf@gitster.siamese.dyndns.org>
On Tue, 11 Nov 2008 09:47:00 -0800, Junio C Hamano <gitster@pobox.com>
wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> >> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
> >> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
> >> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> >> ./test-sha1.sh
> >>
> >> check: common-cmds.h
> >> + @`sparse </dev/null 2>/dev/null` || (\
> >> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> >> + echo "Did you mean 'make test' instead?" ;\
> >> + exit 1 )
> >> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
> >
> > Please read Documentation/SubmittingPatches, your patch lacks a signoff
> > and a commit message.
>
> Heh, for something small and obvious like this, that's asking a tad too
> much, although a properly formatted message does reduce my workload and is
> appreciated.
Junio++
> I said "obvious" not in the sense that it is "obviously good". It is
> obvious what issue the patch wants to address.
>
> Having said that, it is far from clear if special casing "make check" like
> this is a good thing, though. The crufts resulting from "Four extra lines
> won't hurt" kind of reasoning can accumulate and snowball. Is reading the
> Makefile when your build fails in order to see if the target was what you
> really wanted to invoke (ideally, it should rater be "_before_ running
> make, reading the Makefile to find out what you want to run") a lost art
> these days?
Not at all, and for me it was clear from the start, so I typed 'make
test' and went ahead.
It was that I am just all to aware of the GNU world that I can easily
imagine other people making the same mistake, and just thought it
end-user-friendly to do as I proposed.
I'm by now way offended or scared away if you reject these kind of
patches
--
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: [EGIT PATCH 1/7] Test the origName part of the key vs the ref itself
From: Shawn O. Pearce @ 2008-11-11 18:05 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226095664-13759-2-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -127,4 +129,12 @@ public void testDeleteEmptyDirs() throws IOException {
> private void assertExists(final boolean expected, final String name) {
> assertEquals(expected, new File(db.getDirectory(), name).exists());
> }
> +
> + public void testRefKeySameAsOrigName() {
> + Map<String, Ref> allRefs = db.getAllRefs();
> + for (Entry<String, Ref> e : allRefs.entrySet()) {
> + assertEquals(e.getKey(), e.getValue().getOrigName());
> +
> + }
> + }
Hmm, doesn't this have to go after "Keep original ref name ..."
so getOrigName() is actually defined?
--
Shawn.
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Catalin Marinas @ 2008-11-11 17:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20081107054419.GA27146@diana.vm.bytemark.co.uk>
2008/11/7 Karl Hasselström <kha@treskal.com>:
> On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
>
>> I hit a case when refreshing a buried patch that needed a merge
>> conflict sorted out. I'm unable to recover out of the state.
>
> Hmm, so what you're saying is basically that you did something with
> "stg refresh -p" that caused a merge conflict, and that messed things
> up so that you needed to run "stg repair". Is that right?
>
> Have you been able to reproduce it? (I would like to add the failing
> case to the test suite.)
Could be related to this - if I run 'stg goto some-patch' and it fails
with a conflict, the HEAD points to the previous patch though the
stack has the conflicting patch as empty (which is normal) and the
conflicts in the index. Anything after that says HEAD and top not
equal and 'stg repair' is needed.
--
Catalin
^ permalink raw reply
* Re: Install issues
From: Junio C Hamano @ 2008-11-11 17:47 UTC (permalink / raw)
To: Miklos Vajna; +Cc: H.Merijn Brand, git
In-Reply-To: <20081110175123.GV24201@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
>> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>> ./test-sha1.sh
>>
>> check: common-cmds.h
>> + @`sparse </dev/null 2>/dev/null` || (\
>> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>> + echo "Did you mean 'make test' instead?" ;\
>> + exit 1 )
>> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>
> Please read Documentation/SubmittingPatches, your patch lacks a signoff
> and a commit message.
Heh, for something small and obvious like this, that's asking a tad too
much, although a properly formatted message does reduce my workload and is
appreciated.
I said "obvious" not in the sense that it is "obviously good". It is
obvious what issue the patch wants to address.
Having said that, it is far from clear if special casing "make check" like
this is a good thing, though. The crufts resulting from "Four extra lines
won't hurt" kind of reasoning can accumulate and snowball. Is reading the
Makefile when your build fails in order to see if the target was what you
really wanted to invoke (ideally, it should rater be "_before_ running
make, reading the Makefile to find out what you want to run") a lost art
these days?
^ 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