* 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
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 11:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030311s4e05de2dr90277f97a3a5c223@mail.gmail.com>
Hi,
Martin Langhoff wrote:
> [...]
> thanks a lot for the feedback! cvsserver has mainly been
> tried/debugged with a few repositories, mainly the moodle.git
> repository that we host, which is an import from a CVS repo.
I didnt even know it existed! :) I was looking for an Eclipse plugin
(anyone heard anything about such a beast after 20060313?), when
I accidently stumbled upon the git-cvsserver manpage, somewhere
on the web.
> [...]
> That warning is harmless, and always there. I did look once at
> implementing gzip compression, but in some cases it implies creating
> extra temp files to calculate the size, so I've opted to leave it for
> some other day.
>
> OTOH, we could declare that we handle it, and never actually send a
> gzipped file ;-) as long as we can handle gzipped content from the
> client.
Not really an issue imho :) I just automatically type -z3 whenever I do
a CVS update :)
BTW, thanks for writing git-cvsserver!
With friendly regards,
Takis
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 11:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030411o29af1d1bra3276353347516f6@mail.gmail.com>
Hi,
Martin Langhoff wrote:
> On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
>> Hmmm. 100% reproduceable -- looking at it now.
>
>
> Grumble. Some recent change has broken cvsserver -- if I rewind to the
> commit I made of cvsserver, the checkout works correctly. I suspect
> changes to git-diff-tree. However, I'll play dumb and try bisect to
> see where it leads...
>
> (Nice thing about bisecting with C code is that as you get closer the
> delta is smaller, and the recompile is smaller too ;-)
>
> Ok -- an hour's gone by and I'm still fidgeting with bisect. It seems
> to have been broken soon after v1.3.0 but I'm having trouble nailing
> the commit, and understanding WRF has changed.
>
> Can you test with git v1.3.0?
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 ;-) :
takis@issaris:/tmp/a/c$ export PATH=/tmp/testje/bin/:$PATH
takis@issaris:/tmp/a/c$ git --version
git version 1.3.0
takis@issaris:/tmp/a/c$ cvs co -d project-master master
takis@localhost's password:
Permission denied, please try again.
takis@localhost's password:
Permission denied, please try again.
takis@localhost's password:
cvs checkout: Updating project-master
U project-master/Makefile
U project-master/README
U project-master/cache.h
U project-master/cat-file.c
U project-master/commit-tree.c
U project-master/init-db.c
U project-master/read-cache.c
U project-master/read-tree.c
U project-master/show-diff.c
U project-master/update-cache.c
U project-master/write-tree.c
closing dbh with active statement handles
takis@issaris:/tmp/a/c$ which git
/tmp/testje/bin//git
With friendly regards,
Takis
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 11:11 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <46a038f90605030311s4e05de2dr90277f97a3a5c223@mail.gmail.com>
On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Hmmm. 100% reproduceable -- looking at it now.
Grumble. Some recent change has broken cvsserver -- if I rewind to the
commit I made of cvsserver, the checkout works correctly. I suspect
changes to git-diff-tree. However, I'll play dumb and try bisect to
see where it leads...
(Nice thing about bisecting with C code is that as you get closer the
delta is smaller, and the recompile is smaller too ;-)
Ok -- an hour's gone by and I'm still fidgeting with bisect. It seems
to have been broken soon after v1.3.0 but I'm having trouble nailing
the commit, and understanding WRF has changed.
Can you test with git v1.3.0?
martin
^ permalink raw reply
* [PATCH] add documentation for update-index --unresolve
From: Matthias Kestenholz @ 2006-05-03 10:53 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
I am not sure if this is already clear enough. Maybe this needs more
explanation in the manpage?
---
Documentation/git-update-index.txt | 6 +++++-
update-index.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
aa88546740e88b674335e26e342b53e623dcb5c6
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 74844d1..a5afaaf 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -15,7 +15,7 @@ SYNOPSIS
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
- [--really-refresh]
+ [--really-refresh] [--unresolve]
[--info-only] [--index-info]
[-z] [--stdin]
[--verbose]
@@ -80,6 +80,10 @@ OPTIONS
filesystem that has very slow lstat(2) system call
(e.g. cifs).
+--unresolve::
+ Restores the 'unmerged' or 'needs updating' state of a
+ file during a merge if it was cleared by accident.
+
--info-only::
Do not create objects in the object database for all
<file> arguments that follow this flag; just insert
diff --git a/update-index.c b/update-index.c
index facec8d..9fa3d2b 100644
--- a/update-index.c
+++ b/update-index.c
@@ -473,7 +473,7 @@ static void read_index_info(int line_ter
}
static const char update_index_usage[] =
-"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--verbose] [--] <file>...";
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--info-only] [--force-remove] [--stdin] [--index-info] [--unresolve] [--ignore-missing] [-z] [--verbose] [--] <file>...";
static unsigned char head_sha1[20];
static unsigned char merge_head_sha1[20];
--
1.3.1.g7464
^ permalink raw reply related
* [PATCH] fix various typos in documentation
From: Matthias Kestenholz @ 2006-05-03 10:51 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/git-diff-tree.txt | 2 +-
Documentation/git-update-index.txt | 2 +-
revision.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
3b68af9927782ef8b602cca0cdcc446c4dd468ca
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 2169169..906830d 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,7 +92,7 @@ separated with a single space are given.
Furthermore, it lists only files which were modified
from all parents.
--cc::
+--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
and '-p' options and further compresses the patch output
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d4137fc..74844d1 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-update-index'
[--add] [--remove | --force-remove] [--replace]
- [--refresh [-q] [--unmerged] [--ignore-missing]]
+ [--refresh] [-q] [--unmerged] [--ignore-missing]
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
diff --git a/revision.c b/revision.c
index ad78efd..c6e8702 100644
--- a/revision.c
+++ b/revision.c
@@ -574,7 +574,7 @@ int setup_revisions(int argc, const char
revs->max_count = atoi(arg + 12);
continue;
}
- /* accept -<digit>, like traditilnal "head" */
+ /* accept -<digit>, like traditional "head" */
if ((*arg == '-') && isdigit(arg[1])) {
revs->max_count = atoi(arg + 1);
continue;
--
1.3.1.g7464
^ permalink raw reply related
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 10:11 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <445865A5.5030700@lumumba.uhasselt.be>
On 5/3/06, Panagiotis Issaris <takis@lumumba.uhasselt.be> wrote:
> I've tried using git-cvsserver, but keep running into problems:
Panagiotis,
thanks a lot for the feedback! cvsserver has mainly been
tried/debugged with a few repositories, mainly the moodle.git
repository that we host, which is an import from a CVS repo.
> When doing a checkout, it only checks out a small subset of
> the total amount of files in the repository and reports a warning/error.
Hmmm. 100% reproduceable -- looking at it now.
> When doing a subsequent update, it doesn't seem to do anything,
> but reports two error messages/warnings.
...
> closing dbh with active statement handles
I thought we had gotten rid of those. In any case, I don't see that
error, and it's just a silly warning from DBI, as we are using cached
statements. As it happens when cvsserver is shutting down, it doesn't
actually break the protocol.
> server doesn't support gzip-file-contents
That warning is harmless, and always there. I did look once at
implementing gzip compression, but in some cases it implies creating
extra temp files to calculate the size, so I've opted to leave it for
some other day.
OTOH, we could declare that we handle it, and never actually send a
gzipped file ;-) as long as we can handle gzipped content from the
client.
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 9:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060503090007.GM27689@pasky.or.cz>
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:
> > >I'd love to see somebody volunteer to act as an editor to feed
> > >cooked topics for inclusion of the Documentation/ set. Anybody?
>
> I think this has time and someone might emerge naturally.
>
> > Junio, would be possible for you to write a Roadmap in a Wiki page,
> > similar to what Mercurial did here:
> > http://www.selenic.com/mercurial/wiki/index.cgi/RoadMap ?
>
> You can already find a similar (albeit a bit more low-level) document at
>
> http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
>
> but you can certainly add a link to it to the wiki. ;-)
I was looking for something more "high level but I'll try to add that
link to the wiki as soon as I back home from work.
> > 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.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ 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