* Re: Google Summer of Code 2009
From: Shawn O. Pearce @ 2009-01-12 15:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <alpine.DEB.1.00.0901121421530.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Andreas Ericsson wrote:
>
> > Just chiming in that I can probably help mentoring whoever goes with
> > libgit2. I do not have enough spare time for me to promise that I can be
> > there as much as I think is necessary and proper, but I'll gladly help
> > out.
>
> I don't know if I like co-mentoring; I always had the impression that this
> does not work all that well.
I haven't tried it myself, so I can't comment. I thought though
that Daniel and Christian's mentoring went rather well, but maybe
that's just me.
This year I may not be able to be a mentor for GSoC. Even assuming
we are selected again we're likely to only have two students, given
the size of the program and the size of our organization's community.
I will most likely be hosting an intern at day-job, and I do want
to maintain some sort of contribution to Git, without hurting my
day job performance... so my time this summer is probably going to
be somewhat limited.
> > On a side-note, I think all mentors should urge the students in the
> > strongest possible terms to deliver their work to git@vger as soon as
> > possible. From previous years experience, successful projects are those
> > that the list sees code from within a week or two after the project's
> > started, while the projects that are kept in the dark rarely (if ever?)
> > finish successfully.
>
> Nope, that is just plainly incorrect.
>
> The most successful GSoC project we had was Miklos' builtin-merge, but the
> code had to grow to a state that both him and me were comfortable with a
> submission to git@vger.
Heh. I'd wager the most successful GSoC project was Marek's push
support for JGit. Having ObjectWriter available has opened up
the doors to support a lot of code in JGit, like the full protocol
suite, and bundles. Without it I wouldn't have gotten as far as
I did in Gerrit.
In terms of value, to me as a contributor, Marek's work gave me a
foundation we could build on and get stuff done. Miklos' merge is
great, but I don't think we gained nearly as many features as we
did with Marek's contribution.
Anyway, I don't want to get into a "my student was better!" contest.
I just think that we had a very successful year this year, with a
few really great projects being contributed to the community as a
result of our students' hard work.
> The _communication_ should be open, and much of it on the mailing list, I
> agree, but _only_ after the student is familiar enough with the aspects of
> her project (including some familiarity with the source code).
>
> I will _not_ force a student to ask questions openly that he finds
> embarassing.
I agree. The first few weeks are really critical to the student. They
are still trying to find their way around the code base and don't want
to look like an idiot. Nobody wants to look like an idiot, especially
in public, and especially when they have been "hired" to do a particular
job.
But... part of the reason GSoC exists is to get students involved
in open source. The rest of us don't come to Git with mentors we
can ask the "stupid" questions to. We come here and have to ask
what we need to ask, on the public mailing list, complete with
archives for the rest of time. As mentors we should be trying to
encourage our students to work in this, or any other, open source
community. GSoC is about getting these folks _involved_, so that
40 years from now, open source is just as viable as it is today.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Alex Riesen @ 2009-01-12 15:32 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4967DB4A.2000702@lsrfire.ath.cx>
2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> +static int isregexspecial(int c)
> +{
> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> + c == '.' || c == '^' || c == '{' || c == '|';
> +}
> +
> +static int is_fixed(const char *s)
> +{
> + while (!isregexspecial(*s))
> + s++;
> + return !*s;
> +}
strchr?
^ permalink raw reply
* Re: Lightweight tag ?
From: Michael J Gruber @ 2009-01-12 14:54 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <38b2ab8a0901120556x279f320oe693304dd2452050@mail.gmail.com>
Francis Moreau venit, vidit, dixit 01/12/09 14:56:
> On Mon, Jan 12, 2009 at 1:55 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Your test above confirms that the description is correct and nothing is
>> missing. "git push" pushes explicitly listed refspecs (or : as a
>> default). It pushes tags (light and heavy) when asked to.
>>
>
> So do you mean that the only way I have for pushing annoted tags only is
> to do:
>
> $ git push origin refs/tags/annoted
You could use the equivalent, more user friendly "git push origin tag
annoted".
> That's not what Junio said:
>
> Don't use explicit --tags blindly. It says "no matter what kind of tag,
> transfer everything under refs/tags". Otherwise you won't see a
> difference.
>
> So I interpret this like don't use --tags otherwise lightweight and annoted tags
> are the same.
I don't see a difference between lightweight tags and tag objects
regarding the question of automatic tag following, see my parenthetical
request for correction (below) in case I'm wrong.
>> "git pull" pulls tags if they can be reached from heads which are
>> pulled. It pulls all tags only when asked to.
>>
>
> [...]
>
>> So, "non-local" tags are the ones which can be reached from heads which
>> you pull, and local ones are the others.
>
> So I can't create a local tag on public heads (the ones I'm pushing
> out), can I ?
>
>> I don't think lightweight tags are more local than tag objects
>> (please correct me if I'm wrong; I think this needs more doc)
>
> Perhaps it needs documents which are more user friendly: I don't know where
> the 'lightweight' word is coming from (perhaps from the implementation) but
> I would expect that the _local_ term appears in the git-tag manual.
It's the other way round. "lightweight" is in the first few lines of the
man, "local" nowhere. In fact I don't see it anywhere in the docs.
>> It's just that the latter reside in the object db
>> store whereas the former are simple refs under refs/tags.
>
> That's implementation detail...
>
> I just need to create a local tag where I'm sure it won't be seen by others
> whatever the git operations I'm doing, normally a simple "git tag" switch
> should be enough...
Taking "whatever" literally this is impossible, of course.
Taking it /cum grano salis/ it's still impossible within the same repo:
If others have read access they can "ls-remote" and "fetch" happily what
they want. The sane and easy way is to use a private repo for your local
work and all your "local tags", then to push to a public (i.e.
publically readable) repo those branches and tags which you want to be seen.
Are you a Mercurial user by any chance? "hg tag -l" creates local tags
which are stored in an unversioned, private file, whereas "hg tag"
creates (and commits) a tag entry in a versioned file, which is the
source of some confusion and problems with hg tags ("hg co sometag" does
not contain sometag etc.). Maybe you want the behaviour of "hg tag -l"?
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH next] notes: fix core.notesRef documentation
From: Johannes Schindelin @ 2009-01-12 14:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1231769764-17294-1-git-send-email-trast@student.ethz.ch>
Hi,
On Mon, 12 Jan 2009, Thomas Rast wrote:
> The path format was inconsistent with the one used in git-notes.sh: it
> supposedly split the sha1 in the same 2/38 format that .git/objects
> uses, but the code uses the full sha1 without a path separator.
>
> While at it, also fix a grammatical error.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Thanks,
Dscho
^ permalink raw reply
* [PATCH next] notes: fix core.notesRef documentation
From: Thomas Rast @ 2009-01-12 14:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
The path format was inconsistent with the one used in git-notes.sh: it
supposedly split the sha1 in the same 2/38 format that .git/objects
uses, but the code uses the full sha1 without a path separator.
While at it, also fix a grammatical error.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/config.txt | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index acfeb77..348da77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -424,15 +424,13 @@ overlapping IO's.
core.notesRef::
When showing commit messages, also show notes which are stored in
- the given ref. This ref is expected to contain paths of the form
- ??/*, where the directory name consists of the first two
- characters of the commit name, and the base name consists of
- the remaining 38 characters.
+ the given ref. This ref is expected to contain files named
+ after the full SHA-1 of the commit they annotate.
+
-If such a path exists in the given ref, the referenced blob is read, and
+If such a file exists in the given ref, the referenced blob is read, and
appended to the commit message, separated by a "Notes:" line. If the
given ref itself does not exist, it is not an error, but means that no
-notes should be print.
+notes should be printed.
+
This setting defaults to "refs/notes/commits", and can be overridden by
the `GIT_NOTES_REF` environment variable.
--
tg: (1063ea4..) t/notes-doc-fix (depends on: next)
^ permalink raw reply related
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 13:56 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <496B3DA8.1040308@drmicha.warpmail.net>
On Mon, Jan 12, 2009 at 1:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Your test above confirms that the description is correct and nothing is
> missing. "git push" pushes explicitly listed refspecs (or : as a
> default). It pushes tags (light and heavy) when asked to.
>
So do you mean that the only way I have for pushing annoted tags only is
to do:
$ git push origin refs/tags/annoted
That's not what Junio said:
Don't use explicit --tags blindly. It says "no matter what kind of tag,
transfer everything under refs/tags". Otherwise you won't see a
difference.
So I interpret this like don't use --tags otherwise lightweight and annoted tags
are the same.
> "git pull" pulls tags if they can be reached from heads which are
> pulled. It pulls all tags only when asked to.
>
[...]
> So, "non-local" tags are the ones which can be reached from heads which
> you pull, and local ones are the others.
So I can't create a local tag on public heads (the ones I'm pushing
out), can I ?
> I don't think lightweight tags are more local than tag objects
> (please correct me if I'm wrong; I think this needs more doc)
Perhaps it needs documents which are more user friendly: I don't know where
the 'lightweight' word is coming from (perhaps from the implementation) but
I would expect that the _local_ term appears in the git-tag manual.
> It's just that the latter reside in the object db
> store whereas the former are simple refs under refs/tags.
That's implementation detail...
I just need to create a local tag where I'm sure it won't be seen by others
whatever the git operations I'm doing, normally a simple "git tag" switch
should be enough...
thanks.
--
Francis
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Morgan Christiansson @ 2009-01-12 13:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090112051409.GB14992@dcvr.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
Eric Wong wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>
>> Morgan Christiansson <git@mog.se> wrote:
>>
>>> The "Ignoring path" message appears to be coming from git which is
>>> refusing to commit the .git directory. Which leads to git-svn being
>>> unaware of the files being ignored and giving an error when it can't
>>> find them.
>>>
>>> I'm personally fine with these files being ignored by git, but git-svn
>>> needs to be aware that they are not added to the repository.
>>>
>> Hi Morgan,
>> Can you try the following rough patch and see it it fixes things
>> for you? Thanks!
>>
>
> Actually, I think this patch is broken (my quickly put together test
> case was insufficient)...
>
Yes it was. apply_textdelta() is never called for my repo so it has no
effect.
I've attached an updated and simplified version of the testcase you sent
that correctly triggers the bug i reported.
I'm not a native perl coder though so I don't think I would be able to
provide a clean fix for this. But I've traced through enough of the
program to see that the .git directories should be filtered out as early
as possible to mimick the behaviour of git.
get_log() has a callback as it's last argument which gets called once
per commit, nesting this callback in a new callback which filters the
illegal paths out would work.
Also in gs_do_fetch_loop_common() after get_log() and before
do_git_commit() it's possible to filter them.
Regards,
Morgan
[-- Attachment #2: t9133-git-svn-nested-git-repo.sh --]
[-- Type: application/x-sh, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Johannes Schindelin @ 2009-01-12 13:33 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: René Scharfe, Git Mailing List, Junio C Hamano
In-Reply-To: <237967ef0901120425x79b7c1a4p238081a99694ae23@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 844 bytes --]
Hi,
On Mon, 12 Jan 2009, Mikael Magnusson wrote:
> 2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> > Add the new flag "fixed" to struct grep_pat and set it if the pattern
> > is doesn't contain any regex control characters in addition to if the
> > flag -F/--fixed-strings was specified.
> >
> > diff --git a/grep.c b/grep.c
> > index 394703b..a1092df 100644
> > --- a/grep.c
> > +++ b/grep.c
> > @@ -28,9 +28,31 @@ void append_grep_pattern(struct grep_opt *opt, const char *pat,
> > p->next = NULL;
> > }
> >
> > +static int isregexspecial(int c)
> > +{
> > + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> > + c == '.' || c == '^' || c == '{' || c == '|';
> > +}
>
> Shouldn't this include '*' and '\'?
This is covered by isspecial(): see ctype.c.
Hth,
Dscho
^ permalink raw reply
* Re: git submodule merge madness
From: Andreas Ericsson @ 2009-01-12 13:27 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <ADC7A3B1-6756-4258-93CD-DB40C7D2793C@develooper.com>
Ask Bjørn Hansen wrote:
> Hi,
>
> We've (again) replaced a few directories with submodules. Man, it's
> madness!
>
> The typical problem is that we get an error trying to merge a
> "pre-submodule" branch into master:
>
> fatal: cannot read object 894c77319a18c4d48119c2985a9275c9f5883584
> 'some/sub/dir': It is a submodule!
> Mark Levedahl wrote an example in July, but I don't think he got any
> replies: http://marc.info/?l=git&m=121587851313303
> Any ideas? Is there something we can do? I see a strong correlation
> between adding a new submodule and the number of "git sucks" messages on
> our internal IRC server.
>
Well, reworking the repository structure (which is essentially what you're
doing) should be a flag day. Merge stuff before that and mark it in some
way so that you don't run into the problems you're seeing now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Johannes Schindelin @ 2009-01-12 13:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git
In-Reply-To: <496B2690.2010902@op5.se>
Hi,
On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> Just chiming in that I can probably help mentoring whoever goes with
> libgit2. I do not have enough spare time for me to promise that I can be
> there as much as I think is necessary and proper, but I'll gladly help
> out.
I don't know if I like co-mentoring; I always had the impression that this
does not work all that well.
> On a side-note, I think all mentors should urge the students in the
> strongest possible terms to deliver their work to git@vger as soon as
> possible. From previous years experience, successful projects are those
> that the list sees code from within a week or two after the project's
> started, while the projects that are kept in the dark rarely (if ever?)
> finish successfully.
Nope, that is just plainly incorrect.
The most successful GSoC project we had was Miklos' builtin-merge, but the
code had to grow to a state that both him and me were comfortable with a
submission to git@vger.
The _communication_ should be open, and much of it on the mailing list, I
agree, but _only_ after the student is familiar enough with the aspects of
her project (including some familiarity with the source code).
I will _not_ force a student to ask questions openly that he finds
embarassing.
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Christian Couder @ 2009-01-12 13:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git
In-Reply-To: <496B2690.2010902@op5.se>
Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> Just chiming in that I can probably help mentoring whoever goes
> with libgit2. I do not have enough spare time for me to promise
> that I can be there as much as I think is necessary and proper,
> but I'll gladly help out.
>
> On a side-note, I think all mentors should urge the students in
> the strongest possible terms to deliver their work to git@vger
> as soon as possible.
I agree, but I think there is also a merge problem. I mean we should also
perhaps urge students to get what they have done merged as soon as possible
even if it means that they rework 5 or 10 time the code instead of
developing features according to the schedule.
But unfortunately even something merged into next can be removed afterwards,
so it's really difficult, because big features cannot for obvious reasons
be merged into master and the git release cycle doesn't always go along
well with the GSoC schedule.
> From previous years experience, successful
> projects are those that the list sees code from within a week
> or two after the project's started, while the projects that are
> kept in the dark rarely (if ever?) finish successfully.
I don't think things are so simple.
Regards,
Christian.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Christian Couder @ 2009-01-12 13:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Shawn O. Pearce, git, Stephan Beyer,
Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0901102058220.3586@pacific.mpi-cbg.de>
Hi,
Le samedi 10 janvier 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > The application answers really need to be reworked; we need to
> > > address our 2008 results in these parts.
> >
> > By the way, do you know what happened with git-sequencer project?
>
> -- snip --
> commit 3bfd6761ce2f769746c6b84be97f7da0cad7cad1
> Author: Stephan Beyer <s-beyer@gmx.net>
> Date: Wed Jan 7 19:07:31 2009 +0100
>
> builtin-sequencer.c/prepare_commit_msg_hook: tiny simplification
>
> Thanks to Christian.
> -- snap --
Yes, Stephan, Daniel and me are still working on it but very slowly.
You can see what happens on the repo here:
http://repo.or.cz/w/git/sbeyer.git?a=shortlog;h=refs/heads/seq-builtin-dev
May be we should move our discussions, patches and everything on the git
mailing list as it may motivate us and people on the list to help.
One good thing too would be if Stephan could share is todo list.
By the way don't hesitate to put us in CC :-)
Regards,
Christian.
^ permalink raw reply
* Re: Lightweight tag ?
From: Michael J Gruber @ 2009-01-12 12:55 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <m2bpucnas2.fsf@gmail.com>
Francis Moreau venit, vidit, dixit 01/12/09 10:17:
> Hello,
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Don't use explicit --tags blindly. It says "no matter what kind of tag,
>> transfer everything under refs/tags". Otherwise you won't see a
>> difference.
>
> Well:
>
> $ git --version
> git version 1.6.0.4
> $ mkdir test-tag
> $ cd test-tag/
> $ date > A
> $ git init
> Initialized empty Git repository in
> /home/fmoreau/tmp/git/test-tag/.git/
> $ git add .
> $ git commit -a -s -m "Init"
> Created initial commit be8750e: Init
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 A
> $ cd ..
> $ git clone --bare test-tag test-tag.git
> Initialized empty Git repository in /home/fmoreau/tmp/git/test-tag.git/
> $ cd test-tag
> $ git tag light
>
> $ git tag -a -m "Annoted tag" annoted
> $ git push ../test-tag.git
> Everything up-to-date
> $ git push --tags ../test-tag.git
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 166 bytes, done.
> Total 1 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (1/1), done.
> To ../test-tag.git
> * [new tag] annoted -> annoted
> * [new tag] light -> light
>
> It looks like they're no difference for git-push...
>
> That said the documentation about this is rather cryptic IMHO:
>
> ,----[ man git-push ]
> | --tags
> | All refs under $GIT_DIR/refs/tags are pushed, in
> | addition to refspecs explicitly listed on the command
> | line.
> `----
>
> From a user point of view, the word lightweight is missing here. Why
> not simply saying:
>
> ,----
> | All kind of tags are pushed with this option _otherwise_ only annoted
> | tags are pushed
> `----
Your test above confirms that the description is correct and nothing is
missing. "git push" pushes explicitly listed refspecs (or : as a
default). It pushes tags (light and heavy) when asked to.
"git pull" pulls tags if they can be reached from heads which are
pulled. It pulls all tags only when asked to.
In fact, the automatic following of tags (if they can be reached...)
depends on the transport, because typically you want to clone everything
if you clone locally but don't want all tags if you clone/pull from a
remote. There is also a config "tagopt" for overriding this. It's
mentioned but not really explained in "git tag"'s man page.
So, "non-local" tags are the ones which can be reached from heads which
you pull, and local ones are the others. I don't think lightweight tags
are more local than tag objects (please correct me if I'm wrong; I think
this needs more doc). It's just that the latter reside in the object db
store whereas the former are simple refs under refs/tags.
Michael
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Mikael Magnusson @ 2009-01-12 12:25 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4967DB4A.2000702@lsrfire.ath.cx>
2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
> Add the new flag "fixed" to struct grep_pat and set it if the pattern
> is doesn't contain any regex control characters in addition to if the
> flag -F/--fixed-strings was specified.
>
> diff --git a/grep.c b/grep.c
> index 394703b..a1092df 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -28,9 +28,31 @@ void append_grep_pattern(struct grep_opt *opt, const char *pat,
> p->next = NULL;
> }
>
> +static int isregexspecial(int c)
> +{
> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
> + c == '.' || c == '^' || c == '{' || c == '|';
> +}
Shouldn't this include '*' and '\'?
--
Mikael Magnusson
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Mike Hommey @ 2009-01-12 12:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> Alex Riesen wrote:
> > 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
>
> > > Do you have any suggestions to bypass this block for git? I have access
> > > to Linux shell account (no root access, though) which doesn't have
> > > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > > how? And what to do with access via git:// - move to SSH too?
> >
> > See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> > git:// port to anywhere. Same for push over ssh, just give another port when
> > connecting.
>
> Currently I have the folowing in my ~/.ssh/config:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> NoHostAuthenticationForLocalhost yes
> HostName localhost
> Port 2222
>
> and I can simply use "git push repo" without any changes.
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
Something like the following should do the trick:
Host repo.or.cz
ProxyCommand ssh jnareb@host.example.com nc %h %p
You will need nc (netcat) installed on the host.example.com server, though.
Mike
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 12:19 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090112120345.GA12087@coredump.intra.peff.net>
Jeff King schrieb:
> On Mon, Jan 12, 2009 at 01:00:05PM +0100, Johannes Sixt wrote:
>
>> Good question. The exit code is 0xc000013a if the signal was generated by
>> hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
>> signal was "generated" by 'raise(SIGINT)'. The implementation of the
>> latter just calls _exit(3) (same for other deadly signals). Wow!
>
> Eh? So it doesn't even run the signal handlers? Or if it is SIG_DFL
> (i.e., we have already run all the handlers), then it just calls _exit?
It's silly, but not *that* silly: It calls _exit(3) only if the handler is
SIG_DFL.
-- Hannes
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Johannes Schindelin @ 2009-01-12 12:19 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901111936h6343e51fo94750d83e95743dc@mail.gmail.com>
Hi,
On Mon, 12 Jan 2009, Ping Yin wrote:
> $ git --version
> git version 1.6.1.9.g97c34
> $ mkdir test && cd test && git init && git commit --allow-empty -m
> "Initial commit"
> $ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
> $ git diff --stat HEAD^..
> 0 files changed, 0 insertions(+), 0 deletions(-)
>
> May be the following is better?
>
> .gitignore | 0 +
> 1 files changed, 0 insertions(+), 0 deletions(-)
Have fun coding that.
Ciao,
Dscho
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Jeff King @ 2009-01-12 12:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <496B30C5.2060207@viscovery.net>
On Mon, Jan 12, 2009 at 01:00:05PM +0100, Johannes Sixt wrote:
> Good question. The exit code is 0xc000013a if the signal was generated by
> hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
> signal was "generated" by 'raise(SIGINT)'. The implementation of the
> latter just calls _exit(3) (same for other deadly signals). Wow!
Eh? So it doesn't even run the signal handlers? Or if it is SIG_DFL
(i.e., we have already run all the handlers), then it just calls _exit?
> > Don't these get fed to signal()? Does Windows really not care about
> > getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> > are we just ignoring the return code everywhere?
>
> Windows's signal() does return EINVAL; appearently, we never check the
> return code. :-P
OK. That makes sense; we don't bother checking the return code because
it's mostly just registering a cleanup function. The only sane thing to
do on an error (besides ignore it) is to abort whatever we're doing, and
I'm not sure it's worth it.
I do feel a little like this is a trap waiting to spring for future
coders to break Windows, but I think your change doesn't make anything
_worse_ in that regard.
-Peff
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Sixt @ 2009-01-12 12:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20090112112109.GA3825@coredump.intra.peff.net>
Jeff King schrieb:
> Hrm. How do you properly detect "killed by SIGINT" on Windows?
Good question. The exit code is 0xc000013a if the signal was generated by
hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
signal was "generated" by 'raise(SIGINT)'. The implementation of the
latter just calls _exit(3) (same for other deadly signals). Wow!
>> -#define SIGKILL 0
>> -#define SIGCHLD 0
>> -#define SIGPIPE 0
>> -#define SIGHUP 0
>> -#define SIGQUIT 0
>> -#define SIGALRM 100
>> +#define SIGHUP 1
>> +#define SIGQUIT 3
>> +#define SIGKILL 9
>> +#define SIGPIPE 13
>> +#define SIGALRM 14
>> +#define SIGCHLD 17
>
> Don't these get fed to signal()? Does Windows really not care about
> getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> are we just ignoring the return code everywhere?
Windows's signal() does return EINVAL; appearently, we never check the
return code. :-P
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Alex Riesen @ 2009-01-12 11:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110336380.19665@iabervon.org>
2009/1/11 Daniel Barkalow <barkalow@iabervon.org>:
> diff --git a/Makefile b/Makefile
>
> +LIB_OBJS += p4client.o
> +LIB_OBJS += vcs-p4.o
> +
>
> +extern int cmd_p4(int argc, const char **argv, const char *prefix);
> +
Why is your foreign VCS importer built-in? The majority wont ever need it,
yet they have to pay the price for its text being in git executable.
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Luciano Rocha @ 2009-01-12 11:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]
On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski wrote:
> Alex Riesen wrote:
> > 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
>
> > > Do you have any suggestions to bypass this block for git? I have access
> > > to Linux shell account (no root access, though) which doesn't have
> > > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > > how? And what to do with access via git:// - move to SSH too?
> >
> > See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> > git:// port to anywhere. Same for push over ssh, just give another port when
> > connecting.
>
> Currently I have the folowing in my ~/.ssh/config:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> NoHostAuthenticationForLocalhost yes
> HostName localhost
> Port 2222
>
> and I can simply use "git push repo" without any changes.
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
For those cases I use the attached script. Read the first lines, with
information on how to install.
The end result is that I can do:
ssh host1--host2--host3
Or scp, rsync, etc.
Regards,
Luciano Rocha
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #1.2: ssh_p --]
[-- Type: text/plain, Size: 2166 bytes --]
#!/bin/bash
## SSH connection chaining
##
## (C) 2007, Luciano Rocha <strange@nsk.pt>
##
## This program is free software; you can redistribute it and/or
## modify it under the terms of the GNU General Public License
## as published by the Free Software Foundation; either version 2
## of the License, or (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
## MA 02110-1301, USA.
##
## Or check the webpage: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
##
## Documentation:
##
## Include in your .ssh/config:
## host *--*
## proxycommand ssh_p %h %p
##
## And then you can do:
## ssh hosta--hostb--hostc
## scp hosta--hostb--hostc:file .
##
## A user specification is also possible, but not for the last host, for
## that one, you'll have to use ssh's standard user specification (user@host
## or -luser):
## ssh usera_hosta--userb_hostb--hostc -luserc
## scp userc@usera_hosta--userb_hostb--hostc:file .
##
## Compression is disable on all proxy sshs, as traffic is already encrypted.
## Activate compression in the master ssh command, if desired.
##
## Environment variable SSH_CONFIG_FILE can point to a ssh configuration
## file for use in the proxy sshs.
## missing hops
h="${1%--*}"
## nc target
rh="${1##*--}"
p="${2:-22}"
## user for next hop
u=
n="${h##*--}"
if [ -z "${n##*_*}" ]; then
u=${n%%_*}
if [ "$h" != "$n" ]; then
h="${h%--*}--${n##*_}"
else
h="${n##*_}"
fi
fi
echo "${SSH_INDENT}+ connecting to $h for $rh" >&2
exec env SSH_INDENT="${SSH_INDENT} " ssh -o "Compression no" \
${SSH_CONFIG_FILE:+-F$SSH_CONFIG_FILE} \
${u:+$u@}$h \
"echo \"${SSH_INDENT}- connected to $h, forwarding to $rh:$p\" >&2 ; nc -w 3600 $rh $p"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-12 11:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901121213.45858.jnareb@gmail.com>
On Mon, 12 Jan 2009, Jakub Narebski wrote:
> But I have to run
>
> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> first. Is there any way to automate this?
Check out 'gstm' or 'autossh'.
-- Asheesh.
--
You will get what you deserve.
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Andreas Ericsson @ 2009-01-12 11:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090107183033.GB10790@spearce.org>
Just chiming in that I can probably help mentoring whoever goes
with libgit2. I do not have enough spare time for me to promise
that I can be there as much as I think is necessary and proper,
but I'll gladly help out.
On a side-note, I think all mentors should urge the students in
the strongest possible terms to deliver their work to git@vger
as soon as possible. From previous years experience, successful
projects are those that the list sees code from within a week
or two after the project's started, while the projects that are
kept in the dark rarely (if ever?) finish successfully.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Jeff King @ 2009-01-12 11:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <496B2278.9050905@viscovery.net>
On Mon, Jan 12, 2009 at 11:59:04AM +0100, Johannes Sixt wrote:
> But we need to insert the patch below *before* 2/4. The test case needs a
> change, too,(exit code on Windows is 3, not 130) but I'll keep that in my
> repository, like with all other Windows related test suite changes.
Hrm. How do you properly detect "killed by SIGINT" on Windows? That is
the intent of that test.
> -#define SIGKILL 0
> -#define SIGCHLD 0
> -#define SIGPIPE 0
> -#define SIGHUP 0
> -#define SIGQUIT 0
> -#define SIGALRM 100
> +#define SIGHUP 1
> +#define SIGQUIT 3
> +#define SIGKILL 9
> +#define SIGPIPE 13
> +#define SIGALRM 14
> +#define SIGCHLD 17
Don't these get fed to signal()? Does Windows really not care about
getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
are we just ignoring the return code everywhere?
-Peff
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 11:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0901120117mf010317m79874a235e29a439@mail.gmail.com>
Alex Riesen wrote:
> 2009/1/12 Jakub Narebski <jnareb@gmail.com>:
> > Do you have any suggestions to bypass this block for git? I have access
> > to Linux shell account (no root access, though) which doesn't have
> > problems with repo.or.cz, so I think I could set up SSH tunnel: but
> > how? And what to do with access via git:// - move to SSH too?
>
> See man ssh, look for -L. It works for arbitrary ports, so you can redirect
> git:// port to anywhere. Same for push over ssh, just give another port when
> connecting.
Currently I have the folowing in my ~/.ssh/config:
# TP S.A. blocks repo.or.cz
Host repo.or.cz
NoHostAuthenticationForLocalhost yes
HostName localhost
Port 2222
and I can simply use "git push repo" without any changes.
But I have to run
$ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
first. Is there any way to automate this?
--
Jakub Narebski
Poland
^ 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