* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3al00$1dj$1@sea.gmane.org>
On 5/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Linus Torvalds wrote:
> > On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> >>
> >> Perhaps is just a silly idea, but would be possible for OSDL to host a
> >> web site (www.git.org) where we can host pages/wiki an so on?
> >
> > I don't think hosting it would be a problem (it probably would be the same
> > kernel.org thing - OSDL is partly involved in maintaining it). The problem
> > is the content, and the artistic talent.
>
> As to content, we could I think use material found at Wikipedia Git page,
> and on External Links in Wikipedia Git_(software) article, not repeating of
> course what is in official Git Documentation/
I just added the TODO list link but I'm not a wiki expert, if you know
how to link to the article from Wikipedia please do it ;-)
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605030856540.4086@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>>
>> Perhaps is just a silly idea, but would be possible for OSDL to host a
>> web site (www.git.org) where we can host pages/wiki an so on?
>
> I don't think hosting it would be a problem (it probably would be the same
> kernel.org thing - OSDL is partly involved in maintaining it). The problem
> is the content, and the artistic talent.
As to content, we could I think use material found at Wikipedia Git page,
and on External Links in Wikipedia Git_(software) article, not repeating of
course what is in official Git Documentation/
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 16:06 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030839i2bb5de8dka8a4af27755051cf@mail.gmail.com>
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>
> Perhaps is just a silly idea, but would be possible for OSDL to host a
> web site (www.git.org) where we can host pages/wiki an so on?
I don't think hosting it would be a problem (it probably would be the same
kernel.org thing - OSDL is partly involved in maintaining it). The problem
is the content, and the artistic talent.
_I_ personally have what I'd call "negative artistic talent". I think I'm
occasionally good at designing beautiful data structures (and I think git
is that, including the pack-files), but that clearly doesn't translate to
any visual ability what-so-ever. None. Nada. Zilch.
Maybe the new Wiki can evolve into that. It sure looks better today than
it looked yesterday (now, when I first saw it, it was so ugly that I had
to dig my eyeballs out with a spoon, so that's not necessarily saying all
that much ;)
Linus
^ permalink raw reply
* Re: problem with plain git clone
From: Kumar Gala @ 2006-05-03 15:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060503143130.GA9172@spearce.org>
On May 3, 2006, at 9:31 AM, Shawn Pearce wrote:
> Kumar Gala <galak@kernel.crashing.org> wrote:
>> Anyone see an issues like the following:
>>
>> [kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
>> boot/galak/u-boot.git
>> git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
>> fatal: unable to connect a socket (Connection timed out)
>
> There's no GIT daemon running on the empty port. Notice the ':'
> appearing right after '.org'.
>
> Hmm, that sounds like a bug in the protocol URL parser...
Yeah, that was it. thanks.
- kumar
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 15:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Shawn Pearce, Nicolas Pitre, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030817580.4086@g5.osdl.org>
On 5/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 3 May 2006, Andreas Ericsson wrote:
> >
> > Considering Sun's CEO's common comments on Solaris' superiority over Linux I
> > think it's safe to assume that the same CEO wouldn't exactly jump of joy if
> > his employees started depending on a tool fathered by Linus.
>
> I doubt it went that high up, but with any kind of politics it's obviously
> possible that somebody consciously or unconsciously felt it might become a
> political problem, and it might have made a difference.
>
> However, I think the _real_ issue is that Mercurial has a much nicer
> introductory phase. The standard mercurial web-page is so much more
> professional and nice to look at than any git page I have ever seen, and
> let's face it: first looks _do_ count.
I can only agree.
I'm not a git developer, I'm even not a _real_ developer, I only hack
for fun during my very poor spare time but web pages, wiki and
introduction offered by Mercurial are really a lot nicer to what git
is offering at the moment.
Perhaps is just a silly idea, but would be possible for OSDL to host a
web site (www.git.org) where we can host pages/wiki an so on?
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* [PATCH] Add a simple makefile
From: Pavel Roskin @ 2006-05-03 15:34 UTC (permalink / raw)
To: Catalin Marinas, git
From: Pavel Roskin <proski@gnu.org>
---
Makefile | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..df77d97
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,23 @@
+PREFIX = $(HOME)
+DESTDIR = /
+PYTHON = python
+
+all:
+ $(PYTHON) setup.py build
+
+install:
+ $(PYTHON) setup.py install --prefix=$(PREFIX) --root=$(DESTDIR)
+
+doc:
+ cd doc && $(MAKE) all
+
+test:
+ cd t && $(MAKE) all
+
+clean:
+ for dir in doc t; do \
+ (cd $$dir && $(MAKE) clean); \
+ done
+ rm -rf build
+ rm -f stgit/*.pyc
+ rm -f stgit/commands/*.pyc
^ permalink raw reply related
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-03 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605030824v40017178o366a9d8aa83557e8@mail.gmail.com>
Paolo Ciarrocchi wrote:
> Would be fantastic to see a fair comparison of the two tools but I
> can't find anything useful on the web.
Three tools: Git/Cogito, Mercurial and Monotone.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Linus Torvalds @ 2006-05-03 15:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Shawn Pearce, Nicolas Pitre, Paolo Ciarrocchi, Petr Baudis,
Junio C Hamano, git
In-Reply-To: <4458C5D7.8010501@op5.se>
On Wed, 3 May 2006, Andreas Ericsson wrote:
>
> Considering Sun's CEO's common comments on Solaris' superiority over Linux I
> think it's safe to assume that the same CEO wouldn't exactly jump of joy if
> his employees started depending on a tool fathered by Linus.
I doubt it went that high up, but with any kind of politics it's obviously
possible that somebody consciously or unconsciously felt it might become a
political problem, and it might have made a difference.
However, I think the _real_ issue is that Mercurial has a much nicer
introductory phase. The standard mercurial web-page is so much more
professional and nice to look at than any git page I have ever seen, and
let's face it: first looks _do_ count.
Also, the fact that Solaris had the unfortunate bug with signals probably
didn't much help to endear git to them, since it made it look like git had
problems. Never mind that we solved it - I think it took us a while to
even realize that Solaris had a problem, because we weren't intimately
involved.
Which brings me to the final point, which is that I think the hg team was
very active and supporting, perhaps Matt himself. That's _important_ - the
OpenSolaris people probably felt very comfortable with strong support from
the developers. It can often be _the_ best (and biggest) reason to choose
any product - regardless of anything else.
Even if I think the git mailing list itself is very responsive, I think
the hg people were just more directly and actively involved. For git, they
had to come to us.
I also suspect that some people find python scripts somewhat less
intimidating than C. I'll also happily admit that my coding standards tend
to lean towards the "sparse" when it comes to comments, and I much prefer
the "small and well-named functions" approach, and git seems to have stuck
to that with Junio. Which just turns some people off.
So I don't think you need politics to explain it. I think hg is doing
quite well. It took some different design decisions, and while I
personally think the git ones are better, I'm somewhat biased ;)
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 15:24 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Shawn Pearce, Nicolas Pitre, Petr Baudis, Junio C Hamano, git
In-Reply-To: <4458C5D7.8010501@op5.se>
On 5/3/06, Andreas Ericsson <ae@op5.se> wrote:
> >>On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> >>
> >>>On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> >>>
> >>>>Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> >>>>where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> >>>>
> >>>>>On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> >>>>>
> >>>>>BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> >>>>>(they choose Mercurial).
> >>>>
> >>>>I think it's explained somewhere in their forums (or mailing lists or
> >>>>whatever they actually _are_).
> >>>
> >>>I only found the announcement, not the rationales.
> >>
> >>http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
> >>
> >>Looks like they didn't buy the argument about the uselessness of
> >>recording file renames.
> >
> >
> > The final evaluations are available from here (at the very bottom
> > of the page):
> >
> > http://opensolaris.org/os/community/tools/scm/
> >
> > It looks like Mercurial doesn't support renames either, but a lot
> > of users are asking for it to be supported. So I don't think that's
> > the reason. It looks more like they didn't enjoy porting GIT 1.2.2
> > (as 1.2.4 was found to not work in all cases) to Solaris and the
> > tester ran into some problems with the conflict resolution support.
> >
> > My own reading of the two final evaluations for GIT and Mercurial
> > leaves me feeling like GIT is a more mature tool which is faster
> > and more stable then Mercurial. GIT seemed to be more reliable
> > during testing then Mercurial was, despite the cloning issue.
> > Which makes me surprised that OpenSolaris selected Mercurial instead.
> >
>
Would be fantastic to see a fair comparison of the two tools but I
can't find anything useful on the web.
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Andreas Ericsson @ 2006-05-03 15:01 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nicolas Pitre, Paolo Ciarrocchi, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20060503142957.GA9056@spearce.org>
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>
>>On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
>>
>>>On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
>>>
>>>>Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
>>>>where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
>>>>
>>>>>On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
>>>>>
>>>>>BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
>>>>>(they choose Mercurial).
>>>>
>>>>I think it's explained somewhere in their forums (or mailing lists or
>>>>whatever they actually _are_).
>>>
>>>I only found the announcement, not the rationales.
>>
>>http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>>
>>Looks like they didn't buy the argument about the uselessness of
>>recording file renames.
>
>
> The final evaluations are available from here (at the very bottom
> of the page):
>
> http://opensolaris.org/os/community/tools/scm/
>
> It looks like Mercurial doesn't support renames either, but a lot
> of users are asking for it to be supported. So I don't think that's
> the reason. It looks more like they didn't enjoy porting GIT 1.2.2
> (as 1.2.4 was found to not work in all cases) to Solaris and the
> tester ran into some problems with the conflict resolution support.
>
> My own reading of the two final evaluations for GIT and Mercurial
> leaves me feeling like GIT is a more mature tool which is faster
> and more stable then Mercurial. GIT seemed to be more reliable
> during testing then Mercurial was, despite the cloning issue.
> Which makes me surprised that OpenSolaris selected Mercurial instead.
>
Considering Sun's CEO's common comments on Solaris' superiority over
Linux I think it's safe to assume that the same CEO wouldn't exactly
jump of joy if his employees started depending on a tool fathered by Linus.
No offence intended to Mercurial or its developers. Although I don't
know anything about how it works I'm fairly sure Sun's developers would
never agree to be forced to use an inferior tool (congrats Mercurial
devs). However, I *do* think that in a tie-break Mercurial would win for
political reasons.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-log --parents broken post v1.3.0
From: Linus Torvalds @ 2006-05-03 14:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Junio C Hamano
In-Reply-To: <46a038f90605030510x6d582804w6c0d2fec60bd56e5@mail.gmail.com>
On Thu, 4 May 2006, Martin Langhoff wrote:
> On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > Soon after v1.3.0 git-log --parents got broken. When using --parents,
>
> Ok -- perhaps that was a bit of a rushed statement. Reading back on
> the archives, it seems like it may have been intentional.
No it wasn't. "git log --parents" was definitely supposed to still work.
That said, I suspect a git-cvsserver kind of usage is better off using
"git-rev-list --parents HEAD" instead, which didn't break in the first
place.
> I have to confess, I don't quite follow the changes happening in that
> series of commits. If --parents is really not coming back I'll change
> the log entry parsing in cvsserver. However, I suspect git-log should
> error out on it ("fatal: deprecated option") so porcelains break
> explicitly, rather than silently.
No, the option really isn't deprecated, it was just missed because nothing
seemed to use it.. How about this diff?
Signed-off-by: Yadda yadda
Linus
---
diff --git a/log-tree.c b/log-tree.c
index 9634c46..f9c6f7c 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -3,6 +3,15 @@ #include "diff.h"
#include "commit.h"
#include "log-tree.h"
+static void show_parents(struct commit *commit, int abbrev)
+{
+ struct commit_list *p;
+ for (p = commit->parents; p ; p = p->next) {
+ struct commit *parent = p->item;
+ printf(" %s", diff_unique_abbrev(parent->object.sha1, abbrev));
+ }
+}
+
void show_log(struct rev_info *opt, struct log_info *log, const char *sep)
{
static char this_header[16384];
@@ -14,7 +23,10 @@ void show_log(struct rev_info *opt, stru
opt->loginfo = NULL;
if (!opt->verbose_header) {
- puts(sha1_to_hex(commit->object.sha1));
+ fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
+ if (opt->parents)
+ show_parents(commit, abbrev_commit);
+ putchar('\n');
return;
}
@@ -40,6 +52,8 @@ void show_log(struct rev_info *opt, stru
printf("%s%s",
opt->commit_format == CMIT_FMT_ONELINE ? "" : "commit ",
diff_unique_abbrev(commit->object.sha1, abbrev_commit));
+ if (opt->parents)
+ show_parents(commit, abbrev_commit);
if (parent)
printf(" (from %s)", diff_unique_abbrev(parent->object.sha1, abbrev_commit));
putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
^ permalink raw reply related
* Re: problem with plain git clone
From: Shawn Pearce @ 2006-05-03 14:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <7CAB7A96-2C63-4B05-B0C6-72FC5B74D960@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote:
> Anyone see an issues like the following:
>
> [kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
> boot/galak/u-boot.git
> git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
> fatal: unable to connect a socket (Connection timed out)
There's no GIT daemon running on the empty port. Notice the ':'
appearing right after '.org'.
Hmm, that sounds like a bug in the protocol URL parser...
--
Shawn.
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-03 9:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030501x1d97f60at4d10c8e2c7b4304c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
my version is 1.3.1. I'll d/l 1.3.0 and test with that.
Martin Langhoff wrote:
> Bill,
>
> haven't been able to repro your problem at this end. Can you check
> your git version? Apparently cvsserver was broken soon after 1.3.0.
> Can you try with v1.3.0?
>
> cheers,
>
>
> martin
>
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Shawn Pearce @ 2006-05-03 14:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Paolo Ciarrocchi, Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605030934220.28543@localhost.localdomain>
Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> > On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> > > Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> > > where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> > > > On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> > > >
> > > > BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> > > > (they choose Mercurial).
> > >
> > > I think it's explained somewhere in their forums (or mailing lists or
> > > whatever they actually _are_).
> >
> > I only found the announcement, not the rationales.
>
> http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
>
> Looks like they didn't buy the argument about the uselessness of
> recording file renames.
The final evaluations are available from here (at the very bottom
of the page):
http://opensolaris.org/os/community/tools/scm/
It looks like Mercurial doesn't support renames either, but a lot
of users are asking for it to be supported. So I don't think that's
the reason. It looks more like they didn't enjoy porting GIT 1.2.2
(as 1.2.4 was found to not work in all cases) to Solaris and the
tester ran into some problems with the conflict resolution support.
My own reading of the two final evaluations for GIT and Mercurial
leaves me feeling like GIT is a more mature tool which is faster
and more stable then Mercurial. GIT seemed to be more reliable
during testing then Mercurial was, despite the cloning issue.
Which makes me surprised that OpenSolaris selected Mercurial instead.
--
Shawn.
^ permalink raw reply
* problem with plain git clone
From: Kumar Gala @ 2006-05-03 14:18 UTC (permalink / raw)
To: git
Anyone see an issues like the following:
[kgala@kgala_lnx z]$ git clone git://git.kernel.org:/pub/scm/boot/u-
boot/galak/u-boot.git
git clone git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-boot.git
fatal: unable to connect a socket (Connection timed out)
fetch-pack from 'git://git.kernel.org:/pub/scm/boot/u-boot/galak/u-
boot.git' failed.
I've clearly done something crazy, but I setup this repository today
with a simple:
git clone -n rsync://rsync.denx.de/git/u-boot.git
mv u-boot/.git/ u-boot.git
- kumar
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Nicolas Pitre @ 2006-05-03 13:41 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030213r625ce87fw5cbee554f1c20fbd@mail.gmail.com>
On Wed, 3 May 2006, Paolo Ciarrocchi wrote:
> On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> > Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
> > where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> > > On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> > >
> > > BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> > > (they choose Mercurial).
> >
> > I think it's explained somewhere in their forums (or mailing lists or
> > whatever they actually _are_).
>
> I only found the announcement, not the rationales.
http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html
Looks like they didn't buy the argument about the uselessness of
recording file renames.
Nicolas
^ permalink raw reply
* [PATCH] Add a conversion tool to migrate remote information into the config
From: Johannes Schindelin @ 2006-05-03 13:27 UTC (permalink / raw)
To: git, junkio
Use this tool to rewrite the .git/remotes/* files into the config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
contrib/remotes2config.sh | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/contrib/remotes2config.sh b/contrib/remotes2config.sh
new file mode 100644
index 0000000..25901e2
--- /dev/null
+++ b/contrib/remotes2config.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+# Use this tool to rewrite your .git/remotes/ files into the config.
+
+. git-sh-setup
+
+if [ -d "$GIT_DIR"/remotes ]; then
+ echo "Rewriting $GIT_DIR/remotes" >&2
+ error=0
+ # rewrite into config
+ {
+ cd "$GIT_DIR"/remotes
+ ls | while read f; do
+ name=$(echo -n "$f" | tr -c "A-Za-z0-9" ".")
+ sed -n \
+ -e "s/^URL: \(.*\)$/remote.$name.url \1 ./p" \
+ -e "s/^Pull: \(.*\)$/remote.$name.fetch \1 ^$ /p" \
+ -e "s/^Push: \(.*\)$/remote.$name.push \1 ^$ /p" \
+ < "$f"
+ done
+ echo done
+ } | while read key value regex; do
+ case $key in
+ done)
+ if [ $error = 0 ]; then
+ mv "$GIT_DIR"/remotes "$GIT_DIR"/remotes.old
+ fi ;;
+ *)
+ echo "git-repo-config $key "$value" $regex"
+ git-repo-config $key "$value" $regex || error=1 ;;
+ esac
+ done
+fi
+
+
^ permalink raw reply related
* [PATCH] fetch, pull: ask config for remote information
From: Johannes Schindelin @ 2006-05-03 13:20 UTC (permalink / raw)
To: git, junkio
Now you can say
[remote.junio]
url = git://git.kernel.org/pub/scm/git/git.git
pull = next:next
in your .git/config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is 5a223a0d434c874984a0251eca4520ef95718a6d redone.
The conversion tool will follow in a few minutes, after
a bit of testing.
git-parse-remote.sh | 28 ++++++++++++++++++++++++----
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c9b899e..187f088 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -10,7 +10,10 @@ get_data_source () {
# Not so fast. This could be the partial URL shorthand...
token=$(expr "z$1" : 'z\([^/]*\)/')
remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
- if test -f "$GIT_DIR/branches/$token"
+ if test "$(git-repo-config --get "remote.$token.url")"
+ then
+ echo config-partial
+ elif test -f "$GIT_DIR/branches/$token"
then
echo branches-partial
else
@@ -18,7 +21,10 @@ get_data_source () {
fi
;;
*)
- if test -f "$GIT_DIR/remotes/$1"
+ if test "$(git-repo-config --get "remote.$1.url")"
+ then
+ echo config
+ elif test -f "$GIT_DIR/remotes/$1"
then
echo remotes
elif test -f "$GIT_DIR/branches/$1"
@@ -35,6 +41,15 @@ get_remote_url () {
case "$data_source" in
'')
echo "$1" ;;
+ config-partial)
+ token=$(expr "z$1" : 'z\([^/]*\)/')
+ remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
+ url=$(git-repo-config --get "remote.$token.url")
+ echo "$url/$remainder"
+ ;;
+ config)
+ git-repo-config --get "remote.$1.url"
+ ;;
remotes)
sed -ne '/^URL: */{
s///p
@@ -56,8 +71,10 @@ get_remote_url () {
get_remote_default_refs_for_push () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | branches | branches-partial)
+ '' | config-partial | branches | branches-partial)
;; # no default push mapping, just send matching refs.
+ config)
+ git-repo-config --get-all "remote.$1.push" ;;
remotes)
sed -ne '/^Push: */{
s///p
@@ -111,8 +128,11 @@ # Returns list of src: (no store), or sr
get_remote_default_refs_for_fetch () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | branches-partial)
+ '' | config-partial | branches-partial)
echo "HEAD:" ;;
+ config)
+ canon_refs_list_for_fetch \
+ $(git-repo-config --get-all "remote.$1.fetch") ;;
branches)
remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
case "$remote_branch" in '') remote_branch=master ;; esac
^ permalink raw reply related
* Re: [PATCH] repo-config: support --get-regexp and fix crash
From: Johannes Schindelin @ 2006-05-03 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlktjhhvc.fsf@assigned-by-dhcp.cox.net>
Hi,
thanks for your patch.
On Tue, 2 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -26,16 +29,18 @@ static int show_config(const char* key_,
> > if (value_ == NULL)
> > value_ = "";
> >
> > - if (!strcmp(key_, key) &&
> > + if ((use_key_regexp || !strcmp(key_, key)) &&
> > + (!use_key_regexp ||
> > + !regexec(key_regexp, key_, 0, NULL, 0)) &&
> > (regexp == NULL ||
> > (do_not_match ^
> > !regexec(regexp, value_, 0, NULL, 0)))) {
>
> That's a convoluted logic.
>
> (1) Either we are using key-regexp, or otherwise the key has to
> exactly match; and
>
> (2) Either we are not using key-regexp, or key-regexp must
> match; and
>
> (3) Either we are not using regexp, or value must match (or
> unmatch) as we are told by do_no_match.
>
> It all makes sense, but I wonder if this is the clearest way to
> convey what is happening to people. Not that I have a cleaner
> alternative in mind...
How about this (on top of your patch):
--- snip ---
[PATCH] repo-config: deconvolute logics
It was rightly noticed that the logic is quite convoluted. Fix that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
The real change is very short, but a code block got reindented,
too.
repo-config.c | 50 ++++++++++++++++++++++++++------------------------
1 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/repo-config.c b/repo-config.c
index 7e06d1a..63eda1b 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -27,36 +27,38 @@ static int show_config(const char* key_,
{
char value[256];
const char *vptr = value;
+ int dup_error = 0;
if (value_ == NULL)
value_ = "";
- if ((use_key_regexp || !strcmp(key_, key)) &&
- (!use_key_regexp ||
- !regexec(key_regexp, key_, 0, NULL, 0)) &&
- (regexp == NULL ||
+ if (!use_key_regexp && strcmp(key_, key))
+ return 0;
+ if (use_key_regexp && regexec(key_regexp, key_, 0, NULL, 0))
+ return 0;
+ if (regexp != NULL &&
(do_not_match ^
- !regexec(regexp, value_, 0, NULL, 0)))) {
- int dup_error = 0;
- if (show_keys)
- printf("%s ", key_);
- if (seen && !do_all)
- dup_error = 1;
- if (type == T_INT)
- sprintf(value, "%d", git_config_int(key_, value_));
- else if (type == T_BOOL)
- sprintf(value, "%s", git_config_bool(key_, value_)
- ? "true" : "false");
- else
- vptr = value_;
- seen++;
- if (dup_error) {
- error("More than one value for the key %s: %s",
- key_, vptr);
- }
- else
- printf("%s\n", vptr);
+ regexec(regexp, value_, 0, NULL, 0)))
+ return 0;
+
+ if (show_keys)
+ printf("%s ", key_);
+ if (seen && !do_all)
+ dup_error = 1;
+ if (type == T_INT)
+ sprintf(value, "%d", git_config_int(key_, value_));
+ else if (type == T_BOOL)
+ vptr = git_config_bool(key_, value_) ? "true" : "false";
+ else
+ vptr = value_;
+ seen++;
+ if (dup_error) {
+ error("More than one value for the key %s: %s",
+ key_, vptr);
}
+ else
+ printf("%s\n", vptr);
+
return 0;
}
^ permalink raw reply related
* Re: git-log --parents broken post v1.3.0
From: Martin Langhoff @ 2006-05-03 12:10 UTC (permalink / raw)
To: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <46a038f90605030456q679ceebcsa037b834bced9ca2@mail.gmail.com>
On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Soon after v1.3.0 git-log --parents got broken. When using --parents,
Ok -- perhaps that was a bit of a rushed statement. Reading back on
the archives, it seems like it may have been intentional. The new
header format is more succint, but while technically I can fish the
data at the porcelain layer, it is quite convenient to get it directly
from the commit header. Specially given that git-log has the info at
that time...
I have to confess, I don't quite follow the changes happening in that
series of commits. If --parents is really not coming back I'll change
the log entry parsing in cvsserver. However, I suspect git-log should
error out on it ("fatal: deprecated option") so porcelains break
explicitly, rather than silently.
cheers,
martin
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 12:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030442k5c4eee9dj25d4a467942b0f74@mail.gmail.com>
Hi,
Martin Langhoff wrote:
> On 5/3/06, Panagiotis Issaris <takis@lumumba.uhasselt.be> wrote:
>
>> Yes, I installed 1.3.0 using "make prefix=/tmp/testje install"
>> but, I'm getting the same problem (other then my failing typing
>> skills ;-) :
>
>
> The problem is that, while you are executing git-cvsserver from
> /tmp/testje, git-cvsserver invokes git-log from the path, and that is
> the "bad" git-log. Change your PATH in .bashrc so that the /tmp/testje
> install takes precedence...
Prefixing /tmp/testje/bin to my PATH in .bashrc wouldnt work, so I just
replaced
my locally built GIT-.deb package with a locally built v1.3.0 version of
the package.
All worked fine now! :-)
With friendly regards,
Takis
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Martin Langhoff @ 2006-05-03 12:01 UTC (permalink / raw)
To: Bill Burdick; +Cc: git
In-Reply-To: <4456360E.8060305@mobilereasoning.com>
Bill,
haven't been able to repro your problem at this end. Can you check
your git version? Apparently cvsserver was broken soon after 1.3.0.
Can you try with v1.3.0?
cheers,
martin
^ permalink raw reply
* git-log --parents broken post v1.3.0
From: Martin Langhoff @ 2006-05-03 11:56 UTC (permalink / raw)
To: git, Junio C Hamano, Linus Torvalds
Soon after v1.3.0 git-log --parents got broken. When using --parents,
the 'commit <sha1>' opening line would also list the SHA1 of the
parent commits. This seems to have broken git-cvsserver.
Just by testing git-cvsserver, git-bisect has said that
9153983310a169a340bd1023dccafd80b70b05bc is first bad commit
Author: Linus Torvalds <torvalds@osdl.org>
Date: Mon Apr 17 11:59:32 2006 -0700
Log message printout cleanups
But I am not too confident that it's this particular commit -- but it
is definitely one in this series. I had suspected of changes in
git-diff-tree, but the output of git-diff-tree remains unchanged as
far as I could test it.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] repo-config: support --get-regexp and fix crash
From: Johannes Schindelin @ 2006-05-03 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmze0j97u.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Junio made me aware of a crash, a fix for which was too easy to
> > merit a separate patch.
>
> Not really.
Right. I was just too lazy.
> > Strange thing I realized: A value is white-space-trimmed at the end
> > only if the line does not end with a comment. This fact is accounted
> > for in the new tests.
>
> Thanks - a note like this helps me quite a bit, because I
> usually apply e-mailed patches with --whitespace=strip, which
> would have destroyed the test, leaving me scratching my head
> without such a notice.
Apparently, I hid that note well: somebody complained privately that my
patch is not white-space clean.
As for the --get-regexp part: just take your time. It was easy enough, and
I think it is quite cool, but I have to see an application for it yet.
Ciao,
Dscho
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 11:42 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <445895AC.6070109@lumumba.uhasselt.be>
On 5/3/06, Panagiotis Issaris <takis@lumumba.uhasselt.be> wrote:
> Yes, I installed 1.3.0 using "make prefix=/tmp/testje install"
> but, I'm getting the same problem (other then my failing typing
> skills ;-) :
The problem is that, while you are executing git-cvsserver from
/tmp/testje, git-cvsserver invokes git-log from the path, and that is
the "bad" git-log. Change your PATH in .bashrc so that the /tmp/testje
install takes precedence...
cheers,
martin
^ 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