* Re: * [BUG] "git clean" does not pay attention to its parameters
From: Junio C Hamano @ 2007-12-06 2:14 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: Nanako Shiraishi, git
In-Reply-To: <20071205152816.GA21347@mediacenter.austin.rr.com>
Shawn Bohrer <shawn.bohrer@gmail.com> writes:
> Before the rewrite in C git clean would refuse to remove a directory if
> you said:
>
> git clean dir
>
> without using the -d parameter. Per your suggestion this check causes
> git clean to remove the directory anyway since you explicitly asked it
> to.
Thanks for reminding me of that issue.
^ permalink raw reply
* [PATCH 2/3] git config --get-colorbool
From: Junio C Hamano @ 2007-12-06 2:05 UTC (permalink / raw)
To: git
In-Reply-To: <1196906706-11170-1-git-send-email-gitster@pobox.com>
This adds an option to help scripts find out color settings from
the configuration file.
git config --get-colorbool color.diff
inspects color.diff variable, and exits with status 0 (i.e. success) if
color is to be used. It exits with status 1 otherwise.
If a script wants "true"/"false" answer to the standard output of the
command, it can pass an additional boolean parameter to its command
line, telling if its standard output is a terminal, like this:
git config --get-colorbool color.diff true
When called like this, the command outputs "true" to its standard output
if color is to be used (i.e. "color.diff" says "always", "auto", or
"true"), and "false" otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-config.txt | 10 ++++++++++
builtin-branch.c | 2 +-
builtin-config.c | 41 ++++++++++++++++++++++++++++++++++++++++-
color.c | 6 ++++--
color.h | 2 +-
diff.c | 2 +-
wt-status.c | 2 +-
7 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 7640450..98509b4 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -21,6 +21,7 @@ SYNOPSIS
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
'git-config' [<file-option>] --get-color name [default]
+'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
DESCRIPTION
-----------
@@ -135,6 +136,15 @@ See also <<FILES>>.
output without getting confused e.g. by values that
contain line breaks.
+--get-colorbool name [stdout-is-tty]::
+
+ Find the color setting for `name` (e.g. `color.diff`) and output
+ "true" or "false". `stdout-is-tty` should be either "true" or
+ "false", and is taken into account when configuration says
+ "auto". If `stdout-is-tty` is missing, then checks the standard
+ output of the command itself, and exits with status 0 if color
+ is to be used, or exits with status 1 otherwise.
+
--get-color name default::
Find the color configured for `name` (e.g. `color.diff.new`) and
diff --git a/builtin-branch.c b/builtin-branch.c
index c64768b..089cae5 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -65,7 +65,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
static int git_branch_config(const char *var, const char *value)
{
if (!strcmp(var, "color.branch")) {
- branch_use_color = git_config_colorbool(var, value);
+ branch_use_color = git_config_colorbool(var, value, -1);
return 0;
}
if (!prefixcmp(var, "color.branch.")) {
diff --git a/builtin-config.c b/builtin-config.c
index 6175dc3..d10b03f 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -3,7 +3,7 @@
#include "color.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color var [default]";
+"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color var [default] | --get-colorbool name [stdout-is-tty]";
static char *key;
static regex_t *key_regexp;
@@ -208,6 +208,43 @@ static int get_color(int argc, const char **argv)
return 0;
}
+static int stdout_is_tty;
+static int get_colorbool_found;
+static int git_get_colorbool_config(const char *var, const char *value)
+{
+ if (!strcmp(var, get_color_slot))
+ get_colorbool_found =
+ git_config_colorbool(var, value, stdout_is_tty);
+ return 0;
+}
+
+static int get_colorbool(int argc, const char **argv)
+{
+ /*
+ * git config --get-colorbool <slot> [<stdout-is-tty>]
+ *
+ * returns "true" or "false" depending on how <slot>
+ * is configured.
+ */
+
+ if (argc == 2)
+ stdout_is_tty = git_config_bool("command line", argv[1]);
+ else if (argc == 1)
+ stdout_is_tty = isatty(1);
+ else
+ usage(git_config_set_usage);
+ get_colorbool_found = 0;
+ get_color_slot = argv[0];
+ git_config(git_get_colorbool_config);
+
+ if (argc == 1) {
+ return get_colorbool_found ? 0 : 1;
+ } else {
+ printf("%s\n", get_colorbool_found ? "true" : "false");
+ return 0;
+ }
+}
+
int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
@@ -283,6 +320,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
return 0;
} else if (!strcmp(argv[1], "--get-color")) {
return get_color(argc-2, argv+2);
+ } else if (!strcmp(argv[1], "--get-colorbool")) {
+ return get_colorbool(argc-2, argv+2);
} else
break;
argc--;
diff --git a/color.c b/color.c
index 97cfbda..7bd424a 100644
--- a/color.c
+++ b/color.c
@@ -116,7 +116,7 @@ bad:
die("bad config value '%s' for variable '%s'", value, var);
}
-int git_config_colorbool(const char *var, const char *value)
+int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
{
if (value) {
if (!strcasecmp(value, "never"))
@@ -133,7 +133,9 @@ int git_config_colorbool(const char *var, const char *value)
/* any normal truth value defaults to 'auto' */
auto_color:
- if (isatty(1) || (pager_in_use && pager_use_color)) {
+ if (stdout_is_tty < 0)
+ stdout_is_tty = isatty(1);
+ if (stdout_is_tty || (pager_in_use && pager_use_color)) {
char *term = getenv("TERM");
if (term && strcmp(term, "dumb"))
return 1;
diff --git a/color.h b/color.h
index 6809800..ff63513 100644
--- a/color.h
+++ b/color.h
@@ -4,7 +4,7 @@
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
#define COLOR_MAXLEN 24
-int git_config_colorbool(const char *var, const char *value);
+int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
diff --git a/diff.c b/diff.c
index 6b54959..be6cf68 100644
--- a/diff.c
+++ b/diff.c
@@ -146,7 +146,7 @@ int git_diff_ui_config(const char *var, const char *value)
return 0;
}
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
- diff_use_color_default = git_config_colorbool(var, value);
+ diff_use_color_default = git_config_colorbool(var, value, -1);
return 0;
}
if (!strcmp(var, "diff.renames")) {
diff --git a/wt-status.c b/wt-status.c
index d35386d..02dbb75 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -391,7 +391,7 @@ void wt_status_print(struct wt_status *s)
int git_status_config(const char *k, const char *v)
{
if (!strcmp(k, "status.color") || !strcmp(k, "color.status")) {
- wt_status_use_color = git_config_colorbool(k, v);
+ wt_status_use_color = git_config_colorbool(k, v, -1);
return 0;
}
if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
--
1.5.3.7-2132-gbd1cf
^ permalink raw reply related
* [PATCH 3/3] Color support for "git-add -i"
From: Junio C Hamano @ 2007-12-06 2:05 UTC (permalink / raw)
To: git
In-Reply-To: <1196906706-11170-2-git-send-email-gitster@pobox.com>
This is mostly lifted from earlier series by Dan Zwell, but updated to
use "git config --get-color" and "git config --get-colorbool" to make it
simpler and more consistent with commands written in C.
A new configuration color.interactive variable is like color.diff and
color.status, and controls if "git-add -i" uses color.
A set of configuration variables, color.interactive.<slot>, are used to
define what color is used for the prompt, header, and help text.
For perl scripts, Git.pm provides $repo->get_color() method, which takes
the slot name and the default color, and returns the terminal escape
sequence to color the output text. $repo->get_colorbool() method can be
used to check if color is set to be used for a given operation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 12 +++++
git-add--interactive.perl | 119 +++++++++++++++++++++++++++++++++++++--------
perl/Git.pm | 35 +++++++++++++
3 files changed, 146 insertions(+), 20 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0e45ec5..736fcd7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -391,6 +391,18 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When set to `always`, always use colors in `git add --interactive`.
+ When false (or `never`), never. When set to `true` or `auto`, use
+ colors only when the output is to the terminal. Defaults to false.
+
+color.interactive.<slot>::
+ Use customized color for `git add --interactive`
+ output. `<slot>` may be `prompt`, `header`, or `help`, for
+ three distinct types of normal output from interactive
+ programs. The values of these variables may be specified as
+ in color.branch.<slot>.
+
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 335c2c6..1019a72 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,55 @@
#!/usr/bin/perl -w
use strict;
+use Git;
+
+# Prompt colors:
+my ($prompt_color, $header_color, $help_color, $normal_color);
+# Diff colors:
+my ($new_color, $old_color, $fraginfo_color, $metainfo_color, $whitespace_color);
+
+my ($use_color, $diff_use_color);
+my $repo = Git->repository();
+
+$use_color = $repo->get_colorbool('color.interactive');
+
+if ($use_color) {
+ # Set interactive colors:
+
+ # Grab the 3 main colors in git color string format, with sane
+ # (visible) defaults:
+ $prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
+ $header_color = $repo->get_color("color.interactive.header", "bold");
+ $help_color = $repo->get_color("color.interactive.help", "red bold");
+ $normal_color = $repo->get_color("", "reset");
+
+ # Do we also set diff colors?
+ $diff_use_color = $repo->get_colorbool('color.diff');
+ if ($diff_use_color) {
+ $new_color = $repo->get_color("color.diff.new", "green");
+ $old_color = $repo->get_color("color.diff.old", "red");
+ $fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
+ $metainfo_color = $repo->get_color("color.diff.meta", "bold");
+ $whitespace_color = $repo->get_color("color.diff.whitespace", "normal red");
+ }
+}
+
+sub colored {
+ my $color = shift;
+ my $string = join("", @_);
+
+ if ($use_color) {
+ # Put a color code at the beginning of each line, a reset at the end
+ # color after newlines that are not at the end of the string
+ $string =~ s/(\n+)(.)/$1$color$2/g;
+ # reset before newlines
+ $string =~ s/(\n+)/$normal_color$1/g;
+ # codes at beginning and end (if necessary):
+ $string =~ s/^/$color/;
+ $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
+ }
+ return $string;
+}
# command line options
my $patch_mode;
@@ -246,10 +295,20 @@ sub is_valid_prefix {
sub highlight_prefix {
my $prefix = shift;
my $remainder = shift;
- return $remainder unless defined $prefix;
- return is_valid_prefix($prefix) ?
- "[$prefix]$remainder" :
- "$prefix$remainder";
+
+ if (!defined $prefix) {
+ return $remainder;
+ }
+
+ if (!is_valid_prefix($prefix)) {
+ return "$prefix$remainder";
+ }
+
+ if (!$use_color) {
+ return "[$prefix]$remainder";
+ }
+
+ return "$prompt_color$prefix$normal_color$remainder";
}
sub list_and_choose {
@@ -266,7 +325,7 @@ sub list_and_choose {
if (!$opts->{LIST_FLAT}) {
print " ";
}
- print "$opts->{HEADER}\n";
+ print colored $header_color, "$opts->{HEADER}\n";
}
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
@@ -304,7 +363,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print colored $prompt_color, $opts->{PROMPT};
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -371,7 +430,7 @@ sub list_and_choose {
}
sub singleton_prompt_help_cmd {
- print <<\EOF ;
+ print colored $help_color, <<\EOF ;
Prompt help:
1 - select a numbered item
foo - select item based on unique prefix
@@ -380,7 +439,7 @@ EOF
}
sub prompt_help_cmd {
- print <<\EOF ;
+ print colored $help_color, <<\EOF ;
Prompt help:
1 - select a single item
3-5 - select a range of items
@@ -477,6 +536,31 @@ sub parse_diff {
return @hunk;
}
+sub colored_diff_hunk {
+ my ($text) = @_;
+ # return the text, so that it can be passed to print()
+ my @ret;
+ for (@$text) {
+ if (!$diff_use_color) {
+ push @ret, $_;
+ next;
+ }
+
+ if (/^\+/) {
+ push @ret, colored($new_color, $_);
+ } elsif (/^\-/) {
+ push @ret, colored($old_color, $_);
+ } elsif (/^\@/) {
+ push @ret, colored($fraginfo_color, $_);
+ } elsif (/^ /) {
+ push @ret, colored($normal_color, $_);
+ } else {
+ push @ret, colored($metainfo_color, $_);
+ }
+ }
+ return @ret;
+}
+
sub hunk_splittable {
my ($text) = @_;
@@ -671,7 +755,7 @@ sub coalesce_overlapping_hunks {
}
sub help_patch_cmd {
- print <<\EOF ;
+ print colored $help_color, <<\EOF ;
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
@@ -710,9 +794,7 @@ sub patch_update_file {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
- for (@{$head->{TEXT}}) {
- print;
- }
+ print colored_diff_hunk($head->{TEXT});
$num = scalar @hunk;
$ix = 0;
@@ -754,10 +836,8 @@ sub patch_update_file {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
- for (@{$hunk[$ix]{TEXT}}) {
- print;
- }
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored_diff_hunk($hunk[$ix]{TEXT});
+ print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -811,7 +891,7 @@ sub patch_update_file {
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT});
if (1 < @split) {
- print "Split into ",
+ print colored $header_color, "Split into ",
scalar(@split), " hunks.\n";
}
splice(@hunk, $ix, 1,
@@ -894,8 +974,7 @@ sub diff_cmd {
HEADER => $status_head, },
@mods);
return if (!@them);
- system(qw(git diff-index -p --cached HEAD --),
- map { $_->{VALUE} } @them);
+ system(qw(git diff -p --cached HEAD --), map { $_->{VALUE} } @them);
}
sub quit_cmd {
@@ -904,7 +983,7 @@ sub quit_cmd {
}
sub help_cmd {
- print <<\EOF ;
+ print colored $help_color, <<\EOF ;
status - show paths with changes
update - add working tree state to the staged set of changes
revert - revert staged set of changes back to the HEAD version
diff --git a/perl/Git.pm b/perl/Git.pm
index 7468460..a2812ea 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -581,6 +581,41 @@ sub config_int {
};
}
+=item get_colorbool ( NAME )
+
+Finds if color should be used for NAMEd operation from the configuration,
+and returns boolean (true for "use color", false for "do not use color").
+
+=cut
+
+sub get_colorbool {
+ my ($self, $var) = @_;
+ my $stdout_to_tty = (-t STDOUT) ? "true" : "false";
+ my $use_color = $self->command_oneline('config', '--get-colorbool',
+ $var, $stdout_to_tty);
+ return ($use_color eq 'true');
+}
+
+=item get_color ( SLOT, COLOR )
+
+Finds color for SLOT from the configuration, while defaulting to COLOR,
+and returns the ANSI color escape sequence:
+
+ print $repo->get_color("color.interactive.prompt", "underline blue white");
+ print "some text";
+ print $repo->get_color("", "normal");
+
+=cut
+
+sub get_color {
+ my ($self, $slot, $default) = @_;
+ my $color = $self->command_oneline('config', '--get-color', $slot, $default);
+ if (!defined $color) {
+ $color = "";
+ }
+ return $color;
+}
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
--
1.5.3.7-2132-gbd1cf
^ permalink raw reply related
* Re: Git and GCC
From: David Miller @ 2007-12-06 2:28 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712051108s216d3331t8061ef45b9aa324a@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 14:08:41 -0500
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggressive --prune. Two hours
> later, it finished.
> The final size after this is 1.5 gig for all of the history of gcc for
> just trunk.
>
> dberlin@home:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> total 1568899
> -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> -r--r--r-- 1 dberlin dberlin 19008488 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
>
> This is 3x bigger than hg *and* hg doesn't require me to waste my life
> repacking every so often.
> The hg operations run roughly as fast as the git ones
>
> I'm sure there are magic options, magic command lines, etc, i could
> use to make it smaller.
>
> I'm sure if i spent the next few weeks fucking around with git, it may
> even be usable!
>
> But given that git is harder to use, requires manual repacking to get
> any kind of sane space usage, and is 3x bigger anyway, i don't see any
> advantage to continuing to experiment with git and gcc.
I would really appreciate it if you would share experiences
like this with the GIT community, who have been now CC:'d.
That's the only way this situation is going to improve.
When you don't CC: the people who can fix the problem, I can only
speculate that perhaps at least subconsciously you don't care if
the situation improves or not.
The OpenSolaris folks behaved similarly, and that really ticked me
off.
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 2:41 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.182815.249974508.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 14:08:41 -0500
>
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-svn import was done using repacks every 1000 revisions.
> > After it finished, I used git-gc --aggressive --prune. Two hours
> > later, it finished.
> > The final size after this is 1.5 gig for all of the history of gcc for
> > just trunk.
> >
> > dberlin@home:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> > total 1568899
> > -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> > -r--r--r-- 1 dberlin dberlin 19008488 2007-12-05 14:01
> > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
> >
> > This is 3x bigger than hg *and* hg doesn't require me to waste my life
> > repacking every so often.
> > The hg operations run roughly as fast as the git ones
> >
> > I'm sure there are magic options, magic command lines, etc, i could
> > use to make it smaller.
> >
> > I'm sure if i spent the next few weeks fucking around with git, it may
> > even be usable!
> >
> > But given that git is harder to use, requires manual repacking to get
> > any kind of sane space usage, and is 3x bigger anyway, i don't see any
> > advantage to continuing to experiment with git and gcc.
>
> I would really appreciate it if you would share experiences
> like this with the GIT community, who have been now CC:'d.
>
> That's the only way this situation is going to improve.
>
> When you don't CC: the people who can fix the problem, I can only
> speculate that perhaps at least subconsciously you don't care if
> the situation improves or not.
>
I didn't cc the git community for three reasons
1. It's not the nicest message in the world, and thus, more likely to
get bad responses than constructive ones.
2. Based on the level of usability, I simply assume it is too young
for regular developers to use. At least, I hope this is the case.
3. People i know have had bad experiences talking usability issues
with the git community in the past. I am not likely to fare any
better, so I would rather have someone who is involved with both our
community and theirs, raise these issues, rather than a complete
newcomer.
But hey, whatever floats your boat :)
It is true I gave up quickly, but this is mainly because i don't like
to fight with my tools.
I am quite fine with a distributed workflow, I now use 8 or so gcc
branches in mercurial (auto synced from svn) and merge a lot between
them. I wanted to see if git would sanely let me manage the commits
back to svn. After fighting with it, i gave up and just wrote a
python extension to hg that lets me commit non-svn changesets back to
svn directly from hg.
--Dan
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 2:52 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712051841o71ab773ft6dd0714ebc355dd5@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 21:41:19 -0500
> It is true I gave up quickly, but this is mainly because i don't like
> to fight with my tools.
> I am quite fine with a distributed workflow, I now use 8 or so gcc
> branches in mercurial (auto synced from svn) and merge a lot between
> them. I wanted to see if git would sanely let me manage the commits
> back to svn. After fighting with it, i gave up and just wrote a
> python extension to hg that lets me commit non-svn changesets back to
> svn directly from hg.
I find it ironic that you were even willing to write tools to
facilitate your hg based gcc workflow. That really shows what your
thinking is on this matter, in that you're willing to put effort
towards making hg work better for you but you're not willing to expend
that level of effort to see if git can do so as well.
This is what really eats me from the inside about your dissatisfaction
with git. Your analysis seems to be a self-fullfilling prophecy, and
that's totally unfair to both hg and git.
^ permalink raw reply
* Re: * [BUG] "git clean" does not pay attention to its parameters
From: Jeff King @ 2007-12-06 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Shawn Bohrer, git
In-Reply-To: <7veje1zibm.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 04, 2007 at 11:55:41PM -0800, Junio C Hamano wrote:
> [PATCH] git-clean: Honor pathspec.
>
> git-clean "*.rej" should attempt to look at only paths that match
> pattern "*.rej", but rewrite to C broke it.
And here is a test that fails without your patch (probably the commit
message should say "fixed in XX" once the commit id is known, or it
should be squashed in with your patch).
-- >8 --
t7300: add test for clean with wildcard pathspec
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7300-clean.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index f013c17..dfd1188 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -126,6 +126,20 @@ test_expect_success 'git-clean symbolic link' '
'
+test_expect_success 'git-clean with wildcard' '
+
+ touch a.clean b.clean other.c &&
+ git-clean "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -f a.clean &&
+ test ! -f b.clean &&
+ test -f other.c
+
+'
+
test_expect_success 'git-clean -n' '
mkdir -p build docs &&
--
1.5.3.7.2099.gd6d7-dirty
^ permalink raw reply related
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 3:47 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.185203.262588544.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> > I am quite fine with a distributed workflow, I now use 8 or so gcc
> > branches in mercurial (auto synced from svn) and merge a lot between
> > them. I wanted to see if git would sanely let me manage the commits
> > back to svn. After fighting with it, i gave up and just wrote a
> > python extension to hg that lets me commit non-svn changesets back to
> > svn directly from hg.
>
> I find it ironic that you were even willing to write tools to
> facilitate your hg based gcc workflow.
Why?
> That really shows what your
> thinking is on this matter, in that you're willing to put effort
> towards making hg work better for you but you're not willing to expend
> that level of effort to see if git can do so as well.
See, now you claim to know my thinking.
I went back to hg because the GIT's space usage wasn't even in the
ballpark, i couldn't get git-svn rebase to update the revs after the
initial import (even though i had properly used a rewriteRoot).
The size is clearly not just svn data, it's in the git pack itself.
I spent a long time working on SVN to reduce it's space usage (repo
side and cleaning up the client side and giving a path to svn devs to
reduce it further), as well as ui issues, and I really don't feel like
having to do the same for GIT.
I'm tired of having to spend a large amount of effort to get my tools
to work. If the community wants to find and fix the problem, i've
already said repeatedly i'll happily give over my repo, data,
whatever. You are correct i am not going to spend even more effort
when i can be productive with something else much quicker. The devil
i know (committing to svn) is better than the devil i don't (diving
into git source code and finding/fixing what is causing this space
blowup).
The python extension took me a few hours (< 4).
In git, i spent these hours waiting for git-gc to finish.
> This is what really eats me from the inside about your dissatisfaction
> with git. Your analysis seems to be a self-fullfilling prophecy, and
> that's totally unfair to both hg and git.
Oh?
You seem to be taking this awfully personally.
I came into this completely open minded. Really, I did (i'm sure
you'll claim otherwise).
GIT people told me it would work great and i'd have a really small git
repo and be able to commit back to svn.
I tried it.
It didn't work out.
It doesn't seem to be usable for whatever reason.
I'm happy to give details, data, whatever.
I made the engineering decision that my effort would be better spent
doing something I knew i could do quickly (make hg commit back to svn
for my purposes) then trying to improve larger issues in GIT (UI and
space usage). That took me a few hours, and I was happy again.
I would have been incredibly happy to have git just have come up with
a 400 meg gcc repository, and to be happily committing away from
git-svn to gcc's repository ...
But it didn't happen.
So far, you have yet to actually do anything but incorrectly tell me
what I am thinking.
I'll probably try again in 6 months, and maybe it will be better.
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 4:20 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 22:47:01 -0500
> The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just the trunk.
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 4:25 UTC (permalink / raw)
To: Daniel Berlin; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
I fought with this a few months ago when I did my own clone of gcc svn.
My bad for only discussing this on #git at the time. Should have put
this to the list as well.
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
git repack -a -d --depth=100 --window=100 produced a ~550MB packfile
immediately afterwards a git gc --aggressive produces a 1.5G packfile.
This was for all branches/tags, not just trunk like Daniel's repo.
The best theory I had at the time was that the gc doesn't find as good
deltas or doesn't allow the same delta chain depth and so generates a
new object in the pack, rather the reusing a good delta it already has
in the well-packed pack.
Cheers,
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 4:28 UTC (permalink / raw)
To: David Miller; +Cc: dberlin, ismail, gcc, git
In-Reply-To: <20071205.202047.58135920.davem@davemloft.net>
On Wed, 2007-12-05 at 20:20 -0800, David Miller wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those are including all of the repository history and branches
> not just the trunk.
David, I think it is actually a bug in git gc with the --aggressive
option...mind you, even if he solves that the format git svn uses
for its bi-directional metadata is so space-inefficient Daniel will
be crying for other reasons immediately afterwards...4MB for every
branch and tag in gcc svn (more than a few thousand).
You only need it around for any branches you are planning on committing
to but it is all created during the default git svn import.
FYI
Harvey
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-12-06 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwps8zf.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 05, 2007 at 02:59:16AM -0800, Junio C Hamano wrote:
> * jc/clean-fix (Tue Dec 4 23:55:41 2007 -0800) 1 commit
> - git-clean: Honor pathspec.
>
> This does fix limited test cases I tried, but I didn't check the
> directory related options at all. Sanity checking appreciated. We need
> a regression fix before v1.5.4
Hrm, I took a look at this and I'm a bit stumped.
I think the logic in builtin-clean is a bit suspect, and I have a patch
below that fixes it.
However, I still can't get something as simple as:
mkdir dir.clean &&
touch dir.clean/file &&
git clean -d "*.clean/"
to work, and I think the pathspec matching is to blame. If I use
"*.clean/", then read_directory assumes that "*.clean" is a directory to
be opened, without considering that it might be a wildcard, which is
just wrong. If I use "*.clean", then I get the correct directory
listing, but match_pathspec fails because read_directory returns
"dir.clean/". We could fix this by passing match_pathspec ent->len - 1,
but that actually ends up getting ignored! It ends up handing the string
to fnmatch, which treats it like a C string.
Am I crazy, or do we need to fix the wildcard semantics for directories
with both read_directory and with match_pathspec?
Below is my partial patch for reference.
-Peff
---
diff --git a/builtin-clean.c b/builtin-clean.c
index 61ae851..f4cf39f 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -117,7 +117,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
}
if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
- int matched_path = 0;
+ int matched_path = !pathspec;
strbuf_addstr(&directory, ent->name);
if (pathspec) {
/*
@@ -128,11 +128,11 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
baselen, seen))
matched_path = 1;
}
- if (show_only && (remove_directories || matched_path)) {
+ if (show_only && (remove_directories && matched_path)) {
printf("Would remove %s\n", directory.buf);
- } else if (quiet && (remove_directories || matched_path)) {
+ } else if (quiet && (remove_directories && matched_path)) {
remove_dir_recursively(&directory, 0);
- } else if (remove_directories || matched_path) {
+ } else if (remove_directories && matched_path) {
printf("Removing %s\n", directory.buf);
remove_dir_recursively(&directory, 0);
} else if (show_only) {
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index dfd1188..f204a50 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -192,6 +192,34 @@ test_expect_success 'git-clean -d src/ examples/' '
'
+test_expect_success 'git-clean with directory wildcards' '
+
+ mkdir -p dir.clean dir.stay &&
+ touch dir.clean/file dir.stay/file &&
+ git clean "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f dir.stay/file &&
+ test -f dir.clean/file
+
+'
+
+test_expect_success 'git-clean -d with directory wildcards' '
+
+ mkdir -p dir.clean dir.stay &&
+ touch dir.clean/file dir.stay/file &&
+ git clean -d "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f dir.stay/file &&
+ test ! -f dir.clean/file
+
+'
+
test_expect_success 'git-clean -x' '
mkdir -p build docs &&
^ permalink raw reply related
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 4:32 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.202047.58135920.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those are including all of the repository history and branches
> not just the trunk.
I followed the instructions in the tutorials.
I followed the instructions given to by people who created these.
I came up with a 1.5 gig pack file.
You want to help, or you want to argue with me.
Right now it sounds like you are trying to blame me or make it look
like i did something wrong.
You are of course, welcome to try it yourself.
I can give you the absolute exactly commands I gave, and with git
1.5.3.7, it will give you a 1.5 gig pack file.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-12-06 4:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fj60uc$er$2@ger.gmane.org>
On Wed, Dec 05, 2007 at 12:10:04PM +0100, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
> > + Support builtin aliases
> >
> > Cute hack. I'd like to have "git less" here.
>
> I guess that "git whatchanged" can be implemented also as builtin alias.
If you are thinking of
[alias]
whatchanged = log --raw --full-history
it does not quite work. git-log unconditionally sets --always, and there
is no command line option to turn it off. In most cases you could get an
approximation by using --no-merges, but it would still show commits that
actually have no tree change (there are 2 in git.git).
-Peff
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 4:48 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712052032n521c344cla07a5df1f2c26cb8@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 23:32:52 -0500
> On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > From: "Daniel Berlin" <dberlin@dberlin.org>
> > Date: Wed, 5 Dec 2007 22:47:01 -0500
> >
> > > The size is clearly not just svn data, it's in the git pack itself.
> >
> > And other users have shown much smaller metadata from a GIT import,
> > and yes those are including all of the repository history and branches
> > not just the trunk.
> I followed the instructions in the tutorials.
> I followed the instructions given to by people who created these.
> I came up with a 1.5 gig pack file.
> You want to help, or you want to argue with me.
Several people replied in this thread showing what options can lead to
smaller pack files.
They also listed what the GIT limitations are that would effect the
kind of work you are doing, which seemed to mostly deal with the high
space cost of branching and tags when converting to/from SVN repos.
^ permalink raw reply
* When a merge turns into a conflict
From: Anand Kumria @ 2007-12-06 4:49 UTC (permalink / raw)
To: git
Hi,
I've just had an odd experience with git (1.5.3.1) and wondered if this
was a known issue.
One of my co-developers has a project, with a README.txt file. I branch
from it and begin some edits:
- make it more AsciiDoc like (ala git)
- put in the README.txt a few patches that need to be applied
I had no issues 'git add' the file, and performing changes.
However when my colleague came to merge my patches in; git complained
that the file had conflict because:
a. it found the ========= AsciiDoc header line
b. it found the diff markers in the file
I do not know git well enough to know if this is a heurestic that can be
tweaked via the config file or something else. I am presently learning
git-filter-branch so I can prepare something to show -- but I just wanted
to flag and see if anyone else had had the same issue.
Thanks,
Anand
^ permalink raw reply
* Re: [PATCH] Soft aliases: add "less" and minimal documentation
From: Jeff King @ 2007-12-06 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd4tlorho.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 05, 2007 at 11:45:23AM -0800, Junio C Hamano wrote:
> I actually regret to have suggested "git less". Not only because you
> can always say "git show" instead, but because the error message you
> would get with usage string will _not_ say "git-less", but some other
> command's name if you say "git less nonsense".
>
> I on the other hand find the "view" alias moderately less problematic.
> As long as the future direction for the "view" alias is to allow it to
> notice user preference and launch something other than the default
> "gitk", iow, it is crystal clear that "git view" is just a short-hand
> for launching a history browser and the users are free to choose
> whichever viewer available, it won't feel inconsistent if underlying
> "gitk" barfed on malformed input using its own name.
The pattern I see here is that we get into trouble when we _pretend_
that builtin aliases are real commands, and not just handy shortcuts for
the real commands.
IOW, if a user is told that "git less" is the command to look at
objects, then they will:
1. get confused when "git less" claims to be "git cat-file" or "git
show" in error messages
2. get confused when there is no "git less" manpage
3. get confused when their coworker's "git less" behaves completely
differently
OTOH, if a user is told that "git less" is an alias for the user's
preferred method for viewing objects, that the default is "git show",
and that they can customize it themselves using alias.less, then I don't
think any of the above will be surprising.
So I think it is a bad idea to use such aliases to satisfy user requests
for simple commands, even when they can obviously be implemented as such
an alias.
That being said...
> By extension to this reasoning, I am not too keen on adding "update",
> "up", "checkin", "ci", nor "co". I do not think of any alternative
I think "checkin", "ci", and "co" are well-understood as aliases (and
will be doubly so if they are presented in the documentation as such).
After all, they come from CVS, which treats them this way:
$ cvs co
cvs checkout: No CVSROOT specified! Please use the `-d' option
^^^^^^^^
-Peff
^ permalink raw reply
* Re: Git and GCC
From: Linus Torvalds @ 2007-12-06 4:54 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <1196915112.10408.66.camel@brick>
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> If anyone recalls my report was something along the lines of
> git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it actually
throws away potentially good packing, and re-does it all from a clean
slate.
That said, it's totally pointless for a person who isn't a git proponent
to do an initial import, and in that sense I agree with Daniel: he
shouldn't waste his time with tools that he doesn't know or care about,
since there are people who *can* do a better job, and who know what they
are doing, and understand and like the tool.
While you can do a half-assed job with just mindlessly running "git
svnimport" (which is deprecated these days) or "git svn clone" (better),
the fact is, to do a *good* import does likely mean spending some effort
on it. Trying to make the user names / emails to be better with a mailmap,
for example.
[ By default, for example, "git svn clone/fetch" seems to create those
horrible fake email addresses that contain the ID of the SVN repo in
each commit - I'm not talking about the "git-svn-id", I'm talking about
the "user@hex-string-goes-here" thing for the author. Maybe people don't
really care, but isn't that ugly as hell? I'd think it's worth it doing
a really nice import, spending some effort on it.
But maybe those things come from the older CVS->SVN import, I don't
really know. I've done a few SVN imports, but I've done them just for
stuff where I didn't want to touch SVN, but just wanted to track some
project like libgpod. For things like *that*, a totally mindless "git
svn" thing is fine ]
Of course, that does require there to be git people in the gcc crowd who
are motivated enough to do the proper import and then make sure it's
up-to-date and hosted somewhere. If those people don't exist, I'm not sure
there's much idea to it.
The point being, you cannot ask a non-git person to do a major git import
for an actual switch-over. Yes, it *can* be as simple as just doing a
git svn clone --stdlayout svn://svn://gcc.gnu.org/svn/gcc gcc
but the fact remains, you want to spend more effort and expertise on it if
you actually want the result to be used as a basis for future work (as
opposed to just tracking somebody elses SVN tree).
That includes:
- do the historic import with good packing (and no, "--aggressive"
is not it, never mind the misleading name and man-page)
- probably mailmap entries, certainly spending some time validating the
results.
- hosting it
and perhaps most importantly
- helping people who are *not* git users get up to speed.
because doing a good job at it is like asking a CVS newbie to set up a
branch in CVS. I'm sure you can do it from man-pages, but I'm also sure
you sure as hell won't like the end result.
Linus
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 5:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <alpine.LFD.0.9999.0712052033570.13796@woody.linux-foundation.org>
On Wed, 2007-12-05 at 20:54 -0800, Linus Torvalds wrote:
>
> On Wed, 5 Dec 2007, Harvey Harrison wrote:
> >
> > If anyone recalls my report was something along the lines of
> > git gc --aggressive explodes pack size.
> [ By default, for example, "git svn clone/fetch" seems to create those
> horrible fake email addresses that contain the ID of the SVN repo in
> each commit - I'm not talking about the "git-svn-id", I'm talking about
> the "user@hex-string-goes-here" thing for the author. Maybe people don't
> really care, but isn't that ugly as hell? I'd think it's worth it doing
> a really nice import, spending some effort on it.
>
> But maybe those things come from the older CVS->SVN import, I don't
> really know. I've done a few SVN imports, but I've done them just for
> stuff where I didn't want to touch SVN, but just wanted to track some
> project like libgpod. For things like *that*, a totally mindless "git
> svn" thing is fine ]
>
git svn does accept a mailmap at import time with the same format as the
cvs importer I think. But for someone that just wants a repo to check
out this was easiest. I'd be willing to spend the time to do a nicer
job if there was any interest from the gcc side, but I'm not that
invested (other than owing them for an often-used tool).
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 5:11 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.204848.227521641.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 23:32:52 -0500
>
> > On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > > From: "Daniel Berlin" <dberlin@dberlin.org>
> > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > >
> > > > The size is clearly not just svn data, it's in the git pack itself.
> > >
> > > And other users have shown much smaller metadata from a GIT import,
> > > and yes those are including all of the repository history and branches
> > > not just the trunk.
> > I followed the instructions in the tutorials.
> > I followed the instructions given to by people who created these.
> > I came up with a 1.5 gig pack file.
> > You want to help, or you want to argue with me.
>
> Several people replied in this thread showing what options can lead to
> smaller pack files.
Actually, one person did, but that's okay, let's assume it was several.
I am currently trying Harvey's options.
I asked about using the pre-existing repos so i didn't have to do
this, but they were all
1. Done using read-only imports or
2. Don't contain full history
(IE the one that contains full history that is often posted here was
done as a read only import and thus doesn't have the metadata).
> They also listed what the GIT limitations are that would effect the
> kind of work you are doing, which seemed to mostly deal with the high
> space cost of branching and tags when converting to/from SVN repos.
Actually, it turns out that git-gc --aggressive does this dumb thing
to pack files sometimes regardless of whether you converted from an
SVN repo or not.
^ permalink raw reply
* git-p4: Import not at root of tree.
From: David Brown @ 2007-12-06 5:15 UTC (permalink / raw)
To: Git
I'm trying to mirror a directory deep down in a very chaotically organized
Perforce repo. I'd like the git tree to contains the contents of this
directory, but not at the root of my tree.
In other words I'd like to have something like
git-p4 clone --strip=//depot/a/b/c --destination=foo //depot/a/b/c/d
Result in:
foo/d/...
and have only a single directory 'd' at the top of the resulting git repo.
My current choices seem to be to put the contents of 'd' at the root, or
have the whole 'a/b/c/d' tree visible as what the '--keep-path' option does.
If this isn't implemented, any suggestions on the best way to go about
implementing this, or another way to do this.
What I'm trying to do is emulate the behavior of a P4 client spec. There
is a single directory (now, there will probably be others later) that is in
a different place in Perforce and it needs to be in this directory in order
to build. I've tried working with a submodule, but it is cumbersome to do
things like bisections when there are dependencies between the trees.
Thanks,
Dave
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 5:15 UTC (permalink / raw)
To: Daniel Berlin; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
On Thu, 2007-12-06 at 00:11 -0500, Daniel Berlin wrote:
> On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > From: "Daniel Berlin" <dberlin@dberlin.org>
> > Date: Wed, 5 Dec 2007 23:32:52 -0500
> >
> > > On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > > > From: "Daniel Berlin" <dberlin@dberlin.org>
> > > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > > >
> > > > > The size is clearly not just svn data, it's in the git pack itself.
> > > >
> > > > And other users have shown much smaller metadata from a GIT import,
> > > > and yes those are including all of the repository history and branches
> > > > not just the trunk.
> > > I followed the instructions in the tutorials.
> > > I followed the instructions given to by people who created these.
> > > I came up with a 1.5 gig pack file.
> > > You want to help, or you want to argue with me.
> >
> > Several people replied in this thread showing what options can lead to
> > smaller pack files.
>
> Actually, one person did, but that's okay, let's assume it was several.
> I am currently trying Harvey's options.
>
> I asked about using the pre-existing repos so i didn't have to do
> this, but they were all
> 1. Done using read-only imports or
> 2. Don't contain full history
> (IE the one that contains full history that is often posted here was
> done as a read only import and thus doesn't have the metadata).
While you won't get the git svn metadata if you clone the infradead
repo, it can be recreated on the fly by git svn if you want to start
commiting directly to gcc svn.
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 5:17 UTC (permalink / raw)
To: Harvey Harrison; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <1196918132.10408.85.camel@brick>
> While you won't get the git svn metadata if you clone the infradead
> repo, it can be recreated on the fly by git svn if you want to start
> commiting directly to gcc svn.
>
I will give this a try :)
^ permalink raw reply
* Re: [PATCH 2/3] git config --get-colorbool
From: Jeff King @ 2007-12-06 5:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <1196906706-11170-2-git-send-email-gitster@pobox.com>
[Eric Wong cc'd because of git-svn relevance]
On Wed, Dec 05, 2007 at 06:05:04PM -0800, Junio C Hamano wrote:
> This adds an option to help scripts find out color settings from
> the configuration file.
>
> git config --get-colorbool color.diff
>
> inspects color.diff variable, and exits with status 0 (i.e. success) if
> color is to be used. It exits with status 1 otherwise.
There is no way to differentiate between "do not use color" and "no
value found". This makes it impossible to use this to implement the
required "try color.diff, fallback to diff.color" behavior.
We could simply make it
git config --get-colorbool diff
which would check both (and when diff.color support is finally dropped,
just remove it from there).
git-svn should probably be moved to this interface (it still has the
color.diff == true means "always" behavior), but it can't be until the
fallback behavior is implemented.
Also, your patch doesn't seem to implement the color.pager/pager.color
behavior, either (which is probably not important for git-add -i, but is
used by git-svn).
Anyway, below is a totally untested (I don't even have svn installed,
but it passes perl -wc!) patch for git-svn to use the new "true means
auto" behavior for color.diff. It would be nice to replace this with
a working --get-colorbool, but we should at least unify the behavior
before v1.5.4.
-Peff
---
diff --git a/git-svn.perl b/git-svn.perl
index 9f884eb..71f6e93 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3979,7 +3979,12 @@ sub log_use_color {
$dc = `git-config --get $dcvar`;
}
chomp($dc);
- if ($dc eq 'auto') {
+ return 0 if $dc eq 'never';
+ return 1 if $dc eq 'always';
+ if ($dc ne 'auto') {
+ chomp($dc = `git-config --bool --get $dcvar`);
+ }
+ if ($dc eq 'auto' || $dc eq 'true') {
my $pc;
$pc = `git-config --get color.pager`;
if ($pc eq '') {
@@ -3998,10 +4003,7 @@ sub log_use_color {
}
return 0;
}
- return 0 if $dc eq 'never';
- return 1 if $dc eq 'always';
- chomp($dc = `git-config --bool --get $dcvar`);
- return ($dc eq 'true');
+ return 0;
}
sub git_svn_log_cmd {
^ permalink raw reply related
* Re: [PATCH 2/3] git config --get-colorbool
From: Jeff King @ 2007-12-06 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <20071206053059.GF5499@coredump.intra.peff.net>
On Thu, Dec 06, 2007 at 12:30:59AM -0500, Jeff King wrote:
> Also, your patch doesn't seem to implement the color.pager/pager.color
> behavior, either (which is probably not important for git-add -i, but is
> used by git-svn).
Oops, maybe I should actually read your patch more carefully before
criticizing. I see that you do handle pager_use_color in
git_config_colorbool, but I think that for --get-colorbool usage,
pager_in_use is going to be useless (wow, three forms of "use" in one
clause).
-Peff
^ 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