* [PATCH 0/3] rebase --merge improvements and fixes
From: Eric Wong @ 2006-06-25 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060622110941.GA32261@hand.yhbt.net>
These patches should address the current issues with rebase --merge
usage. It can now do everything the original format-patch | am -3
strategy including --skip and detection of merged commits by upstream.
--
Eric Wong
^ permalink raw reply
* [PATCH 1/3] rebase: allow --merge option to handle patches merged upstream
From: Eric Wong @ 2006-06-25 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060622110941.GA32261@hand.yhbt.net>
Enhance t3401-rebase-partial to test with --merge as well as
the standard am -3 strategy.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-rebase.sh | 15 +++++++++++----
t/t3401-rebase-partial.sh | 13 ++++++++++++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 9159477..53fb14e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -82,7 +82,10 @@ call_merge () {
rv=$?
case "$rv" in
0)
- git-commit -C "$cmt" || die "commit failed: $MRESOLVEMSG"
+ if test -n "`git-diff-index HEAD`"
+ then
+ git-commit -C "$cmt" || die "commit failed: $MRESOLVEMSG"
+ fi
;;
1)
test -d "$GIT_DIR/rr-cache" && git-rerere
@@ -110,9 +113,13 @@ finish_rb_merge () {
do
git-read-tree `cat "$dotest/cmt.$msgnum.result"`
git-checkout-index -q -f -u -a
- git-commit -C "`cat $dotest/cmt.$msgnum`"
-
- printf "Committed %0${prec}d" $msgnum
+ if test -n "`git-diff-index HEAD`"
+ then
+ git-commit -C "`cat $dotest/cmt.$msgnum`"
+ printf "Committed %0${prec}d" $msgnum
+ else
+ printf "Already applied: %0${prec}d" $msgnum
+ fi
echo ' '`git-rev-list --pretty=oneline -1 HEAD | \
sed 's/^[a-f0-9]\+ //'`
msgnum=$(($msgnum + 1))
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 32dc9c5..360a670 100755
--- a/t/t3401-rebase-partial.sh
+++ b/t/t3401-rebase-partial.sh
@@ -37,7 +37,9 @@ test_expect_success \
test_expect_success \
'pick top patch from topic branch into master' \
'git-cherry-pick my-topic-branch^0 &&
- git-checkout -f my-topic-branch
+ git-checkout -f my-topic-branch &&
+ git-branch master-merge master &&
+ git-branch my-topic-branch-merge my-topic-branch
'
test_debug \
@@ -50,4 +52,13 @@ test_expect_success \
'rebase topic branch against new master and check git-am did not get halted' \
'git-rebase master && test ! -d .dotest'
+if test -z "$no_python"
+then
+ test_expect_success \
+ 'rebase --merge topic branch that was partially merged upstream' \
+ 'git-checkout -f my-topic-branch-merge &&
+ git-rebase --merge master-merge &&
+ test ! -d .git/.dotest-merge'
+fi
+
test_done
--
1.4.0.g937a
^ permalink raw reply related
* Re: PPC SHA-1 Updates in "pu"
From: Petr Baudis @ 2006-06-25 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vhd2atid1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jun 24, 2006 at 10:21:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Pasky, can we first iron out kinks in the build procedure and
> installation before converting existing programs further?
Sure.
> The things I worry about currently are:
>
> - the SITELIBARCH gotcha I sent you a message about (and you
> responded to it already -- was that an Acked-by?);
Yes. :-)
> - RPM target -- we probably acquired a new build-dependency in
> which case the .spec file needs to be updated;
Well, perl is currently not listed even as a runtime dependency,
so does it really need to be listed as a build dependency?
> - Make sure Git.xs builds and installed result works fine on
> all platforms we care about, including Cygwin and other
> non-Linux boxes.
Unfortunately I don't have access to a lot of those. :-(
> I'd even suggest we revert the changes to git-fmt-merge-msg to
> keep it working for now, until the above worries are resolved.
> Otherwise we cannot have it in "next" safely (and I REALLY _do_
> want to have Git.pm infrastructure in "next" soonish).
Yes, that sounds reasonable.
> We can start using Git.xs and friends in some _new_ ancillary
> programs, once we solve building and installing problems for
> everybody. That way it would help us gain portability and
> confidence without disrupting existing users.
Well, I don't think it's very likely that Git.pm per se would be buggy
on a certain specific platform - it should either work as well as
everywhere else or not build at all, in which case you have disrupted
the existing users anyway. :-) (But without disrupting anyone we won't
get any bugreports and never get it fixed.)
Perhaps other converted perl scripts can linger at least on the pu
branch?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Junio C Hamano @ 2006-06-25 1:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606242207510.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> My original idea: on a machine where you have no accurate diff, you at
> least want to pass the tests, and you want to ensure you can apply a diff
> you generated on that machine.
I remember that, but I think recently we converted t4100 and
t4101 to use pregenerated test vectors so it might not be an
issue anymore?
> This patch is just compile tested, but obviously correct
Looks sane, thanks.
I would maybe rename the option to --inaccurate-eof and default
it to off (i.e. no --accurate-eof option). After all we are not
talking about arbitrary inaccuracy but the particular botch of
not having "\No newline at the end of file."
^ permalink raw reply
* Re: [PATCH 07/12] Git.pm: Better error handling
From: Petr Baudis @ 2006-06-25 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060624131731.GU21864@pasky.or.cz>
Dear diary, on Sat, Jun 24, 2006 at 03:17:31PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Sat, Jun 24, 2006 at 10:37:25AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > +int
> > > +error_xs(const char *err, va_list params)
> > > +{
> >
> > You said in git-compat-util.h that set_error_routine takes a
> > function that returns void, so this gives unnecessary type
> > clash.
> >
> > --------------------------------
> > In file included from /usr/lib/perl/5.8/CORE/perl.h:756,
> > from Git.xs:15:
> > /usr/lib/perl/5.8/CORE/embed.h:4193:1: warning: "die" redefined
> > Git.xs:11:1: warning: this is the location of the previous definition
> > Git.xs: In function 'boot_Git':
> > Git.xs:57: warning: passing argument 1 of 'set_error_routine' from incompatible pointer type
> > Git.xs:58: warning: passing argument 1 of 'set_die_routine' makes qualified function pointer from unqualified
> > --------------------------------
>
> Oh, I forgot to fix it in the .xs. :-(
---
[PATCH] Git.pm: Squash some annoying warnings in Git.xs
From: Petr Baudis <pasky@suse.cz>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.xs | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/perl/Git.xs b/perl/Git.xs
index e841e4a..d7a2b75 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -29,21 +29,18 @@ report_xs(const char *prefix, const char
return buf;
}
-void
+void NORETURN
die_xs(const char *err, va_list params)
{
- char *str;
- str = report_xs("fatal: ", err, params);
+ char *str = report_xs("fatal: ", err, params);
croak(str);
}
-int
+void
error_xs(const char *err, va_list params)
{
- char *str;
- str = report_xs("error: ", err, params);
+ char *str = report_xs("error: ", err, params);
warn(str);
- return -1;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: PPC SHA-1 Updates in "pu"
From: Petr Baudis @ 2006-06-25 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd5cyt8a3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 01:59:16AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > how does that compile for anybody else, when -DSHA1_HEADER isn't set
> > correctly? The quotes have gone missing:
> >
> > -DSHA1_HEADER='ppc/sha1.h'
> >
> > don't ask me why.
>
> That is, as usual, caused by careless shell quoting.
>
> : gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile
> GIT_VERSION = 1.4.1.rc1.g9adbe
> (cd perl && /usr/bin/perl Makefile.PL \
> PREFIX="/home/junio/git-test" \
> DEFINE="-O2 -Wall -Wdeclaration-after-statement
> -g -fPIC -DSHA1_HEADER='"ppc/sha1.h"'
> -DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
> LIBS="libgit.a xdiff/lib.a -lz")
> Unrecognized argument in LIBS ignored: 'libgit.a'
> Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
> Writing Makefile for Git
Oops...
----
Git.pm build: Fix $DEFINE quoting and missing GIT-CFLAGS dependency
Signed-off-by: Petr Baudis <pasky@suse.cz>
diff --git a/Makefile b/Makefile
index 9a59466..64375f6 100644
--- a/Makefile
+++ b/Makefile
@@ -608,10 +608,12 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
-perl/Makefile: perl/Git.pm perl/Makefile.PL
+PERL_DEFINES = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"'
+PERL_DEFINES_SQ = $(subst ','\'',$(PERL_DEFINES))
+perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
(cd perl && $(PERL_PATH) Makefile.PL \
PREFIX="$(prefix)" \
- DEFINE="$(ALL_CFLAGS) -DGIT_VERSION=\\\"$(GIT_VERSION)\\\"" \
+ DEFINE='$(PERL_DEFINES_SQ)' \
LIBS="$(EXTLIBS)")
doc:
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-24 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0606241338370.6483@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Don't everybody see them?
No. But I see it now.
> how does that compile for anybody else, when -DSHA1_HEADER isn't set
> correctly? The quotes have gone missing:
>
> -DSHA1_HEADER='ppc/sha1.h'
>
> don't ask me why.
That is, as usual, caused by careless shell quoting.
: gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile
GIT_VERSION = 1.4.1.rc1.g9adbe
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"ppc/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
All options but to use OpenSSL SHA-1 implementation share the
same problem (Meta/Make is a thin "make" wrapper to give USE_PIC
and other C compilation flags):
: gitster; ARM_SHA1=YesPlease Meta/Make perl/Makefile
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"arm/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
: gitster; MOZILLA_SHA1=YesPlease Meta/Make perl/Makefile
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"mozilla-sha1/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Martin Langhoff @ 2006-06-24 23:42 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30606240918m6b452314m6514b5e5fc86f147@mail.gmail.com>
Paolo,
I've seen in the irc logs that you were wondering whether we could a
web-based survey tool. Perhaps I can setup Moodle with an
easy-to-fillout survey. Interested?
martin
^ permalink raw reply
* Re: [PATCH 2/7] Merge with_raw, with_stat and summary variables to output_format
From: Johannes Schindelin @ 2006-06-24 23:20 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060625005654.627e176b.tihirvon@gmail.com>
Hi,
On Sun, 25 Jun 2006, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sat, 24 Jun 2006, Timo Hirvonen wrote:
> >
> > > @@ -818,17 +817,12 @@ void show_combined_diff(struct combine_d
> > > struct diff_options *opt = &rev->diffopt;
> > > if (!p->len)
> > > return;
> > > - switch (opt->output_format) {
> > > - case DIFF_FORMAT_RAW:
> > > - case DIFF_FORMAT_NAME_STATUS:
> > > - case DIFF_FORMAT_NAME:
> > > + if (opt->output_format & (DIFF_FORMAT_RAW |
> > > + DIFF_FORMAT_NAME |
> > > + DIFF_FORMAT_NAME_STATUS)) {
> > > show_raw_diff(p, num_parent, rev);
> > > - return;
> > > - case DIFF_FORMAT_PATCH:
> > > + } else if (opt->output_format & DIFF_FORMAT_PATCH) {
> >
> > Not that it matters, but this "else" could go. (Otherwise, "--raw -p"
> > would be the same as "--raw", right?)
>
> Just tested, ./git log -p --raw displays both raw and patch. I think it
> works because I changed diff_tree_combined() to use show_raw_diff() and
> show_patch_diff() directly.
>
> It feels 'wrong' to check flags and then call a function which checks
> the flags again. This combined diff stuff is confusing.
Sorry for not checking the result, but just the patch. I also find this
behaviour confusing. Junio?
> > > + int inter_name_termination = '\t';
> > > + int line_termination = options->line_termination;
> > > +
> > > + if (!line_termination)
> > > + inter_name_termination = 0;
> >
> > <nit type=minor>
> > This should be part of patch 1/7.
> > </nit>
>
> That clean up was possible only after I made other changes to the code,
> I think. At least it wasn't obvious when I wrote 1/7.
It is just a minor nit, I do not think it is necessary to change the
patch.
> > > show_stats(diffstat);
> > > free(diffstat);
> >
> > Why not go the full nine yards, and make diffstat not a pointer, but the
> > struct itself? You would avoid calloc()ing and free()ing. (Of course,
> > instead of calloc()ing you have to memset() it to 0.)
>
> I was blind :)
;-) In my experience, after staring at the code too long, you turn blind.
This is why I like a second pair of eyeballs so much.
> > > + if (output_format & DIFF_FORMAT_PATCH) {
> > > + if (output_format & (DIFF_FORMAT_DIFFSTAT |
> > > + DIFF_FORMAT_SUMMARY)) {
> > > + if (options->stat_sep)
> > > + fputs(options->stat_sep, stdout);
> > > + else
> > > + putchar(options->line_termination);
> >
> > Are we sure we do not want something like
> >
> > if (output_format / DIFF_FORMAT_DIFFSTAT > 1)
> > /* output separator */
> >
> > after each format (this example being after the diffstat), the condition
> > being: if there is still an output format to come, add the separator?
>
> I'm not sure what you mean.
>
> It outputs separator between (diffstat and/or summary) and patch.
> There's no separator between diffstat and summary or raw and diffstat.
> Should there be one?
IMHO there should be one.
> Thanks for your comments. Should I patch the patch or send a fixed one?
I cannot speak for Junio, but I think an additional patch to clean things
up would be the way to go.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Matthias Kestenholz @ 2006-06-24 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <94fc236b0606241455m22c4d285led04846a915267a2@mail.gmail.com>
* Adrien Beau (adrienbeau@gmail.com) wrote:
>
> The results of the Mercurial survey have been posted there:
> http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey
>
> An interesting read.
I find the answers to the question, what people most like to see
improved interesting: The improvement which got mentioned most often
was "merge across rename", something which git does already.
It seems, that partial checkouts and truncated history are the
only things left to implement for git from this list.
I am looking forward to a git user survey!
Matthias
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Petr Baudis @ 2006-06-24 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606241344450.6483@g5.osdl.org>
Dear diary, on Sat, Jun 24, 2006 at 10:52:04PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> Pasky, the homepage seems a bit pointless. Each individual page is so
> small that splitting it up into six different pages is just
> counter-productive.
Wow, finally some more feedback on the homepage!
> I'd almost suggest making it _one_ page, perhaps with some shortcuts
> within it (ie a "http://git.or.cz/index.html#tools" shortcut within the
> page instead of having a separate "http://git.or.cz/tools.html" page)
Good point. When designing the multi-page layout I expected much more
stuff to end up on the homepage but it sort of didn't happen and now the
Wiki seems to work pretty well, so I have folded it all back to a single
page. I ain't no webdesign-ka but it could've turned out worse; as
usual, I'm taking patches.
The menubar should be now actually useful for quick navigation between
various Git-related resources (going to Git's gitweb using this path
should be much faster than over kernel.org, especially when gitweb.cgi
has its bad days over there).
> I don't know about everybody else, but I get irritated at webpages that
> force me to just switch to another page to get any information. It's like
> how some web journalists split up a story over 20 pages, and each page is
> just a few paragraphs and some graphic (and the commercials, of course).
We could put up some commercials as well and use them for funding pizza
distributed in a round-robin fashion between the developers.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH 2/7] Merge with_raw, with_stat and summary variables to output_format
From: Timo Hirvonen @ 2006-06-24 21:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.63.0606242219320.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> thank you very much for doing the extra step and using the original
> constant names. I appreciate that.
>
> On Sat, 24 Jun 2006, Timo Hirvonen wrote:
>
> > @@ -818,17 +817,12 @@ void show_combined_diff(struct combine_d
> > struct diff_options *opt = &rev->diffopt;
> > if (!p->len)
> > return;
> > - switch (opt->output_format) {
> > - case DIFF_FORMAT_RAW:
> > - case DIFF_FORMAT_NAME_STATUS:
> > - case DIFF_FORMAT_NAME:
> > + if (opt->output_format & (DIFF_FORMAT_RAW |
> > + DIFF_FORMAT_NAME |
> > + DIFF_FORMAT_NAME_STATUS)) {
> > show_raw_diff(p, num_parent, rev);
> > - return;
> > - case DIFF_FORMAT_PATCH:
> > + } else if (opt->output_format & DIFF_FORMAT_PATCH) {
>
> Not that it matters, but this "else" could go. (Otherwise, "--raw -p"
> would be the same as "--raw", right?)
Just tested, ./git log -p --raw displays both raw and patch. I think it
works because I changed diff_tree_combined() to use show_raw_diff() and
show_patch_diff() directly.
It feels 'wrong' to check flags and then call a function which checks
the flags again. This combined diff stuff is confusing.
> > @@ -856,19 +846,18 @@ void diff_tree_combined(const unsigned c
> > [...]
> >
> > - if (do_diffstat && rev->loginfo)
> > - show_log(rev, rev->loginfo,
> > - opt->with_stat ? "---\n" : "\n");
> > + if (opt->output_format & DIFF_FORMAT_DIFFSTAT && rev->loginfo)
> > + show_log(rev, rev->loginfo, "---\n");
> > diff_flush(&diffopts);
> > - if (opt->with_stat)
> > + if (opt->output_format & DIFF_FORMAT_DIFFSTAT)
> > putchar('\n');
> > }
>
> Just a remark: this hunk actually changes behaviour. "with_stat" meant
> that the stat was prepended before something like a patch, and therefore a
> separator was needed. If you pass only "--stat", the separator will be
> printed anyway now.
You are right, it now prints --- when it should print empty line.
> > + int inter_name_termination = '\t';
> > + int line_termination = options->line_termination;
> > +
> > + if (!line_termination)
> > + inter_name_termination = 0;
>
> <nit type=minor>
> This should be part of patch 1/7.
> </nit>
That clean up was possible only after I made other changes to the code,
I think. At least it wasn't obvious when I wrote 1/7.
> > show_stats(diffstat);
> > free(diffstat);
>
> Why not go the full nine yards, and make diffstat not a pointer, but the
> struct itself? You would avoid calloc()ing and free()ing. (Of course,
> instead of calloc()ing you have to memset() it to 0.)
I was blind :)
> > + if (output_format & DIFF_FORMAT_PATCH) {
> > + if (output_format & (DIFF_FORMAT_DIFFSTAT |
> > + DIFF_FORMAT_SUMMARY)) {
> > + if (options->stat_sep)
> > + fputs(options->stat_sep, stdout);
> > + else
> > + putchar(options->line_termination);
>
> Are we sure we do not want something like
>
> if (output_format / DIFF_FORMAT_DIFFSTAT > 1)
> /* output separator */
>
> after each format (this example being after the diffstat), the condition
> being: if there is still an output format to come, add the separator?
I'm not sure what you mean.
It outputs separator between (diffstat and/or summary) and patch.
There's no separator between diffstat and summary or raw and diffstat.
Should there be one?
Thanks for your comments. Should I patch the patch or send a fixed one?
I'm currently too tired to write any code.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Adrien Beau @ 2006-06-24 21:55 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30606240918m6b452314m6514b5e5fc86f147@mail.gmail.com>
On 6/24/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>
> I was wondering whether it could be a good idea to have a kind of "GIT
> users survey" when google pointed my eyes to this page:
> http://www.selenic.com/pipermail/mercurial/2006-April/007513.html
>
> So I modified the content of the survey and published a DRAF here:
> http://paolo.ciarrocchi.googlepages.com/GITSurvey
>
> (...)
>
> What do people living in this ML think about this suvery?
> Do you have any suggestion?
> Do you think it worth the effort?
The results of the Mercurial survey have been posted there:
http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey
An interesting read.
^ permalink raw reply
* Re: [PATCH 2/7] Merge with_raw, with_stat and summary variables to output_format
From: Johannes Schindelin @ 2006-06-24 20:52 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060624202153.1001a66c.tihirvon@gmail.com>
Hi,
thank you very much for doing the extra step and using the original
constant names. I appreciate that.
On Sat, 24 Jun 2006, Timo Hirvonen wrote:
> @@ -818,17 +817,12 @@ void show_combined_diff(struct combine_d
> struct diff_options *opt = &rev->diffopt;
> if (!p->len)
> return;
> - switch (opt->output_format) {
> - case DIFF_FORMAT_RAW:
> - case DIFF_FORMAT_NAME_STATUS:
> - case DIFF_FORMAT_NAME:
> + if (opt->output_format & (DIFF_FORMAT_RAW |
> + DIFF_FORMAT_NAME |
> + DIFF_FORMAT_NAME_STATUS)) {
> show_raw_diff(p, num_parent, rev);
> - return;
> - case DIFF_FORMAT_PATCH:
> + } else if (opt->output_format & DIFF_FORMAT_PATCH) {
Not that it matters, but this "else" could go. (Otherwise, "--raw -p"
would be the same as "--raw", right?)
> show_patch_diff(p, num_parent, dense, rev);
> - return;
> - default:
> - return;
> }
> }
> @@ -856,19 +846,18 @@ void diff_tree_combined(const unsigned c
> [...]
>
> - if (do_diffstat && rev->loginfo)
> - show_log(rev, rev->loginfo,
> - opt->with_stat ? "---\n" : "\n");
> + if (opt->output_format & DIFF_FORMAT_DIFFSTAT && rev->loginfo)
> + show_log(rev, rev->loginfo, "---\n");
> diff_flush(&diffopts);
> - if (opt->with_stat)
> + if (opt->output_format & DIFF_FORMAT_DIFFSTAT)
> putchar('\n');
> }
Just a remark: this hunk actually changes behaviour. "with_stat" meant
that the stat was prepended before something like a patch, and therefore a
separator was needed. If you pass only "--stat", the separator will be
printed anyway now.
> diff --git a/diff.c b/diff.c
> index f358546..bfed79c 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1372,23 +1372,27 @@ int diff_setup_done(struct diff_options
> (0 <= options->rename_limit && !options->detect_rename))
> return -1;
>
> + if (options->output_format & DIFF_FORMAT_NO_OUTPUT)
> + options->output_format = 0;
> +
> + if (options->output_format & (DIFF_FORMAT_NAME |
> + DIFF_FORMAT_NAME_STATUS |
> + DIFF_FORMAT_CHECKDIFF |
> + DIFF_FORMAT_NO_OUTPUT))
The DIFF_FORMAT_NO_OUTPUT here makes no sense (if it was set, you unset it
above).
> @@ -1671,15 +1674,17 @@ const char *diff_unique_abbrev(const uns
> [...]
>
> static void diff_flush_raw(struct diff_filepair *p,
> - int line_termination,
> - int inter_name_termination,
> - struct diff_options *options,
> - int output_format)
> + struct diff_options *options)
> {
> int two_paths;
> char status[10];
> int abbrev = options->abbrev;
> const char *path_one, *path_two;
> + int inter_name_termination = '\t';
> + int line_termination = options->line_termination;
> +
> + if (!line_termination)
> + inter_name_termination = 0;
<nit type=minor>
This should be part of patch 1/7.
</nit>
> @@ -2041,55 +2028,61 @@ static void diff_summary(struct diff_fil
> [...]
>
> - if (options->with_raw) {
> + if (output_format & (DIFF_FORMAT_RAW |
> + DIFF_FORMAT_NAME |
> + DIFF_FORMAT_NAME_STATUS |
> + DIFF_FORMAT_CHECKDIFF)) {
> for (i = 0; i < q->nr; i++) {
> struct diff_filepair *p = q->queue[i];
> - flush_one_pair(p, DIFF_FORMAT_RAW, options, NULL);
> + if (check_pair_status(p))
> + flush_one_pair(p, options);
This is a very nice cleanup.
> }
> - if (options->with_stat) {
> +
> + if (output_format & DIFF_FORMAT_DIFFSTAT) {
> + struct diffstat_t *diffstat;
> +
> + diffstat = xcalloc(sizeof (struct diffstat_t), 1);
> + diffstat->xm.consume = diffstat_consume;
> for (i = 0; i < q->nr; i++) {
> struct diff_filepair *p = q->queue[i];
> - flush_one_pair(p, DIFF_FORMAT_DIFFSTAT, options,
> - diffstat);
> + if (check_pair_status(p))
> + diff_flush_stat(p, options, diffstat);
Again, very nice.
> }
> show_stats(diffstat);
> free(diffstat);
Why not go the full nine yards, and make diffstat not a pointer, but the
struct itself? You would avoid calloc()ing and free()ing. (Of course,
instead of calloc()ing you have to memset() it to 0.)
> + if (output_format & DIFF_FORMAT_PATCH) {
> + if (output_format & (DIFF_FORMAT_DIFFSTAT |
> + DIFF_FORMAT_SUMMARY)) {
> + if (options->stat_sep)
> + fputs(options->stat_sep, stdout);
> + else
> + putchar(options->line_termination);
Are we sure we do not want something like
if (output_format / DIFF_FORMAT_DIFFSTAT > 1)
/* output separator */
after each format (this example being after the diffstat), the condition
being: if there is still an output format to come, add the separator?
All in all, I like this patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Linus Torvalds @ 2006-06-24 20:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Randal L. Schwartz, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20060624200401.GV21864@pasky.or.cz>
On Sat, 24 Jun 2006, Petr Baudis wrote:
>
> It is also linked from the homepage, although not as prominently as it
> should be; it grew nicely over the time so it probably deserves a more
> visible link now. I will add it on the front page.
Pasky, the homepage seems a bit pointless. Each individual page is so
small that splitting it up into six different pages is just
counter-productive.
I'd almost suggest making it _one_ page, perhaps with some shortcuts
within it (ie a "http://git.or.cz/index.html#tools" shortcut within the
page instead of having a separate "http://git.or.cz/tools.html" page)
Hmm?
In contrast, the wiki frontpage actually works pretty well - it's got more
of that kind of "multiple sub-headers all on the same page" kind of
layout, with just extra _details_ behind the links.
I don't know about everybody else, but I get irritated at webpages that
force me to just switch to another page to get any information. It's like
how some web journalists split up a story over 20 pages, and each page is
just a few paragraphs and some graphic (and the commercials, of course).
I'd much rather _scroll_ a bit, or use ^F to _search_, than have to click
through links.
Linus
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Linus Torvalds @ 2006-06-24 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vhd2atid1.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Jun 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Also, "pu" in general is totally unusable. It doesn't even compile.
>
> Care to share problems with Pasky and I to take a look at,
> please?
Don't everybody see them?
In file included from Git.xs:8:
../cache.h:6:10: error: #include expects "FILENAME" or <FILENAME>
In file included from /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/perl.h:756,
from Git.xs:15:
/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/embed.h:4195:1: warning: "die" redefined
Git.xs:11:1: warning: this is the location of the previous definition
Git.xs: In function 'boot_Git':
Git.xs:57: warning: passing argument 1 of 'set_error_routine' from incompatible pointer type
Git.xs:58: warning: passing argument 1 of 'set_die_routine' makes qualified function pointer from unqualified
make[1]: *** [Git.o] Error 1
make[1]: Leaving directory `/home/torvalds/git/perl'
make: *** [all] Error 2
how does that compile for anybody else, when -DSHA1_HEADER isn't set
correctly? The quotes have gone missing:
-DSHA1_HEADER='ppc/sha1.h'
don't ask me why.
Linus
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-24 20:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0606241147480.6483@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Also, "pu" in general is totally unusable. It doesn't even compile.
Care to share problems with Pasky and I to take a look at,
please?
> I think that "Git.xs" thing is fine for random hacks, but please please
> PLEASE don't make any central program depend on it.
I agree. I got really disgusted when I tentatively pulled the
current Git.xs into "next" and installed it for my own use to
notice that it broke git-fmt-merge-msg hence git-pull workflow.
Pasky, can we first iron out kinks in the build procedure and
installation before converting existing programs further? The
things I worry about currently are:
- the SITELIBARCH gotcha I sent you a message about (and you
responded to it already -- was that an Acked-by?);
- RPM target -- we probably acquired a new build-dependency in
which case the .spec file needs to be updated;
- Make sure Git.xs builds and installed result works fine on
all platforms we care about, including Cygwin and other
non-Linux boxes.
I'd even suggest we revert the changes to git-fmt-merge-msg to
keep it working for now, until the above worries are resolved.
Otherwise we cannot have it in "next" safely (and I REALLY _do_
want to have Git.pm infrastructure in "next" soonish).
We can start using Git.xs and friends in some _new_ ancillary
programs, once we solve building and installing problems for
everybody. That way it would help us gain portability and
confidence without disrupting existing users.
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Johannes Schindelin @ 2006-06-24 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmg35pkt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 23 Jun 2006, Junio C Hamano wrote:
> By the way, I noticed NO_ACCURATE_DIFF is a compile time option
> to cause git-apply to accept diff output from implementations
> that botch "\No newline at the end of file", and I think it is
> wrong -- it should be a run time option to git-apply if we would
> want to support it, because the version of diff you have does
> not have much to do with which implementations of diff were used
> to generate patches you would receive and apply.
>
> Thoughts?
My original idea: on a machine where you have no accurate diff, you at
least want to pass the tests, and you want to ensure you can apply a diff
you generated on that machine.
But I was wrong. This patch is just compile tested, but obviously correct
(lacking usage() and Documentation updates as usual, since I do not want
to do that work before I know the patch is applied):
---
[PATCH] apply: add --no-accurate-diff and --accurate-diff options
You can still set the default behaviour in the Makefile, but at least you
can override it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-apply.c | 32 +++++++++++++++++++++++---------
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index e113c74..2d26ade 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -125,6 +125,7 @@ #define BINARY_LITERAL_DEFLATED 2
unsigned long deflate_origlen;
int lines_added, lines_deleted;
int score;
+ int no_accurate_diff:1;
struct fragment *fragments;
char *result;
unsigned long resultsize;
@@ -1333,7 +1334,8 @@ static int apply_line(char *output, cons
return plen;
}
-static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag)
+static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag,
+ int no_accurate_diff)
{
int match_beginning, match_end;
char *buf = desc->buffer;
@@ -1386,13 +1388,11 @@ static int apply_one_fragment(struct buf
size -= len;
}
-#ifdef NO_ACCURATE_DIFF
- if (oldsize > 0 && old[oldsize - 1] == '\n' &&
+ if (no_accurate_diff && oldsize > 0 && old[oldsize - 1] == '\n' &&
newsize > 0 && new[newsize - 1] == '\n') {
oldsize--;
newsize--;
}
-#endif
oldlines = old;
newlines = new;
@@ -1614,7 +1614,7 @@ static int apply_fragments(struct buffer
return apply_binary(desc, patch);
while (frag) {
- if (apply_one_fragment(desc, frag) < 0)
+ if (apply_one_fragment(desc, frag, patch->no_accurate_diff) < 0)
return error("patch failed: %s:%ld",
name, frag->oldpos);
frag = frag->next;
@@ -2097,7 +2097,7 @@ static int use_patch(struct patch *p)
return 1;
}
-static int apply_patch(int fd, const char *filename)
+static int apply_patch(int fd, const char *filename, int no_accurate_diff)
{
unsigned long offset, size;
char *buffer = read_patch_file(fd, &size);
@@ -2113,6 +2113,7 @@ static int apply_patch(int fd, const cha
int nr;
patch = xcalloc(1, sizeof(*patch));
+ patch->no_accurate_diff = no_accurate_diff;
nr = parse_chunk(buffer + offset, size, patch);
if (nr < 0)
break;
@@ -2180,6 +2181,11 @@ int cmd_apply(int argc, const char **arg
{
int i;
int read_stdin = 1;
+#ifdef NO_ACCURATE_DIFF
+ int no_accurate_diff = 1;
+#else
+ int no_accurate_diff = 0;
+#endif
const char *whitespace_option = NULL;
for (i = 1; i < argc; i++) {
@@ -2188,7 +2194,7 @@ int cmd_apply(int argc, const char **arg
int fd;
if (!strcmp(arg, "-")) {
- apply_patch(0, "<stdin>");
+ apply_patch(0, "<stdin>", no_accurate_diff);
read_stdin = 0;
continue;
}
@@ -2265,6 +2271,14 @@ int cmd_apply(int argc, const char **arg
parse_whitespace_option(arg + 13);
continue;
}
+ if (!strcmp(arg, "--no-accurate-diff")) {
+ no_accurate_diff = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--accurate-diff")) {
+ no_accurate_diff = 0;
+ continue;
+ }
if (check_index && prefix_length < 0) {
prefix = setup_git_directory();
@@ -2281,12 +2295,12 @@ int cmd_apply(int argc, const char **arg
usage(apply_usage);
read_stdin = 0;
set_default_whitespace_mode(whitespace_option);
- apply_patch(fd, arg);
+ apply_patch(fd, arg, no_accurate_diff);
close(fd);
}
set_default_whitespace_mode(whitespace_option);
if (read_stdin)
- apply_patch(0, "<stdin>");
+ apply_patch(0, "<stdin>", no_accurate_diff);
if (whitespace_error) {
if (squelch_whitespace_errors &&
squelch_whitespace_errors < whitespace_error) {
^ permalink raw reply related
* Re: [RFC] GIT user survey
From: Petr Baudis @ 2006-06-24 20:04 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <863bduba81.fsf@blue.stonehenge.com>
Dear diary, on Sat, Jun 24, 2006 at 09:54:38PM CEST, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> I think my point is that I read this list regularly, but
> I had no idea there was a wiki. Where is it being promoted?
> Surely not on git(1). Was it announced here? How often?
It was announced in
15227 F May 03 Petr Baudis ( 1.1K) [ANNOUNCE] Git wiki
spawning a 61-mails thread. ;-)
It is also linked from the homepage, although not as prominently as it
should be; it grew nicely over the time so it probably deserves a more
visible link now. I will add it on the front page.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Randal L. Schwartz @ 2006-06-24 19:54 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30606241008w6cf9e6c0hf230ff1091194a7c@mail.gmail.com>
>>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
Paolo> On 24 Jun 2006 10:05:33 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>> >>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
>>
Paolo> 1. Do you use the GIT wiki? If yes, do you find it useful?
>>
>> There's a git wiki??
Paolo> Yup.
Paolo> http://git.or.cz/gitwiki/FrontPage
I think my point is that I read this list regularly, but
I had no idea there was a wiki. Where is it being promoted?
Surely not on git(1). Was it announced here? How often?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001 [PATCH] Makefile: add framework to verify and bench sha1 implementations.
From: Junio C Hamano @ 2006-06-24 19:47 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20060624092921.32165.qmail@science.horizon.com>
linux@horizon.com writes:
> Nice work, but I might point out that the original PPC SHA bug was hashing
> more than 0.5G of contiguous data in a *single* call to SHA1_Update,
> while your test program works with 8K buffers.
Blush. I realized it and updated the version in "pu" after I
sen the message.
^ permalink raw reply
* Re: [PATCH] diff --color: use $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-24 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v7j36yfh1.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sat, 24 Jun 2006, Junio C Hamano wrote:
> BTW, while doing this, I noticed that the patch does not do the
> color output for combined diffs. Care to look into it after
> Timo's output format series settles?
You mean just copying the relevant parts from your patch, which I missed,
and do minimal testing? Sure ;-)
But first, by way of thanks to Martin, I have to reintroduce into
format-patch the check for patches which are already upstream.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Johannes Schindelin @ 2006-06-24 19:42 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio
In-Reply-To: <11511475882820-git-send-email-martin@catalyst.net.nz>
Hi,
almost happy.
On Sat, 24 Jun 2006, Martin Langhoff wrote:
> unless ($index{$branch}) {
> $index{$branch} = tmpnam();
> $ENV{GIT_INDEX_FILE} = $index{$branch};
> - system("git-read-tree", $branch);
> + }
> + if ($ancestor) {
> + system("git-read-tree", $ancestor);
> die "read-tree failed: $?\n" if $?;
> } else {
> + unless ($index{$branch}) {
> + $index{$branch} = tmpnam();
> + $ENV{GIT_INDEX_FILE} = $index{$branch};
> + system("git-read-tree", $branch);
> + die "read-tree failed: $?\n" if $?;
> + }
> + }
This line ^ seems to have white space at the end.
Also, in my case, this is still broken. $index{$branch} is set, $ancestor
not, but $ENV{GIT_INDEX_FILE} ne $index{$branch}.
You can reproduce this by importing into branch origin while branch master
(which is not equal to origin) is checked out.
Plus, the initial setting of GIT_INDEX_FILE forgot to perform a
git-read-tree.
How about this on top of your patch (which fixes things with my setup):
---
[PATCH] cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
Also, make sure that the initial git-read-tree is performed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsimport | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
--- git-cvsimport.perl 2006-06-24 20:30:33.000000000 +0200
+++ git-cvsimport 2006-06-24 21:35:42.000000000 +0200
@@ -470,6 +470,9 @@
$index{$opt_o} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$opt_o};
+system("git-read-tree", $opt_o);
+die "read-tree failed: $?\n" if $?;
+
unless(-d $git_dir) {
system("git-init-db");
die "Cannot init the GIT db at $git_tree: $?\n" if $?;
@@ -813,17 +816,15 @@
unless ($index{$branch}) {
$index{$branch} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$branch};
+ system("git-read-tree", $branch);
+ die "read-tree failed: $?\n" if $?;
}
+ # just in case
+ $ENV{GIT_INDEX_FILE} = $index{$branch};
if ($ancestor) {
+ print "have ancestor $ancestor" if $opt_v;
system("git-read-tree", $ancestor);
die "read-tree failed: $?\n" if $?;
- } else {
- unless ($index{$branch}) {
- $index{$branch} = tmpnam();
- $ENV{GIT_INDEX_FILE} = $index{$branch};
- system("git-read-tree", $branch);
- die "read-tree failed: $?\n" if $?;
- }
}
} else {
# just in case
^ permalink raw reply
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Johannes Schindelin @ 2006-06-24 19:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7vslluyika.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 24 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I would not care too strongly about that. Eventually, I really would like
> > this file to reside in $GIT_DIR, not /tmp, but whatever. That is not my
> > biggest concern right now. That I cannot update since June 18th, however,
> > is.
>
> Would reverting 8f732649 in the meantime be an option for you?
I think it is worth fixing instead of working around.
Ciao,
Dscho
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Linus Torvalds @ 2006-06-24 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtb6yip5.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Jun 2006, Junio C Hamano wrote:
>
> If somebody has time and inclination, please try updated PPC SHA-1
> from linux@horizon.com that is in "pu" (say make check-sha1) and
> report impressions.
"make check-sha1" passes.
Before:
[torvalds@g5 linux]$ /usr/bin/time git-fsck-objects --full
101.90user 4.66system 1:46.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1787158minor)pagefaults 0swaps
After:
[torvalds@g5 linux]$ /usr/bin/time ~/git/git-fsck-objects --full
101.16user 4.32system 1:45.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1787127minor)pagefaults 0swaps
which doesn't seem to really imply anything seriously changed (in fact,
rerunning it made the numbers even closer).
This is on a G5 powerpc.
Also, "pu" in general is totally unusable. It doesn't even compile.
I think that "Git.xs" thing is fine for random hacks, but please please
PLEASE don't make any central program depend on it.
Linus
^ 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