* Ocupacion temporal para un trabajo a tiempo parcial
From: Diann @ 2006-06-25 0:36 UTC (permalink / raw)
To: git
Hola!.
Este correo electrónico le muestra una oferta de trabajo, que podrÃa ser interesante a usted.
Gerente financiero situado en su paÃs! Trabajo en Internet con buen sueldo!
GoldLeader Inc. busca a personas enérgicas y responsables para completar el
puesto de encargado de deudores de media jornada.
Como encargado de deudores, usted será el responsable de procesar y facilitar
las transferencias de fondos iniciadas por nuestros clientes bajo la supervisión del gerente regional.
Ofrecemos:
- Ventajas buenas (más de 1000 $ por semana);
- Contrato legal;
Se precisa puntualidad, capacidades directivas y responsabilidad.
Usted también recibirá instrucciones detalladas para acciones
subsecuentes de nuestro gerente, con información sobre como recibir/transferir el dinero.
1. Ser capaz de comprobar su correo electrónico varias veces por dÃa
2. Ser capaz de responder a correos electrónico inmediatamente
3. Ser capaz de trabajar horas extra si es necesario
4. Ser responsable y trabajador
5. Hablar ingles
6. Tener más de 21 años;
7. DeberÃa tener una cuenta bancaria personal
Para información adicionales y preguntas sobre el puesto de trabajo,
por favor envÃe sus datos de contacto a career@goldleader.biz
NO SON VENTAS!!! NO SON LLAMADAS!!!
USTED NO NECESITA DINERO PARA COMENZAR!!!
Gracias por su atencion.
Con respeto,
Departamento de personal Goldleader Inc.
http://www.goldleader.biz
^ permalink raw reply
* On boolean configuration variables...
From: Junio C Hamano @ 2006-06-24 12:28 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Boolean configuration variables in $GIT_DIR/config are a bit
strange.
[bool]
var1
var2 =
var3 = true
var4 = yes
var5 = 1
var6 = 2
var7 = false
var8 = no
var9 = 0
var1, var3, var5, and var6 are "true"; var2, var7 and var9 are
"false". var4 and var8 are syntax errors.
Currently "git repo-config --bool --get bool.var1" returns
"false", which is fixed by the attached patch, but I am
wondering if it is a good idea to allow "yes" and "no" as well.
-- >8 --
[PATCH] repo-config: fix printing of bool
When a bool variable appears without any value, it means true.
However, replacing the NULL value with an empty string, an earlier
commit f067a13745fbeae1aa357876348a00e5edd0a629 broke show-config.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
repo-config.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/repo-config.c b/repo-config.c
index ab8f1af..743f02b 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -29,16 +29,13 @@ static int show_config(const char* key_,
const char *vptr = value;
int dup_error = 0;
- if (value_ == NULL)
- value_ = "";
-
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)))
+ regexec(regexp, (value_?value_:""), 0, NULL, 0)))
return 0;
if (show_keys)
@@ -46,11 +43,11 @@ static int show_config(const char* key_,
if (seen && !do_all)
dup_error = 1;
if (type == T_INT)
- sprintf(value, "%d", git_config_int(key_, value_));
+ sprintf(value, "%d", git_config_int(key_, value_?value_:""));
else if (type == T_BOOL)
vptr = git_config_bool(key_, value_) ? "true" : "false";
else
- vptr = value_;
+ vptr = value_?value_:"";
seen++;
if (dup_error) {
error("More than one value for the key %s: %s",
--
1.4.1.rc1.ga77b7
^ permalink raw reply related
* Re: [PATCH 01/12] Introduce Git.pm (v4)
From: Junio C Hamano @ 2006-06-24 11:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060624111657.GR21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (This is also why I was a bit confused by your make test patch - it does
> not "fix" anything per se since no tests directly use Git.pm.)
You are right.
You do not want to be testing installed version, but the one
freshly built, so the patch does not have any effect, except for
one case: testing before installing Git.pm for the first time
anywhere yet. -I prepends the directory to the search path, so
we are not testing the freshly built copy at all.
Is there a way from the environment to override this behaviour,
so that we can run the tests properly? I think PERL5LIB and
PERLLIB are defeated by having -I there (that's why I said I
liked what Fredrik did with his Python script, which appends the
final installed location to the search path). I think unshift
into @INC by hand (i.e. without even using use lib "$path")
would do what we want, but I feel that is a bit too ugly just
for the testing X-<.
I suspect we would need to think this a bit more... sigh.
> ...because well, they do:
>
> $(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
> rm -f $@ $@+
> sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
> -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
> $@.perl >$@+
> chmod +x $@+
> mv $@+ $@
I'll need to look at why it fails for me, but the above seems to
be doing the right thing, from a superficial look at least.
git-fmt-merge-msg substituted like the above begins with:
#!/usr/bin/perl -w -I/home/junio/git-pu/share/perl/5.8.8
because my $(prefix) is /home/junio/git-pu/ when building from "pu"
branch. Then it goes on to create ~/git-pu/{lib,share}/perl/5.8.8
and does this:
make -C perl install
make[1]: Entering directory `/opt/git/git.git/perl'
Installing /home/junio/git-pu/lib/perl/5.8.8/auto/Git/Git.so
Installing /home/junio/git-pu/lib/perl/5.8.8/auto/Git/Git.bs
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /home/junio/git-pu/lib/perl/5.8.8/Git.pm
Installing /home/junio/git-pu/lib/perl/5.8.8/Error.pm
Installing /home/junio/git-pu/man/man3/Error.3pm
Installing /home/junio/git-pu/man/man3/Git.3pm
Writing /home/junio/git-pu/lib/perl/5.8.8/auto/Git/.packlist
Appending installation info to /home/junio/git-pu/lib/perl/5.8.8/perllocal.pod
It appears that this is needed perhaps?
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 54e8b20..92c140d 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -3,7 +3,7 @@ use ExtUtils::MakeMaker;
sub MY::postamble {
return <<'MAKE_FRAG';
instlibdir:
- @echo $(INSTALLSITELIB)
+ @echo $(INSTALLSITEARCH)
MAKE_FRAG
}
^ permalink raw reply related
* Re: [PATCH 01/12] Introduce Git.pm (v4)
From: Petr Baudis @ 2006-06-24 11:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060624111657.GR21864@pasky.or.cz>
Dear diary, on Sat, Jun 24, 2006 at 01:16:57PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> $(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
> rm -f $@ $@+
> sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
> -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
> $@.perl >$@+
> chmod +x $@+
> mv $@+ $@
>
> (This is also why I was a bit confused by your make test patch - it does
> not "fix" anything per se since no tests directly use Git.pm.)
And this makes the Perl scripts work even without make install:
Signed-off-by: Petr Baudis <pasky@suse.cz>
diff --git a/Makefile b/Makefile
index 7842195..d614f18 100644
--- a/Makefile
+++ b/Makefile
@@ -509,7 +509,9 @@ common-cmds.h: Documentation/git-*.txt
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
rm -f $@ $@+
- sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e '2i\
+ use lib qw ('"$$(make -s -C perl instlibdir)"' '"$$(pwd)"'/perl/blib/lib);' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@+
chmod +x $@+
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 54e8b20..2cbd227 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -2,6 +2,9 @@ use ExtUtils::MakeMaker;
sub MY::postamble {
return <<'MAKE_FRAG';
+all::
+ cp blib/arch/auto/Git/* blib/lib/auto/Git/
+
instlibdir:
@echo $(INSTALLSITELIB)
--
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
* [RFC] git-fetch - repack in the background after fetching
From: Martin Langhoff @ 2006-06-24 11:30 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
Check whether we have a large set of unpacked objects and repack
after the fetch, but don't for the user to wait for us. Conditional
on core.autorepack =! no.
Having ' handle concurrent pruning of packed objects'
(637cdd9d1d997fca34a1fc668fed1311e30fe95f) from Jeff King it should
be safe to repack and prune in the background.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
This is a follow up to a similar patch earlier
http://www.gelato.unsw.edu.au/archives/git/0605/21401.html -- is there
interest in making GIT more friendly to users who don't know or care
about packing and repacking their repos?
I loathe to do this conditionally only on the count of unpacked
objects. If there's a quick'n'dirty way of asking portably whether
the machine is busy or otherwise resource-constrained (ie: on battery)
it should use it to avoid running repack at inconvenient times.
---
git-fetch.sh | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..7211318 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -427,3 +427,12 @@ case ",$update_head_ok,$orig_head," in
fi
;;
esac
+
+if test "$(git-repo-config --get core.autorepack)" != 'no'
+then
+ if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+ then
+ echo "Repacking in the background"
+ nice git repack -a -d -q &
+ fi
+fi
--
1.4.1.rc1.g59c8
^ permalink raw reply related
* Re: [PATCH 2/5] Rework diff options
From: Timo Hirvonen @ 2006-06-24 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodwj11qa.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > diff --git a/builtin-log.c b/builtin-log.c
> > index 5a8a50b..e4a6385 100644
> > --- a/builtin-log.c
> > +++ b/builtin-log.c
> > @@ -26,8 +26,8 @@ static int cmd_log_wc(int argc, const ch
> > if (rev->always_show_header) {
> > if (rev->diffopt.pickaxe || rev->diffopt.filter) {
> > rev->always_show_header = 0;
> > - if (rev->diffopt.output_format == DIFF_FORMAT_RAW)
> > - rev->diffopt.output_format = DIFF_FORMAT_NO_OUTPUT;
> > + if (rev->diffopt.output_fmt & OUTPUT_FMT_RAW)
> > + rev->diffopt.output_fmt |= OUTPUT_FMT_NONE;
> > }
> > }
>
> The original code is saying "For git-log command (i.e. when
> always-show-header is on), if the command line did not override
> but ended up asking for diff only because it wanted to do -S or
> --diff-filter, do not show any diff" which is quite an opaque
> logic.
I'll just remove this change from the fixed patch 2/5. New version of
the patch 3/5 should then fix this logic.
> > @@ -1371,23 +1371,26 @@ int diff_setup_done(struct diff_options
> > (0 <= options->rename_limit && !options->detect_rename))
> > return -1;
> >
> > + if (options->output_fmt & OUTPUT_FMT_NONE)
> > + options->output_fmt = 0;
> > +
> > + if (options->output_fmt & (OUTPUT_FMT_NAME |
> > + OUTPUT_FMT_CHECKDIFF |
> > + OUTPUT_FMT_NONE))
> > + options->output_fmt &= ~(OUTPUT_FMT_RAW |
> > + OUTPUT_FMT_DIFFSTAT |
> > + OUTPUT_FMT_SUMMARY |
> > + OUTPUT_FMT_PATCH);
> > +
>
> Maybe doing the same for --name-status?
Will fix. Originally I made --name-status imply --name-only but changed
it and forgot to fix this.
> I wonder if the --name,
> --name-status and --check should be mutually exclusive. What
> happens when you specify more than one of them?
I'll just make it die() then. If it breaks something then the code is
really dumb anyway.
> > diff --git a/revision.c b/revision.c
> > index b963f2a..4ad2272 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -852,8 +852,8 @@ int setup_revisions(int argc, const char
> > if (revs->combine_merges) {
> > revs->ignore_merges = 0;
> > if (revs->dense_combined_merges &&
> > - (revs->diffopt.output_format != DIFF_FORMAT_DIFFSTAT))
> > - revs->diffopt.output_format = DIFF_FORMAT_PATCH;
> > + !(revs->diffopt.output_fmt & OUTPUT_FMT_DIFFSTAT))
> > + revs->diffopt.output_fmt |= OUTPUT_FMT_PATCH;
> > }
> > revs->diffopt.abbrev = revs->abbrev;
> > diff_setup_done(&revs->diffopt);
>
> This tells it to default to patch format unless we are asked to
> do diffstat only, in which case we just show stat without patch.
> The new logic seems to be fishy.
If we first initialize it to 0 instead of DIFF_FORMAT_RAW and after
command line flags have been parsed, if it still is 0, then default to
DIFF_FORMAT_PATCH.
> - could I ask you to redo a patch to do only the clean-up part
> first, so that I can accept it for either "next" or "master".
>
> - Then after I take the clean-up, could you rebase four
> remainder patches ("Rework diff options" to "Add --patch
> option for diff-*") on the result? The patches this round
> are already split quite well in that the first one does the
> enum to bit conversion and the latter three cleans things up
> (all of which I like a lot). As Johannes suggested, it might
> be easier to review if they reused the same preprocessor
> symbols instead of renaming them. I'd take them for "next".
Yes, all this makes sense.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Junio C Hamano @ 2006-06-24 11:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, git
In-Reply-To: <46a038f90606240416n563288f5q99a5ac81723776c3@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Johannes, Junio,
>
> I've managed to repro the problem -- which was totally reproduceable,
> I was just testing the wrong version of the script. The problem was
> quite obvious: when running an incremental, the first head would not
> get the index created properly. Even worse, when forking a new branch,
> the index would be empty too.
>
> Fixed both cases and posted separately.
Thanks. Will be in "next".
^ permalink raw reply
* [PATCH] diff --color: use reset sequence when we mean reset.
From: Junio C Hamano @ 2006-06-24 11:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606221301500.5498@g5.osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> - always reset the color _before_ printing out the newline.
>
> This is actually important. You (and Johannes) didn't see it, because
> it only matters if you set the background, but if you don't do this,
> you get some random and funky behaviour if you pick a color with a
> non-default background (which still potentially has problems with tabs
> etc, but less so).
Doh.
I think you did not see it until you tried "git diff" with
a stat-dirty but otherwise unmodified file.
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 33c8c57..549f4e0 100644
--- a/diff.c
+++ b/diff.c
@@ -681,7 +681,7 @@ static void builtin_diff(const char *nam
const char *lbl[2];
char *a_one, *b_two;
const char *set = get_color(o->color_diff, DIFF_METAINFO);
- const char *reset = get_color(o->color_diff, DIFF_PLAIN);
+ const char *reset = get_color(o->color_diff, DIFF_RESET);
a_one = quote_two("a/", name_a);
b_two = quote_two("b/", name_b);
--
1.4.1.rc1.ga77b7
^ permalink raw reply related
* Re: [PATCH 01/12] Introduce Git.pm (v4)
From: Petr Baudis @ 2006-06-24 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu06bymtr.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jun 24, 2006 at 10:33:52AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> The reason it failed? Well, it could not find Git.pm because
> the changes to fmt-merge-msg was done for distros not for people
> who install under their home directories.
I don't understand what are you trying to say here...
> Now, I am quite unhappy about the situation (and it is not your
> fault). "git pull" is something almost everybody uses, and
> having the series means they would need to make sure whereever
> Git.pm is installed is on their PERL5LIB as things currently
> stand.
...because well, they do:
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
rm -f $@ $@+
sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@+
chmod +x $@+
mv $@+ $@
(This is also why I was a bit confused by your make test patch - it does
not "fix" anything per se since no tests directly use Git.pm.)
--
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] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Martin Langhoff @ 2006-06-24 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Martin Langhoff
In-Reply-To: <7vslluyika.fsf@assigned-by-dhcp.cox.net>
Johannes, Junio,
I've managed to repro the problem -- which was totally reproduceable,
I was just testing the wrong version of the script. The problem was
quite obvious: when running an incremental, the first head would not
get the index created properly. Even worse, when forking a new branch,
the index would be empty too.
Fixed both cases and posted separately. Thanks for the sharp eyes, and
sorry about the bug!
martin
^ permalink raw reply
* [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Martin Langhoff @ 2006-06-24 11:13 UTC (permalink / raw)
To: git, junkio, Johannes.Schindelin; +Cc: Martin Langhoff
Two bugs had slipped in the "keep one index per branch during import"
patch. Both incremental imports and new branches would see an
empty tree for their initial commit. Now we cover all the relevant
cases, checking whether we actually need to setup the index before
preparing the actual commit, and doing it.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-cvsimport.perl | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
old mode 100644
new mode 100755
index d961b7b..1c1fd02
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -813,11 +813,26 @@ while(<CVS>) {
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 $?;
+ }
+ }
+ } else {
+ # just in case
+ unless ($index{$branch}) {
+ $index{$branch} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$branch};
- }
+ system("git-read-tree", $branch);
+ die "read-tree failed: $?\n" if $?;
+ }
}
$last_branch = $branch if $branch ne $last_branch;
$state = 9;
--
1.4.1.rc1.g59c8
^ permalink raw reply related
* [PATCH] diff --color: use $GIT_DIR/config
From: Junio C Hamano @ 2006-06-24 11:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0606230756050.6483@g5.osdl.org>
This lets you use something like this in your $GIT_DIR/config
file.
[diff]
color = auto
[diff.color]
new = blue
old = yellow
frag = reverse
When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal. Other choices are "always",
and "never". Usual boolean true/false can also be used.
The colormap entries can specify colors for the following slots:
plain - lines that appear in both old and new file (context)
meta - diff --git header and extended git diff headers
frag - @@ -n,m +l,k @@ lines (hunk header)
old - lines deleted from old file
new - lines added to new file
The following color names can be used:
normal, bold, dim, l, blink, reverse, reset,
black, red, green, yellow, blue, magenta, cyan,
white
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> Which just means that we should have some way to let people set their own
> colors.
At the source level it is easy to specify color and attribute
combinations (e.g. "bold|red") by having the preprocessor
concatenate string literals, but I was too lazy to allow that
from the configuration level. People might want to have that,
though.
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?
cache.h | 1 -
diff.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 80 insertions(+), 15 deletions(-)
diff --git a/cache.h b/cache.h
index efeafea..3502fee 100644
--- a/cache.h
+++ b/cache.h
@@ -181,7 +181,6 @@ extern int assume_unchanged;
extern int prefer_symlink_refs;
extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
-extern int diff_rename_limit_default;
extern int shared_repository;
extern const char *apply_default_whitespace;
diff --git a/diff.c b/diff.c
index 1db0285..33c8c57 100644
--- a/diff.c
+++ b/diff.c
@@ -13,17 +13,8 @@ #include "xdiff-interface.h"
static int use_size_cache;
-int diff_rename_limit_default = -1;
-
-int git_diff_config(const char *var, const char *value)
-{
- if (!strcmp(var, "diff.renamelimit")) {
- diff_rename_limit_default = git_config_int(var, value);
- return 0;
- }
-
- return git_default_config(var, value);
-}
+static int diff_rename_limit_default = -1;
+static int diff_use_color_default = 0;
enum color_diff {
DIFF_RESET = 0,
@@ -51,9 +42,6 @@ #define COLOR_MAGENTA "\033[35m"
#define COLOR_CYAN "\033[36m"
#define COLOR_WHITE "\033[37m"
-#define COLOR_CYANBG "\033[46m"
-#define COLOR_GRAYBG "\033[47m" // Good for xterm
-
static const char *diff_colors[] = {
[DIFF_RESET] = COLOR_RESET,
[DIFF_PLAIN] = COLOR_NORMAL,
@@ -63,6 +51,83 @@ static const char *diff_colors[] = {
[DIFF_FILE_NEW] = COLOR_GREEN,
};
+static int parse_diff_color_slot(const char *var, int ofs)
+{
+ if (!strcasecmp(var+ofs, "plain"))
+ return DIFF_PLAIN;
+ if (!strcasecmp(var+ofs, "meta"))
+ return DIFF_METAINFO;
+ if (!strcasecmp(var+ofs, "frag"))
+ return DIFF_FRAGINFO;
+ if (!strcasecmp(var+ofs, "old"))
+ return DIFF_FILE_OLD;
+ if (!strcasecmp(var+ofs, "new"))
+ return DIFF_FILE_NEW;
+ die("bad config variable '%s'", var);
+}
+
+static const char *parse_diff_color_value(const char *value, const char *var)
+{
+ if (!strcasecmp(value, "normal"))
+ return COLOR_NORMAL;
+ if (!strcasecmp(value, "bold"))
+ return COLOR_BOLD;
+ if (!strcasecmp(value, "dim"))
+ return COLOR_DIM;
+ if (!strcasecmp(value, "ul"))
+ return COLOR_UL;
+ if (!strcasecmp(value, "blink"))
+ return COLOR_BLINK;
+ if (!strcasecmp(value, "reverse"))
+ return COLOR_REVERSE;
+ if (!strcasecmp(value, "reset"))
+ return COLOR_RESET;
+ if (!strcasecmp(value, "black"))
+ return COLOR_BLACK;
+ if (!strcasecmp(value, "red"))
+ return COLOR_RED;
+ if (!strcasecmp(value, "green"))
+ return COLOR_GREEN;
+ if (!strcasecmp(value, "yellow"))
+ return COLOR_YELLOW;
+ if (!strcasecmp(value, "blue"))
+ return COLOR_BLUE;
+ if (!strcasecmp(value, "magenta"))
+ return COLOR_MAGENTA;
+ if (!strcasecmp(value, "cyan"))
+ return COLOR_CYAN;
+ if (!strcasecmp(value, "white"))
+ return COLOR_WHITE;
+ die("bad config value '%s' for variable '%s'", value, var);
+}
+
+int git_diff_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "diff.renamelimit")) {
+ diff_rename_limit_default = git_config_int(var, value);
+ return 0;
+ }
+ if (!strcmp(var, "diff.color")) {
+ if (!value)
+ diff_use_color_default = 1; /* bool */
+ else if (!strcasecmp(value, "auto"))
+ diff_use_color_default = isatty(1);
+ else if (!strcasecmp(value, "never"))
+ diff_use_color_default = 0;
+ else if (!strcasecmp(value, "always"))
+ diff_use_color_default = 1;
+ else
+ diff_use_color_default = git_config_bool(var, value);
+ return 0;
+ }
+ if (!strncmp(var, "diff.color.", 11)) {
+ int slot = parse_diff_color_slot(var, 11);
+ diff_colors[slot] = parse_diff_color_value(value, var);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
static char *quote_one(const char *str)
{
int needlen;
@@ -1362,6 +1427,7 @@ void diff_setup(struct diff_options *opt
options->change = diff_change;
options->add_remove = diff_addremove;
+ options->color_diff = diff_use_color_default;
}
int diff_setup_done(struct diff_options *options)
--
1.4.1.rc1.ga77b7
^ permalink raw reply related
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Martin Langhoff @ 2006-06-24 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git, junkio
In-Reply-To: <Pine.LNX.4.63.0606241145280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/24/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Thank you. This fixes the error.
Your welcome!
> HOWEVER, it does not fix the main problem: when I try to git-cvsimport,
> there is no index for that branch yet, since I used to git-cvsimport with
> the old cvsimport.
>
> Now, when cvsimport sees there is no index, it evidently assumes that the
> current state is an empty tree, which is *not* true.
>
> The effect is: the first commit removes all files from the tree which were
> not touched by the cvs commit. Bad.
I don't quite understand. No it shouldn't be the case -- it should
create the index using git-read-tree based on the tip of the branch.
Right after the call to tmpnam() the code looks like
$index{$branch} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$branch};
system("git-read-tree", $branch);
die "read-tree failed: $?\n" if $?;
> > This usage of tempfiles is open to a race condition
>
> 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.
It's worrying me too. Running some tests now...
martin
^ permalink raw reply
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Junio C Hamano @ 2006-06-24 10:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Martin Langhoff
In-Reply-To: <Pine.LNX.4.63.0606241145280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
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?
^ permalink raw reply
* PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-24 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyhv11ej.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> linux@horizon.com writes:
>
>> Well, I'm not sure it's worth this much trouble. Both of my PPC
>> implementations are smaller and faster than the current one,
>> so that's a pretty easy decision. The difference between them
>> is 2-3%, which is, I think, not enough to be worth the maintenance
>> burden of a run-time decision infrastructure. Just pick either one
>> and call it a day.
>>...
>> Not that numbers are bad, but I think that until there's a real
>> need for more than a single good-enough version per instruction set,
>> this is excessive.
>
> OK. I somehow got an impression that your two versions had
> quite different performance characteristics on G4 and G5 and
> there was a real choice. If they are between a few per-cent,
> then I agree it is not worth doing at all.
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.
The first line from ./test-sha1.sh is the time output to hash 100MB
and there should be bunch of OK output to verify the code hashes
things correctly for inputs of various sizes.
^ permalink raw reply
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Johannes Schindelin @ 2006-06-24 9:50 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio
In-Reply-To: <11511257501323-git-send-email-martin@catalyst.net.nz>
Hi,
On Sat, 24 Jun 2006, Martin Langhoff wrote:
> On 6/24/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > It seems that git-cvsimport makes a temporary file of size 0, which cannot
> > get mmap()ed, because it has size 0.
>
> This switch to tmpnam() avoids creating the tmpfile in the first place and
> streamlines the code. This handling of tmpfiles is slightly safer, but there
> is an inherent race condition.
Thank you. This fixes the error.
HOWEVER, it does not fix the main problem: when I try to git-cvsimport,
there is no index for that branch yet, since I used to git-cvsimport with
the old cvsimport.
Now, when cvsimport sees there is no index, it evidently assumes that the
current state is an empty tree, which is *not* true.
The effect is: the first commit removes all files from the tree which were
not touched by the cvs commit. Bad.
> This usage of tempfiles is open to a race condition
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.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-repack -- respect -q and be quiet
From: Martin Langhoff @ 2006-06-24 9:41 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
git-repack was passing the -q along to pack-objects but ignoring it
itself. Correct the oversight.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-repack.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 4fb3f26..eb75c8c 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -49,8 +49,9 @@ name=$(git-rev-list --objects --all $rev
if [ -z "$name" ]; then
echo Nothing new to pack.
else
- echo "Pack pack-$name created."
-
+ if test "$quiet" != '-q'; then
+ echo "Pack pack-$name created."
+ fi
mkdir -p "$PACKDIR" || exit
mv .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
--
1.4.1.rc1.g59c8
^ permalink raw reply related
* Re: A series file for git?
From: Junio C Hamano @ 2006-06-24 9:01 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <m1odwkyuf5.fsf_-_@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> I was using:
> git-rev-list $revargs | tac > list
> for sha1 in $(cat list); do git-cherry-pick -r $sha1 ; done
>...
> - Keeping patches in git and just remembering their sha1 is nice
> but it has the downside that it can be really easy to loose
> the sha1, and thus the patch. So some sort of history mechanism
> so you can get back to where you were would be nice.
Actually, the $revargs above is composed of your branch names
(e.g. "^master this-topic that-topic"), so as long as you do not
lose these branches they are protected.
>
> - This is a similar technique to topic branches. However in some
> of the more interesting cases a topic branch can't be used because
> you have a whole series of little changes, that allow depend on
> each other. So topic branches need not apply.
Sorry I fail to see why. A series of little changes that depend
on each other would be a string of pearls on a topic branch in
the simplest case, or a handful of topic branches that
occasionally merge with each other if you want to get fancier.
Cherry-picking from a DAG of the latter kind with your rev-list
piped to tac is no different than cherry-picking from a simple
straight line of the former kind, isn't it?
> - One of the places where we currently uses series files
> (patch-scripts && quilt), and heavy cherry picking is for patch
> aging. That is letting patches sit in a testing branch for
> a while so people have a chance to test and look at them.
I agree that patch aging and updating does not mesh well with
how git inherently works, as git regards commits immutable
objects. Even then, I use my "pu" branch (and topics that
hasn't merged to "next" but in "pu") pretty much as patch aging
area and I regularly do "git commit --amend" to update them.
This however is cumbersome with core git tools alone, and I
suspect is better done with StGIT.
> If we create a meta data branch with just the series file
> we can remove the risk of loosing things, as we always
> have a path back to the old history if we want it.
I am not sure about that. What does the series file contain,
and what other things the meta data branch contain? If you are
listing commit SHA1 in the series file, you _do_ have the risk
of losing things -- git-fsck-objects needs to look at such blob
object and consider that as the root of reachability chain; to
me that seems too specialized hack.
I have a feeling that I really should study how well StGIT does
things before talking about this further. It may suit your
needs perfectly. What do you feel is lacking in StGIT that you
need?
^ permalink raw reply
* Re: [PATCH 07/12] Git.pm: Better error handling
From: Junio C Hamano @ 2006-06-24 8:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060624023442.32751.28342.stgit@machine.or.cz>
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
--------------------------------
Other troubles I saw with the v4 series while compiling:
--------------------------------
usage.c:35: warning: initialization makes qualified function pointer from unqualified
usage.c:36: warning: initialization makes qualified function pointer from unqualified
I'd fix it with this
diff --git a/usage.c b/usage.c
index b781b00..52c2e96 100644
--- a/usage.c
+++ b/usage.c
@@ -12,19 +12,19 @@ static void report(const char *prefix, c
fputs("\n", stderr);
}
-void usage_builtin(const char *err)
+static NORETURN void usage_builtin(const char *err)
{
fprintf(stderr, "usage: %s\n", err);
exit(129);
}
-void die_builtin(const char *err, va_list params)
+static NORETURN void die_builtin(const char *err, va_list params)
{
report("fatal: ", err, params);
exit(128);
}
-void error_builtin(const char *err, va_list params)
+static void error_builtin(const char *err, va_list params)
{
report("error: ", err, params);
}
--------------------------------
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -DSHA1_HEADER='<openssl/sha.h>'
-DGIT_VERSION=\\\"1.4.1.rc1.gab0df\\\"" \
LIBS="libgit.a xdiff/lib.a -lz -lcrypto")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Do you need to pass LIBS, and if so maybe this is not a way
Makefile.PL expects it to be passed perhaps?
--------------------------------
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1
/usr/bin/perl Makefile.PL "PREFIX=/home/junio/git-test" "DEFINE=-O2 -Wall -Wdeclaration-after-statement -g -DSHA1_HEADER='<openssl/sha.h>' -DGIT_VERSION=\"1.4.1.rc1.gab0df\"" "LIBS=libgit.a xdiff/lib.a -lz -lcrypto"
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
make[1]: *** [Makefile] Error 1
--------------------------------
The latter is what Perl's build mechanism does so it is not
strictly your fault, but it nevertheless is irritating that we
have to say make clean twice.
^ permalink raw reply related
* Re: [PATCH 01/12] Introduce Git.pm (v4)
From: Junio C Hamano @ 2006-06-24 8:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vr71f5kzs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Just to let you know, I already have v3 in my tree which is
> merged in "pu". With the two fixes I sent you earlier I think
> it is in a good shape to be cooked in "next".
>
> I do not think I'd have trouble applying this new series (I
> would probably start from "master" to apply it and perhaps merge
> or --squash merge it onto pb/gitpm topic branch that has v3 with
> the two fixes I sent you separately) but we will see soon
> enough.
EEEEEEEEEK.
git-fmt-merge-msg failed and git-pull did not notice it and went
ahead to call git-merge with an empty log message. This screwed
up my tree rather big way.
The reason it failed? Well, it could not find Git.pm because
the changes to fmt-merge-msg was done for distros not for people
who install under their home directories.
Now, I am quite unhappy about the situation (and it is not your
fault). "git pull" is something almost everybody uses, and
having the series means they would need to make sure whereever
Git.pm is installed is on their PERL5LIB as things currently
stand.
In the case of git-merge-recursive.py, Fredrik does
sys.path.append('''@@GIT_PYTHON_PATH@@''')
and while running test this invalid path is overridden by having
PYTHONPATH environment variable. Since it is "append", the test
picks up the freshly built version, not the version from the
previous install (i.e. PYTHONPATH environment variable wins).
So you would probably want to have something like
use lib '@@GIT_PERL_PATH@@';
inside git-fmt-merge-msg.perl, which will be turned into
use lib '/home/junio/some/where/you/install/pm';
in git-fmt-merge-msg and things might start working.
... gitster mumbles something in his mouth, and in a puff of
smoke Merlyn appears and solves all our Perl problems ;-) ...
^ permalink raw reply
* From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001, [PATCH] Makefile: add framework to verify and bench sha1 implementations.
From: Junio C Hamano, Junio C Hamano @ 2006-06-24 7:59 UTC (permalink / raw)
To: git; +Cc: linux
In-Reply-To: <7vfyhv11ej.fsf@assigned-by-dhcp.cox.net>
With this, you can say
MOZILLA_SHA1=YesPlease make check-sha1
to see how fast your favorite SHA-1 implementation is and if it
fails with small to huge inputs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* As the maintainer, I do need people to see breakage before it
happens, without having access to all the platforms, hence
this.
Makefile | 6 ++++
test-sha1.c | 24 +++++++++++++++++
test-sha1.sh | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 113 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index e29e3fa..ea0044d 100644
--- a/Makefile
+++ b/Makefile
@@ -636,6 +636,12 @@ test-delta$X: test-delta.c diff-delta.o
test-dump-cache-tree$X: dump-cache-tree.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+test-sha1$X: test-sha1.o $(GITLIBS)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+
+check-sha1:: test-sha1$X
+ ./test-sha1.sh
+
check:
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
diff --git a/test-sha1.c b/test-sha1.c
new file mode 100644
index 0000000..2efc315
--- /dev/null
+++ b/test-sha1.c
@@ -0,0 +1,24 @@
+#include "cache.h"
+
+int main(int ac, char **av)
+{
+ SHA_CTX ctx;
+ unsigned char sha1[20];
+
+ SHA1_Init(&ctx);
+
+ while (1) {
+ ssize_t sz;
+ char buffer[8192];
+ sz = xread(0, buffer, sizeof(buffer));
+ if (sz == 0)
+ break;
+ if (sz < 0)
+ die("test-sha1: %s", strerror(errno));
+ SHA1_Update(&ctx, buffer, sz);
+ }
+ SHA1_Final(sha1, &ctx);
+ puts(sha1_to_hex(sha1));
+ exit(0);
+}
+
diff --git a/test-sha1.sh b/test-sha1.sh
new file mode 100755
index 0000000..01bbb57
--- /dev/null
+++ b/test-sha1.sh
@@ -0,0 +1,83 @@
+#!/bin/sh
+
+dd if=/dev/zero bs=1048576 count=100 2>/dev/null |
+/usr/bin/time ./test-sha1 >/dev/null
+
+while read expect cnt pfx
+do
+ case "$expect" in '#'*) continue ;; esac
+ actual=`
+ {
+ test -z "$pfx" || echo "$pfx"
+ dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
+ tr '[\0]' '[g]'
+ } | ./test-sha1
+ `
+ if test "$expect" = "$actual"
+ then
+ echo "OK: $expect $cnt $pfx"
+ else
+ echo >&2 "OOPS: $cnt"
+ echo >&2 "expect: $expect"
+ echo >&2 "actual: $actual"
+ exit 1
+ fi
+done <<EOF
+da39a3ee5e6b4b0d3255bfef95601890afd80709 0
+3f786850e387550fdab836ed7e6dc881de23001b 0 a
+5277cbb45a15902137d332d97e89cf8136545485 0 ab
+03cfd743661f07975fa2f1220c5194cbaff48451 0 abc
+3330b4373640f9e4604991e73c7e86bfd8da2dc3 0 abcd
+ec11312386ad561674f724b8cca7cf1796e26d1d 0 abcde
+bdc37c074ec4ee6050d68bc133c6b912f36474df 0 abcdef
+69bca99b923859f2dc486b55b87f49689b7358c7 0 abcdefg
+e414af7161c9554089f4106d6f1797ef14a73666 0 abcdefgh
+0707f2970043f9f7c22029482db27733deaec029 0 abcdefghi
+a4dd8aa74a5636728fe52451636e2e17726033aa 1
+9986b45e2f4d7086372533bb6953a8652fa3644a 1 frotz
+23d8d4f788e8526b4877548a32577543cbaaf51f 10
+8cd23f822ab44c7f481b8c92d591f6d1fcad431c 10 frotz
+f3b5604a4e604899c1233edb3bf1cc0ede4d8c32 512
+b095bd837a371593048136e429e9ac4b476e1bb3 512 frotz
+08fa81d6190948de5ccca3966340cc48c10cceac 1200 xyzzy
+e33a291f42c30a159733dd98b8b3e4ff34158ca0 4090 4G
+#a3bf783bc20caa958f6cb24dd140a7b21984838d 9999 nitfol
+EOF
+
+exit
+
+# generating test vectors
+# inputs are number of megabytes followed by some random string to prefix.
+
+while read cnt pfx
+do
+ actual=`
+ {
+ test -z "$pfx" || echo "$pfx"
+ dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
+ tr '[\0]' '[g]'
+ } | sha1sum |
+ sed -e 's/ .*//'
+ `
+ echo "$actual $cnt $pfx"
+done <<EOF
+0
+0 a
+0 ab
+0 abc
+0 abcd
+0 abcde
+0 abcdef
+0 abcdefg
+0 abcdefgh
+0 abcdefghi
+1
+1 frotz
+10
+10 frotz
+512
+512 frotz
+1200 xyzzy
+4090 4G
+9999 nitfol
+EOF
--
1.4.1.rc1.g0fca
^ permalink raw reply related
* Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.
From: Junio C Hamano @ 2006-06-24 7:09 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060622110941.GA32261@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> > * I wanted to raise my confidence level in the new rebase --merge
>> > code, so I did a little exercise which resulted in finding this
>> > buglet.
>> >...
>> > So the exercise went like this:
>> >...
>> > With this fix, the above works beautifully. I am reasonably
>> > happy with this shiny new toy. Good job, Eric! and thanks.
>
> :) Thanks for the extra QA and fix.
Another thing I noticed is while rebasing onto the mainline that
has accepted a few of the patches from the topic. The original
rebase with "git am -3" logic notices that the patch has already
been applied and drops that commit, which is rather nice, but
the new "rebase --merge" logic barfs when git-commit notices
there is nothing to commit. I think you could before calling
git-commit check if the git-merge-$strategy gave you the tree
identical to the HEAD tree, and simply skip it (maybe after
giving the user "patch already applied"message).
^ permalink raw reply
* Re: x86 asm SHA1 (draft)
From: Junio C Hamano @ 2006-06-24 7:03 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060624012202.4822.qmail@science.horizon.com>
linux@horizon.com writes:
> Well, I'm not sure it's worth this much trouble. Both of my PPC
> implementations are smaller and faster than the current one,
> so that's a pretty easy decision. The difference between them
> is 2-3%, which is, I think, not enough to be worth the maintenance
> burden of a run-time decision infrastructure. Just pick either one
> and call it a day.
>...
> Not that numbers are bad, but I think that until there's a real
> need for more than a single good-enough version per instruction set,
> this is excessive.
OK. I somehow got an impression that your two versions had
quite different performance characteristics on G4 and G5 and
there was a real choice. If they are between a few per-cent,
then I agree it is not worth doing at all.
^ permalink raw reply
* Re: [PATCH] cvsimport - streamline temp index file creation and avoid creating empty tmpfiles
From: Junio C Hamano @ 2006-06-24 6:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Johannes.Schindelin
In-Reply-To: <11511257501323-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> On 6/24/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> It seems that git-cvsimport makes a temporary file of size 0, which cannot
>> get mmap()ed, because it has size 0.
>
> This switch to tmpnam() avoids creating the tmpfile in the first place and
> streamlines the code. This handling of tmpfiles is slightly safer, but there
> is an inherent race condition.
>
> ---
> NOTE: (a) I cannot reproduce the problem and (b) this is only lightly tested,
> if trivial.
Thanks both.
I'd take this to "next" after I hear from somebody, most likely
Johannes, who had trouble with the code earlier that the problem
is fixed.
^ permalink raw reply
* Re: [PATCH 2/5] Rework diff options
From: Junio C Hamano @ 2006-06-24 6:55 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060624005252.c694e421.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> diff --git a/builtin-diff.c b/builtin-diff.c
> index 99a2f76..372894a 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -56,15 +56,15 @@ static int builtin_diff_files(struct rev
> 3 < revs->max_count)
> usage(builtin_diff_usage);
> if (revs->max_count < 0 &&
> - (revs->diffopt.output_format == DIFF_FORMAT_PATCH))
> + (revs->diffopt.output_fmt & OUTPUT_FMT_PATCH))
> revs->combine_merges = revs->dense_combined_merges = 1;
> /*
> * Backward compatibility wart - "diff-files -s" used to
> * defeat the common diff option "-s" which asked for
> - * DIFF_FORMAT_NO_OUTPUT.
> + * OUTPUT_FMT_NONE
> */
> - if (revs->diffopt.output_format == DIFF_FORMAT_NO_OUTPUT)
> - revs->diffopt.output_format = DIFF_FORMAT_RAW;
> + if (revs->diffopt.output_fmt & OUTPUT_FMT_NONE)
> + revs->diffopt.output_fmt = OUTPUT_FMT_RAW;
> return run_diff_files(revs, silent);
> }
We do not have to remove this now, but I think we can remove
this "backward compatibility wart" sometime in the next round;
Cogito has been fixed not to use this.
> @@ -110,7 +110,7 @@ static int builtin_diff_b_f(struct rev_i
> while (1 < argc) {
> const char *arg = argv[1];
> if (!strcmp(arg, "--raw"))
> - revs->diffopt.output_format = DIFF_FORMAT_RAW;
> + revs->diffopt.output_fmt |= OUTPUT_FMT_RAW;
> else
> usage(builtin_diff_usage);
> argv++; argc--;
I see later in the series you taught low-level diff_opt_parse
about --raw switch, which is good.
> diff --git a/builtin-log.c b/builtin-log.c
> index 5a8a50b..e4a6385 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -26,8 +26,8 @@ static int cmd_log_wc(int argc, const ch
> if (rev->always_show_header) {
> if (rev->diffopt.pickaxe || rev->diffopt.filter) {
> rev->always_show_header = 0;
> - if (rev->diffopt.output_format == DIFF_FORMAT_RAW)
> - rev->diffopt.output_format = DIFF_FORMAT_NO_OUTPUT;
> + if (rev->diffopt.output_fmt & OUTPUT_FMT_RAW)
> + rev->diffopt.output_fmt |= OUTPUT_FMT_NONE;
> }
> }
The original code is saying "For git-log command (i.e. when
always-show-header is on), if the command line did not override
but ended up asking for diff only because it wanted to do -S or
--diff-filter, do not show any diff" which is quite an opaque
logic.
> diff --git a/combine-diff.c b/combine-diff.c
> index 64b20cc..d0d8d01 100644
> --- a/combine-diff.c
> +++ b/combine-diff.c
> @@ -878,13 +867,13 @@ void diff_tree_combined(const unsigned c
> num_paths++;
> }
> if (num_paths) {
> - if (opt->with_raw) {
> - int saved_format = opt->output_format;
> - opt->output_format = DIFF_FORMAT_RAW;
> + if (opt->output_fmt & OUTPUT_FMT_RAW) {
> + int saved_fmt = opt->output_fmt;
> + opt->output_fmt |= OUTPUT_FMT_RAW;
> for (p = paths; p; p = p->next) {
> show_combined_diff(p, num_parent, dense, rev);
> }
> - opt->output_format = saved_format;
> + opt->output_fmt = saved_fmt;
> putchar(opt->line_termination);
> }
> for (p = paths; p; p = p->next) {
The code needs to run show_combined_diff twice, once for raw
output and another for normal output, since the processing
needed to be done in show_combined_diff are quite different
between the case where you emit raw diff (in which case you do
not combine at the hunk level) and normal diff (in which case
you do). Since your modified show_combined_diff checks FMT_RAW
first, I suspect it would not make any difference if it is ORing
OUTPUT_FMT_RAW into output_fmt or assignment. In fact, since
the bit is already on when the if () statement is taken, I think
you can lose the whole saved_fmt business, and just say
something like this here:
if (opt->output_fmt & OUTPUT_FMT_RAW) {
for (p = paths; p; p = p->next) {
show_combined_diff(p, num_parent, dense, rev);
}
putchar(opt->line_termination);
}
But I think the other side needs to drop OUTPUT_FMT_RAW bit,
since around ll. 817 in combine-diff.c you show_raw_diff() if
OUTPUT_FMT_RAW bit is on regardless of the OUTPUT_FMT_PATCH bit.
> diff --git a/diff.c b/diff.c
> index 1db0285..6eb7db0 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -203,7 +203,7 @@ static void emit_rewrite_diff(const char
> static int fill_mmfile(mmfile_t *mf, struct diff_filespec *one)
> {
> if (!DIFF_FILE_VALID(one)) {
> - mf->ptr = ""; /* does not matter */
> + mf->ptr = (char *)""; /* does not matter */
> mf->size = 0;
> return 0;
> }
> @@ -395,7 +395,7 @@ static void show_stats(struct diffstat_t
> }
>
> for (i = 0; i < data->nr; i++) {
> - char *prefix = "";
> + const char *prefix = "";
> char *name = data->files[i]->name;
> int added = data->files[i]->added;
> int deleted = data->files[i]->deleted;
> @@ -917,7 +917,7 @@ int diff_populate_filespec(struct diff_f
> err_empty:
> err = -1;
> empty:
> - s->data = "";
> + s->data = (char *)"";
> s->size = 0;
> return err;
> }
> @@ -1408,7 +1411,7 @@ int diff_setup_done(struct diff_options
> return 0;
> }
>
> -int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val)
> +static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val)
> {
> char c, *eq;
> int len;
> @@ -1720,16 +1722,12 @@ static void diff_flush_raw(struct diff_f
> free((void*)path_two);
> }
>
> -static void diff_flush_name(struct diff_filepair *p,
> - int inter_name_termination,
> - int line_termination)
> +static void diff_flush_name(struct diff_filepair *p, int line_termination)
> {
> char *path = p->two->path;
>
> if (line_termination)
> path = quote_one(p->two->path);
> - else
> - path = p->two->path;
> printf("%s%c", path, line_termination);
> if (p->two->path != path)
> free(path);
These are all good changes but I would have liked to see them as
a separate series.
> @@ -1371,23 +1371,26 @@ int diff_setup_done(struct diff_options
> (0 <= options->rename_limit && !options->detect_rename))
> return -1;
>
> + if (options->output_fmt & OUTPUT_FMT_NONE)
> + options->output_fmt = 0;
> +
> + if (options->output_fmt & (OUTPUT_FMT_NAME |
> + OUTPUT_FMT_CHECKDIFF |
> + OUTPUT_FMT_NONE))
> + options->output_fmt &= ~(OUTPUT_FMT_RAW |
> + OUTPUT_FMT_DIFFSTAT |
> + OUTPUT_FMT_SUMMARY |
> + OUTPUT_FMT_PATCH);
> +
Maybe doing the same for --name-status? I wonder if the --name,
--name-status and --check should be mutually exclusive. What
happens when you specify more than one of them?
> +/* Same as output_fmt = 0 but we know that -s flag was given
> + * and we should not give default value to output_fmt.
> + */
> +#define OUTPUT_FMT_NONE 0x0080
This is a very good comment to tell the reader what is going on.
I appreciate it.
> diff --git a/revision.c b/revision.c
> index b963f2a..4ad2272 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -852,8 +852,8 @@ int setup_revisions(int argc, const char
> if (revs->combine_merges) {
> revs->ignore_merges = 0;
> if (revs->dense_combined_merges &&
> - (revs->diffopt.output_format != DIFF_FORMAT_DIFFSTAT))
> - revs->diffopt.output_format = DIFF_FORMAT_PATCH;
> + !(revs->diffopt.output_fmt & OUTPUT_FMT_DIFFSTAT))
> + revs->diffopt.output_fmt |= OUTPUT_FMT_PATCH;
> }
> revs->diffopt.abbrev = revs->abbrev;
> diff_setup_done(&revs->diffopt);
This tells it to default to patch format unless we are asked to
do diffstat only, in which case we just show stat without patch.
The new logic seems to be fishy.
Whew, now it's quite a lot of changes. How to proceed from
here? My rather selfish preference is:
- "git-merge not add -p when asking for --summary --stat" is an
obvious fix that is independently applicable to "master", so
I took it already.
- could I ask you to redo a patch to do only the clean-up part
first, so that I can accept it for either "next" or "master".
- Then after I take the clean-up, could you rebase four
remainder patches ("Rework diff options" to "Add --patch
option for diff-*") on the result? The patches this round
are already split quite well in that the first one does the
enum to bit conversion and the latter three cleans things up
(all of which I like a lot). As Johannes suggested, it might
be easier to review if they reused the same preprocessor
symbols instead of renaming them. I'd take them for "next".
^ 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