* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Junio C Hamano @ 2007-11-03 2:45 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Brian Downing
In-Reply-To: <20071102174552.GE15595@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> The whitespace policy varies based on the project (and in some cases,
> based on the file within that project). It shouldn't vary from user to
> user or repo to repo. So the configuration variable mechanism seems a
> poor match. Would it be possible to use something like gitattributes
> instead? Then the whitespace policy would be associated with the
> project itself, would automatically be propagated on clone, etc.
The use of gitattributes certainly sounds like a good way to
go. A project like git may say "HT indent for C sources, SP
only for Python parts".
Having said that, I've added a few tests and merged the result
to 'next' already. We can improve it to use attributes instead
while on 'next'.
And the git-apply side needs a matching adjustment.
^ permalink raw reply
* [PATCH 1/2] Added basic color support to git add --interactive
From: Dan Zwell @ 2007-11-03 3:41 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071023035221.66ea537f@danzwell.com>
[-- Attachment #1: Type: text/plain, Size: 4621 bytes --]
From 29b34bb32846921c9432bf1b74c93d06a0667a44 Mon Sep 17 00:00:00 2001
From: Dan Zwell <dzwell@zwell.net>
Date: Mon, 22 Oct 2007 15:55:20 -0500
Subject: [PATCH] Added basic color support to git add --interactive
Added function "print_colored" that prints text with a color that
is passed in. Converted many calls to "print" to being calls to
"print_colored".
The prompt, the header, and the help output are the 3 types of
colorized output, and each has its own color.
Colorization is done through Term::ANSIColor, which is included
with modern versions of perl. This is optional, and should not
need to be present if color.interactive is not turned on.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
I believe this version takes care of the complaints people had
with this patch. I hope this is helpful.
Documentation/config.txt | 6 ++++++
git-add--interactive.perl | 42 ++++++++++++++++++++++++++++++++++++------
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index edf50cd..2fd783f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -382,6 +382,12 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When true (or `always`), always use colors in `git add
+ --interactive`. When false (or `never`), never. When set to
+ `auto`, use colors only when the output is to the
+ terminal. Defaults to false.
+
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 ac598f8..16dc7b0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,36 @@
use strict;
+my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
+my $color_config = qx(git config --get color.interactive);
+if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
+ require Term::ANSIColor;
+
+ $use_color = "true";
+ # Sane (visible) defaults:
+ $prompt_color = Term::ANSIColor::color("blue bold");
+ $header_color = Term::ANSIColor::color("bold");
+ $help_color = Term::ANSIColor::color("red bold");
+ $normal_color = Term::ANSIColor::color("reset");
+}
+
+sub print_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$/;
+ }
+ print $string;
+}
+
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
my @invalid = grep {m/[":*]/} @_;
@@ -175,7 +205,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] ? '*' : ' ';
@@ -205,7 +235,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print_colored $prompt_color, $opts->{PROMPT};
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -544,7 +574,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
@@ -619,7 +649,7 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print_colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -673,7 +703,7 @@ sub patch_update_cmd {
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,
@@ -766,7 +796,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
--
1.5.3.5.474.g3e4bb
[-- Attachment #2: 0001-Added-basic-color-support-to-git-add-interactive.patch --]
[-- Type: text/x-patch, Size: 4377 bytes --]
>From 29b34bb32846921c9432bf1b74c93d06a0667a44 Mon Sep 17 00:00:00 2001
From: Dan Zwell <dzwell@zwell.net>
Date: Mon, 22 Oct 2007 15:55:20 -0500
Subject: [PATCH] Added basic color support to git add --interactive
Added function "print_colored" that prints text with a color that
is passed in. Converted many calls to "print" to being calls to
"print_colored".
The prompt, the header, and the help output are the 3 types of
colorized output, and each has its own color.
Colorization is done through Term::ANSIColor, which is included
with modern versions of perl. This is optional, and should not
need to be present if color.interactive is not turned on.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
Documentation/config.txt | 6 ++++++
git-add--interactive.perl | 42 ++++++++++++++++++++++++++++++++++++------
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index edf50cd..2fd783f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -382,6 +382,12 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When true (or `always`), always use colors in `git add
+ --interactive`. When false (or `never`), never. When set to
+ `auto`, use colors only when the output is to the
+ terminal. Defaults to false.
+
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 ac598f8..16dc7b0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,36 @@
use strict;
+my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
+my $color_config = qx(git config --get color.interactive);
+if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
+ require Term::ANSIColor;
+
+ $use_color = "true";
+ # Sane (visible) defaults:
+ $prompt_color = Term::ANSIColor::color("blue bold");
+ $header_color = Term::ANSIColor::color("bold");
+ $help_color = Term::ANSIColor::color("red bold");
+ $normal_color = Term::ANSIColor::color("reset");
+}
+
+sub print_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$/;
+ }
+ print $string;
+}
+
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
my @invalid = grep {m/[":*]/} @_;
@@ -175,7 +205,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] ? '*' : ' ';
@@ -205,7 +235,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print_colored $prompt_color, $opts->{PROMPT};
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -544,7 +574,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
@@ -619,7 +649,7 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print_colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -673,7 +703,7 @@ sub patch_update_cmd {
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,
@@ -766,7 +796,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
--
1.5.3.5.474.g3e4bb
^ permalink raw reply related
* [PATCH 2/2] Let git-add--interactive read colors from .gitconfig
From: Dan Zwell @ 2007-11-03 3:41 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071023035221.66ea537f@danzwell.com>
>From ad3c6a2f015197a72d85039783a63a24c19f7017 Mon Sep 17 00:00:00 2001
From: Dan Zwell <dzwell@zwell.net>
Date: Mon, 22 Oct 2007 16:08:01 -0500
Subject: [PATCH] Let git-add--interactive read colors from .gitconfig
Colors are specified in color.interactive.{prompt,header,help}.
They are specified as git color strings as described in the
documentation. The method color_to_ansi_string() in Git.pm parses
these strings and returns ANSI color codes (using
Term::ANSIColor).
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
One thought is that is seems a bit sloppy to call "require Term::ANSIColor"
within color_to_ansi_code(), but I can't really see a better way. After all,
that is where the methods from that library are really needed. And I don't
know why Git.pm should need to know whether color will end up being used.
Documentation/config.txt | 7 +++++
git-add--interactive.perl | 22 ++++++++++++-----
perl/Git.pm | 56 ++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2fd783f..ade3399 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -388,6 +388,13 @@ color.interactive::
`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 16dc7b0..2bce5a1 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,18 +1,26 @@
#!/usr/bin/perl -w
use strict;
+use Git;
my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
my $color_config = qx(git config --get color.interactive);
if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
- require Term::ANSIColor;
-
$use_color = "true";
- # Sane (visible) defaults:
- $prompt_color = Term::ANSIColor::color("blue bold");
- $header_color = Term::ANSIColor::color("bold");
- $help_color = Term::ANSIColor::color("red bold");
- $normal_color = Term::ANSIColor::color("reset");
+ # Grab the 3 main colors in git color string format, with sane
+ # (visible) defaults:
+ my $repo = Git->repository();
+ my $git_prompt_color =
+ Git::config($repo, "color.interactive.prompt")||"bold blue";
+ my $git_header_color =
+ Git::config($repo, "color.interactive.header")||"bold";
+ my $git_help_color =
+ Git::config($repo, "color.interactive.help")||"red bold";
+
+ $prompt_color = Git::color_to_ansi_code($git_prompt_color);
+ $header_color = Git::color_to_ansi_code($git_header_color);
+ $help_color = Git::color_to_ansi_code($git_help_color);
+ $normal_color = Git::color_to_ansi_code("normal");
}
sub print_colored {
diff --git a/perl/Git.pm b/perl/Git.pm
index 3f4080c..9100e0b 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -515,7 +515,6 @@ sub config {
};
}
-
=item config_bool ( VARIABLE )
Retrieve the bool configuration C<VARIABLE>. The return value
@@ -550,6 +549,61 @@ sub config_bool {
}
+=item color_to_ansi_code ( COLOR )
+
+Converts a git-style color string, like "underline blue white" to
+an ANSI color code. The code is generated by Term::ANSIColor,
+after the string is parsed into the format that is accepted by
+that module. Used as follows:
+
+ print color_to_ansi_code("underline blue white");
+ print "some text";
+ print color_to_ansi_code("normal");
+
+=cut
+
+sub color_to_ansi_code {
+ my ($git_string) = @_;
+ my @ansi_words;
+ my %attrib_mappings = (
+ "bold" => "bold",
+ "ul" => "underline",
+ "blink" => "blink",
+ # not supported:
+ #"dim" => "",
+ "reverse" => "reverse"
+ );
+ my ($fg_done, $word);
+
+ foreach $word (split /\s+/, $git_string) {
+ if ($word =~ /normal/) {
+ $fg_done = "true";
+ }
+ elsif ($word =~ /black|red|green|yellow/ ||
+ $word =~ /blue|magenta|cyan|white/) {
+ # is a color.
+ if ($fg_done) {
+ # this is the background
+ push @ansi_words, "on_" . $word;
+ }
+ else {
+ # this is foreground
+ $fg_done = "true";
+ push @ansi_words, $word;
+ }
+ }
+ else {
+ # this is an attribute, not a color.
+ if ($attrib_mappings{$word}) {
+ push(@ansi_words,
+ $attrib_mappings{$word});
+ }
+ }
+ }
+ require Term::ANSIColor;
+ return Term::ANSIColor::color(join(" ", @ansi_words)||"reset");
+}
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
--
1.5.3.5.474.g3e4bb
^ permalink raw reply related
* Re: *[PATCH 2/2] Let git-add--interactive read colors from .gitconfig
From: Junio C Hamano @ 2007-11-03 5:06 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071102224111.7f7e165c@paradox.zwell.net>
Dan Zwell <dzwell@zwell.net> writes:
> One thought is that is seems a bit sloppy to call "require Term::ANSIColor"
> within color_to_ansi_code(), but I can't really see a better way. After all,
> that is where the methods from that library are really needed. And I don't
> know why Git.pm should need to know whether color will end up being used.
How big is Term::ANSIColor, and how universally available is it?
Implementing the ANSI "ESC [ %d m" arithmetic color.c in Perl
ourselves does not feel too much effort, compared to the
potential hassle of dealing with extra dependencies and
potential drift between scripts and C implementation.
We may later want to update the C side to take colors from
terminfo, but that is a separate topic ;-)
Since your 2/2 updates on your 1/2, the diff is difficult to
comment on, so I'll comment on the combined effects.
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ac598f8..2bce5a1 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,44 @@
#!/usr/bin/perl -w
use strict;
+use Git;
+
+my ($use_color, $prompt_color, $header_color, $help_color, $normal_color);
+my $color_config = qx(git config --get color.interactive);
+if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
+ $use_color = "true";
+ # Grab the 3 main colors in git color string format, with sane
+ # (visible) defaults:
+ my $repo = Git->repository();
+ my $git_prompt_color =
+ Git::config($repo, "color.interactive.prompt")||"bold blue";
+ my $git_header_color =
+ Git::config($repo, "color.interactive.header")||"bold";
+ my $git_help_color =
+ Git::config($repo, "color.interactive.help")||"red bold";
+
+ $prompt_color = Git::color_to_ansi_code($git_prompt_color);
+ $header_color = Git::color_to_ansi_code($git_header_color);
+ $help_color = Git::color_to_ansi_code($git_help_color);
+ $normal_color = Git::color_to_ansi_code("normal");
+}
If we are to still use Term::ANSIColor, then we might want to
protect ourselves from a broken installation:
if ($color_config =~ /true|always/ ||
-t STDOUT && $color_config =~ /auto/) {
eval { require Term::ANSIColor; };
if (!$@) {
$use_color = 1;
... set up the colors ...
}
else {
$use_color = 0;
}
}
Then you can remove the require from Git::color_to_ansi_code().
Your current calling convention is to require the calling site
to be sure the module is availble; the suggested change merely
makes it responsible to also make sure the module is loaded.
Hmm?
By the way, coloring the diff text itself may be just the matter
of doing something like this (except that you now need to snarf
OLD, NEW, METAINFO and FRAGINFO colors for diff configuration as
well.
In addition to a small matter of testing, a more practical issue
would be to add PAGER support there, I think.
---
git-add--interactive.perl | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 2bce5a1..1063a34 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -388,6 +388,27 @@ sub parse_diff {
return @hunk;
}
+sub print_diff_hunk {
+ my ($text) = @_;
+ for (@$text) {
+ if (!$use_color) {
+ print;
+ next;
+ }
+ if (/^\+/) {
+ print_colored $new_color, $_;
+ } elsif (/^\-/) {
+ print_colored $old_color, $_;
+ } elsif (/^\@/) {
+ print_colored $fraginfo_color, $_;
+ } elsif (/^ /) {
+ print_colored $normal_color, $_;
+ } else {
+ print_colored $metainfo_color, $_;
+ }
+ }
+}
+
sub hunk_splittable {
my ($text) = @_;
@@ -610,9 +631,7 @@ sub patch_update_cmd {
my ($ix, $num);
my $path = $it->{VALUE};
my ($head, @hunk) = parse_diff($path);
- for (@{$head->{TEXT}}) {
- print;
- }
+ print_diff_hunk($head->{TEXT});
$num = scalar @hunk;
$ix = 0;
@@ -654,9 +673,7 @@ sub patch_update_cmd {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
- for (@{$hunk[$ix]{TEXT}}) {
- print;
- }
+ print_diff_hunk($hunk[$ix]{TEXT});
print_colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
@@ -794,8 +811,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 {
^ permalink raw reply related
* [PATCH] git-fetch: more terse fetch output
From: Nicolas Pitre @ 2007-11-03 5:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Jeff King
This makes the fetch output much more terse and prettier on a 80 column
display, based on a consensus reached on the mailing list. Here's an
example output:
Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
Resolving deltas: 100% (4604/4604), done.
From git://git.kernel.org/pub/scm/git/git
! [rejected] html -> origin/html (non fast forward)
136e631..f45e867 maint -> origin/maint (fast forward)
9850e2e..44dd7e0 man -> origin/man (fast forward)
3e4bb08..e3d6d56 master -> origin/master (fast forward)
fa3665c..536f64a next -> origin/next (fast forward)
+ 4f6d9d6...768326f pu -> origin/pu (forced update)
* [new branch] todo -> origin/todo
Some portions of this patch have been extracted from earlier proposals
by Jeff King and Shawn Pearce.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 003ed76..960b1da 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -131,12 +131,6 @@ static struct ref *get_ref_map(struct transport *transport,
return ref_map;
}
-static void show_new(enum object_type type, unsigned char *sha1_new)
-{
- fprintf(stderr, " %s: %s\n", typename(type),
- find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
-}
-
static int s_update_ref(const char *action,
struct ref *ref,
int check_old)
@@ -157,34 +151,38 @@ static int s_update_ref(const char *action,
return 0;
}
+#define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
+
static int update_local_ref(struct ref *ref,
- const char *note,
- int verbose)
+ const char *remote,
+ int verbose,
+ char *display)
{
- char oldh[41], newh[41];
struct commit *current = NULL, *updated;
enum object_type type;
struct branch *current_branch = branch_get(NULL);
+ const char *pretty_ref = ref->name + (
+ !prefixcmp(ref->name, "refs/heads/") ? 11 :
+ !prefixcmp(ref->name, "refs/tags/") ? 10 :
+ !prefixcmp(ref->name, "refs/remotes/") ? 13 :
+ 0);
+ *display = 0;
type = sha1_object_info(ref->new_sha1, NULL);
if (type < 0)
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!*ref->name) {
/* Not storing */
- if (verbose) {
- fprintf(stderr, "* fetched %s\n", note);
- show_new(type, ref->new_sha1);
- }
+ if (verbose)
+ sprintf(display, "* branch %s -> FETCH_HEAD", remote);
return 0;
}
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose) {
- fprintf(stderr, "* %s: same as %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
- }
+ if (verbose)
+ sprintf(display, "= %-*s %s -> %s", SUMMARY_WIDTH,
+ "[up to date]", remote, pretty_ref);
return 0;
}
@@ -196,63 +194,65 @@ static int update_local_ref(struct ref *ref,
* If this is the head, and it's not okay to update
* the head, and the old value of the head isn't empty...
*/
- fprintf(stderr,
- " * %s: Cannot fetch into the current branch.\n",
- ref->name);
+ sprintf(display, "! %-*s %s -> %s (can't fetch in current branch)",
+ SUMMARY_WIDTH, "[rejected]", remote, pretty_ref);
return 1;
}
if (!is_null_sha1(ref->old_sha1) &&
!prefixcmp(ref->name, "refs/tags/")) {
- fprintf(stderr, "* %s: updating with %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
+ sprintf(display, "- %-*s %s -> %s",
+ SUMMARY_WIDTH, "[tag update]", remote, pretty_ref);
return s_update_ref("updating tag", ref, 0);
}
current = lookup_commit_reference_gently(ref->old_sha1, 1);
updated = lookup_commit_reference_gently(ref->new_sha1, 1);
if (!current || !updated) {
- char *msg;
- if (!strncmp(ref->name, "refs/tags/", 10))
+ const char *msg;
+ const char *what;
+ if (!strncmp(ref->name, "refs/tags/", 10)) {
msg = "storing tag";
- else
+ what = "[new tag]";
+ }
+ else {
msg = "storing head";
- fprintf(stderr, "* %s: storing %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
+ what = "[new branch]";
+ }
+
+ sprintf(display, "* %-*s %s -> %s",
+ SUMMARY_WIDTH, what, remote, pretty_ref);
return s_update_ref(msg, ref, 0);
}
- strcpy(oldh, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));
- strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
-
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, "* %s: fast forward to %s\n",
- ref->name, note);
- fprintf(stderr, " old..new: %s..%s\n", oldh, newh);
+ char quickref[83];
+ strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));
+ strcat(quickref, "..");
+ strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
+ sprintf(display, " %-*s %s -> %s (fast forward)",
+ SUMMARY_WIDTH, quickref, remote, pretty_ref);
return s_update_ref("fast forward", ref, 1);
- }
- if (!force && !ref->force) {
- fprintf(stderr,
- "* %s: not updating to non-fast forward %s\n",
- ref->name, note);
- fprintf(stderr,
- " old...new: %s...%s\n", oldh, newh);
+ } else if (force || ref->force) {
+ char quickref[84];
+ strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));
+ strcat(quickref, "...");
+ strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
+ sprintf(display, "+ %-*s %s -> %s (forced update)",
+ SUMMARY_WIDTH, quickref, remote, pretty_ref);
+ return s_update_ref("forced-update", ref, 1);
+ } else {
+ sprintf(display, "! %-*s %s -> %s (non fast forward)",
+ SUMMARY_WIDTH, "[rejected]", remote, pretty_ref);
return 1;
}
- fprintf(stderr,
- "* %s: forcing update to non-fast forward %s\n",
- ref->name, note);
- fprintf(stderr, " old...new: %s...%s\n", oldh, newh);
- return s_update_ref("forced-update", ref, 1);
}
static void store_updated_refs(const char *url, struct ref *ref_map)
{
FILE *fp;
struct commit *commit;
- int url_len, i, note_len;
+ int url_len, i, note_len, shown_url = 0;
char note[1024];
const char *what, *kind;
struct ref *rm;
@@ -315,8 +315,17 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
rm->merge ? "" : "not-for-merge",
note);
- if (ref)
- update_local_ref(ref, note, verbose);
+ if (ref) {
+ update_local_ref(ref, what, verbose, note);
+ if (*note) {
+ if (!shown_url) {
+ fprintf(stderr, "From %.*s\n",
+ url_len, url);
+ shown_url = 1;
+ }
+ fprintf(stderr, " %s\n", note);
+ }
+ }
}
fclose(fp);
}
@@ -376,9 +385,6 @@ static struct ref *find_non_local_tags(struct transport *transport,
if (!path_list_has_path(&existing_refs, ref_name) &&
!path_list_has_path(&new_refs, ref_name) &&
lookup_object(ref->old_sha1)) {
- fprintf(stderr, "Auto-following %s\n",
- ref_name);
-
path_list_insert(ref_name, &new_refs);
rm = alloc_ref(strlen(ref_name) + 1);
^ permalink raw reply related
* Re: [PATCH] git-fetch: more terse fetch output
From: Junio C Hamano @ 2007-11-03 5:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711030101340.21255@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> This makes the fetch output much more terse and prettier on a 80 column
> display, based on a consensus reached on the mailing list. Here's an
> example output:
>
> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
> Resolving deltas: 100% (4604/4604), done.
> From git://git.kernel.org/pub/scm/git/git
> ! [rejected] html -> origin/html (non fast forward)
> 136e631..f45e867 maint -> origin/maint (fast forward)
> 9850e2e..44dd7e0 man -> origin/man (fast forward)
> 3e4bb08..e3d6d56 master -> origin/master (fast forward)
> fa3665c..536f64a next -> origin/next (fast forward)
> + 4f6d9d6...768326f pu -> origin/pu (forced update)
> * [new branch] todo -> origin/todo
Yay!
^ permalink raw reply
* Re: [PATCH] errors: "strict subset" -> "ancestor"
From: Steffen Prohaska @ 2007-11-03 7:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20071103023944.GA15379@fieldses.org>
On Nov 3, 2007, at 3:39 AM, J. Bruce Fields wrote:
> diff --git a/send-pack.c b/send-pack.c
> index 5e127a1..b74fd45 100644
> --- a/send-pack.c
> +++ b/send-pack.c
> @@ -297,9 +297,9 @@ static int send_pack(int in, int out, struct
> remote *remote, int nr_refspec, cha
> * commits at the remote end and likely
> * we were not up to date to begin with.
> */
> - error("remote '%s' is not a strict "
> - "subset of local ref '%s'. "
> - "maybe you are not up-to-date and "
> + error("remote '%s' is not an ancestor of\n"
> + " local '%s'.\n"
Two spaces in a row after local and before '%s'.
Steffen
^ permalink raw reply
* Re: [PATCH] errors: "strict subset" -> "ancestor"
From: David Symonds @ 2007-11-03 7:14 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: J. Bruce Fields, Junio C Hamano, git
In-Reply-To: <A4169B7B-C05B-4CA0-B41B-E1E2D71491B6@zib.de>
On 11/3/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Nov 3, 2007, at 3:39 AM, J. Bruce Fields wrote:
>
> > diff --git a/send-pack.c b/send-pack.c
> > index 5e127a1..b74fd45 100644
> > --- a/send-pack.c
> > +++ b/send-pack.c
> > @@ -297,9 +297,9 @@ static int send_pack(int in, int out, struct
> > remote *remote, int nr_refspec, cha
> > * commits at the remote end and likely
> > * we were not up to date to begin with.
> > */
> > - error("remote '%s' is not a strict "
> > - "subset of local ref '%s'. "
> > - "maybe you are not up-to-date and "
> > + error("remote '%s' is not an ancestor of\n"
> > + " local '%s'.\n"
>
> Two spaces in a row after local and before '%s'.
So? That's presumably to align the remote and local strings.
Dave.
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 7:16 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List, Pascal Obry
In-Reply-To: <472BABFA.6030200@obry.net>
On Nov 3, 2007, at 12:00 AM, Pascal Obry wrote:
> Abdelrazak,
>
>> I would like to try git on Windows together with git-svn, I
>> downloaded
>> Git-1.5.3-preview20071027.exe and tried:
>
> The best Git port on Windows is the Cygwin one. I'm using git-svn
> without trouble.
But you _MUST NOT_ use Cygwin's textmode.
Steffen
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-03 7:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <A35C7C2D-A829-4A16-B81B-8A6DE01FE5DB@zib.de>
Steffen Prohaska a écrit :
>> The best Git port on Windows is the Cygwin one. I'm using git-svn
>> without trouble.
>
> But you _MUST NOT_ use Cygwin's textmode.
Yes, of course! Who would use Cygwin's textmode :) ?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] errors: "strict subset" -> "ancestor"
From: Steffen Prohaska @ 2007-11-03 7:24 UTC (permalink / raw)
To: David Symonds; +Cc: J. Bruce Fields, Junio C Hamano, git
In-Reply-To: <ee77f5c20711030014x23ac6206rec81fe5968992147@mail.gmail.com>
On Nov 3, 2007, at 8:14 AM, David Symonds wrote:
> On 11/3/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> On Nov 3, 2007, at 3:39 AM, J. Bruce Fields wrote:
>>
>>> diff --git a/send-pack.c b/send-pack.c
>>> index 5e127a1..b74fd45 100644
>>> --- a/send-pack.c
>>> +++ b/send-pack.c
>>> @@ -297,9 +297,9 @@ static int send_pack(int in, int out, struct
>>> remote *remote, int nr_refspec, cha
>>> * commits at the remote end and
>>> likely
>>> * we were not up to date to begin
>>> with.
>>> */
>>> - error("remote '%s' is not a strict "
>>> - "subset of local ref '%s'. "
>>> - "maybe you are not up-to-date
>>> and "
>>> + error("remote '%s' is not an
>>> ancestor of\n"
>>> + " local '%s'.\n"
>>
>> Two spaces in a row after local and before '%s'.
>
> So? That's presumably to align the remote and local strings.
They are not aligned. The second line is indented with one
space. Look at examples in the commit message. The first line
starts with "error:", which already destroys the alignment.
Steffen
^ permalink raw reply
* Re: *[PATCH 2/2] Let git-add--interactive read colors from .gitconfig
From: Dan Zwell @ 2007-11-03 7:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <7vy7dfyl33.fsf_-_@gitster.siamese.dyndns.org>
On Fri, 02 Nov 2007 22:06:08 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Dan Zwell <dzwell@zwell.net> writes:
>
> How big is Term::ANSIColor, and how universally available is it?
> Implementing the ANSI "ESC [ %d m" arithmetic color.c in Perl
> ourselves does not feel too much effort, compared to the
> potential hassle of dealing with extra dependencies and
> potential drift between scripts and C implementation.
20K on my machine, and part of the core library since Perl 5.6.0.
This was released in 2000. With your addition (the eval check to make
sure the module is loaded), nobody should be harmed if they don't have a
modern perl, either. My vote would be to reimplement the coloring if we
actually notice these problems.
<snip>
>
> By the way, coloring the diff text itself may be just the matter
> of doing something like this (except that you now need to snarf
> OLD, NEW, METAINFO and FRAGINFO colors for diff configuration as
> well.
>
> In addition to a small matter of testing, a more practical issue
> would be to add PAGER support there, I think.
You mean in general, so that users can view a hunk in the PAGER, then
be prompted for what to do with it? (Because it doesn't solve the color
problems, because calling "diff --color" here creates other problems.)
>
> ---
>
> git-add--interactive.perl | 32 ++++++++++++++++++++++++--------
> 1 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 2bce5a1..1063a34 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -388,6 +388,27 @@ sub parse_diff {
> return @hunk;
> }
>
> +sub print_diff_hunk {
> + my ($text) = @_;
> + for (@$text) {
> + if (!$use_color) {
> + print;
> + next;
> + }
> + if (/^\+/) {
> + print_colored $new_color, $_;
> + } elsif (/^\-/) {
> + print_colored $old_color, $_;
> + } elsif (/^\@/) {
> + print_colored $fraginfo_color, $_;
> + } elsif (/^ /) {
> + print_colored $normal_color, $_;
> + } else {
> + print_colored $metainfo_color, $_;
> + }
> + }
> +}
> +
> sub hunk_splittable {
> my ($text) = @_;
>
> @@ -610,9 +631,7 @@ sub patch_update_cmd {
> my ($ix, $num);
> my $path = $it->{VALUE};
> my ($head, @hunk) = parse_diff($path);
> - for (@{$head->{TEXT}}) {
> - print;
> - }
> + print_diff_hunk($head->{TEXT});
> $num = scalar @hunk;
> $ix = 0;
>
> @@ -654,9 +673,7 @@ sub patch_update_cmd {
> if (hunk_splittable($hunk[$ix]{TEXT})) {
> $other .= '/s';
> }
> - for (@{$hunk[$ix]{TEXT}}) {
> - print;
> - }
> + print_diff_hunk($hunk[$ix]{TEXT});
> print_colored $prompt_color, "Stage this hunk
> [y/n/a/d$other/?]? "; my $line = <STDIN>;
> if ($line) {
> @@ -794,8 +811,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 {
>
In a previous incantation of this thread, coloring the diff output was
discussed. Your patch works, I tested it, but it does not highlight
whitespace at the end of lines or space/tab errors. If this is the only
case that more than one color may appear per line, it should not be
hard to match it as a special case (assuming this check isn't disabled
in .gitconfig), and print the rest of the line as we otherwise would.
Dan
^ permalink raw reply
* Re: [PATCH] errors: "strict subset" -> "ancestor"
From: Steffen Prohaska @ 2007-11-03 7:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071103023944.GA15379@fieldses.org>
On Nov 3, 2007, at 3:39 AM, J. Bruce Fields wrote:
> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> The term "ancestor" is a bit more intuitive (and more consistent with
> the documentation) than the term "strict subset".
>
> Also, remove superfluous "ref", capitalize, and add some carriage
> returns, changing:
>
> error: remote 'refs/heads/master' is not a strict subset of local
> ref 'refs/heads/master'. maybe you are not up-to-date and need to
> pull first?
> error: failed to push to 'ssh://linux-nfs.org/~bfields/exports/
> git.git'
>
> to:
>
> error: remote 'refs/heads/master' is not an ancestor of
> local 'refs/heads/master'.
> Maybe you are not up-to-date and need to pull first?
> error: failed to push to 'ssh://linux-nfs.org/~bfields/exports/
> git.git'
Junio suggested in [1] (see also earlier messages in that
thread) to replace the recommendation to pull with a hint
where to look in the user manual.
[1] http://marc.info/?l=git&m=119398999317677&w=2
The point is, there are various ways to resolve the problem.
pull is not necessarily the right solution. At least, you should
consider to rebase. Or maybe just something else went wrong.
Nonetheless I think it could be a good idea to keep the most
likely cases. So, how about
"Are you up-to-date? Did you forget to pull or rebase? See User's
Manual for details."
I put it as questions to avoid making a suggestion. The questions
should give sufficient hints for searching in the User's Manual.
I haven't found the single section that would explain exactly
the situation we're dealing with.
I attached the commit that originally introduced the suggestion.
Steffen
commit 69310a34cb6dcca32b08cf3ea9e91ab19354a874
Author: Junio C Hamano <junkio@cox.net>
Date: Thu Dec 22 12:39:39 2005 -0800
send-pack: reword non-fast-forward error message.
Wnen refusing to push a head, we said cryptic "remote 'branch'
object X does not exist on local" or "remote ref 'branch' is not
a strict subset of local ref 'branch'". That was gittish.
Since the most likely reason this happens is because the pushed
head was not up-to-date, clarify the error message to say that
straight, and suggest pulling first.
First noticed by Johannes and seconded by Andreas.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 7:57 UTC (permalink / raw)
To: Pascal Obry; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <472C211C.90907@obry.net>
On Nov 3, 2007, at 8:19 AM, Pascal Obry wrote:
> Steffen Prohaska a écrit :
>>> The best Git port on Windows is the Cygwin one. I'm using git-svn
>>> without trouble.
>>
>> But you _MUST NOT_ use Cygwin's textmode.
>
> Yes, of course! Who would use Cygwin's textmode :) ?
People who I'm working with. Cygwin's converts CVS working
copies to Windows line endings if you use textmode. And this
is what they want.
And as long as textmode is an option in Cygwin's installer
user will select this option. And after it was removed from
the installer it will still be there for a couple of years,
until all existing installations finally disappear.
Because of this situation, I started to work on msysgit.
I need git without Cygwin.
Steffen
^ permalink raw reply
* Re: [PATCH 0/2] History replay support
From: Marco Costalba @ 2007-11-03 7:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0711021809060.3342@woody.linux-foundation.org>
On 11/3/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 2 Nov 2007, Linus Torvalds wrote:
> >
> > The bad news is that it doesn't work well in this simplistic form, because
> > there is a O(n**2) behaviour when replays *do* happen, ie we end up having
> > replays within replays [..]
>
> Gaah. the more I look at this, the more I think the topo sort should be
> done at the visualization side.
>
> It's really quite cheap to do the topo sort, *and* it's really quite cheap
> to do the tests that trigger the topo sort, but what's expensive is to
> re-output all the data again!
>
> The silly thing is, I think I've come up with an "almost optimal"
> solution, but it's so ugly that I'm a bit ashamed of it.
>
> That almost optimal solution is simply:
> - get the first <n> (say: 100) commits, and topo-sort just them. Feed it
> to the visualizer.
> - the visualizer will now have enough to work with in order to show the
> starting screen and set the cursor to the hourglass or whatever the
> "wait for it" thing is.
> - get the rest of the commits at our normal leisurely pace (whether it
> is one second of 17).
> - output the total number of commits (so that the visualizer can re-size
> the slider and/or allocate some big array just once), topo-sort it all,
> and output the full thing.
>
> It's disgusting. But it avoids the unnecessary data transfer - except for
> just the first 100 commits that get sent twice. And it gets what *I* look
> for, namely that "immediate" feel to the initial pop-up of the history.
>
It's not disgusting is human perception oriented !
All this stuff is not needed to get the sha faster, but to let think
the user that are faster. It's for strictly human consumption, so I
would say your "ugly" solution is the best for me.
A bunch of revisions, just to let user eyes to re-focus on new stuff
(and some hundredths of milliseconds are already elapsed after this)
while in the background the real, shadowed, work goes on.
It's also easy on the client GUI side, simply discard all and reload
as soon _correct_ data arrives.
So the new option could became:
git log --fast-output 100 500 --topo-order <...whatever...>
where git log outputs as soon as it can 100 commits and feeds it to
the visualizer. If the _normal_ commits are still not ready after 500
ms are elapsed then git log spits out another 100 commits chunk and so
on at 500ms intervals until good commits are ready. Then outputs the
full thing.
It is very user perception oriented, but hey, so is a GUI!
Marco
P.S: A little optimization for small repositories would be that git
log *waits* at maximum 500ms before to output the first 100 commits
chunk, so that in case of small repos (thousands of revisions) or in
case of warmed up cache the commits in output are already the good
ones, no need for fakes!
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 8:02 UTC (permalink / raw)
To: Pascal Obry; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <EE16FE19-8C6C-4438-8E6E-EA6B87A898A7@zib.de>
On Nov 3, 2007, at 8:57 AM, Steffen Prohaska wrote:
> On Nov 3, 2007, at 8:19 AM, Pascal Obry wrote:
>
>> Steffen Prohaska a écrit :
>>>> The best Git port on Windows is the Cygwin one. I'm using git-svn
>>>> without trouble.
>>>
>>> But you _MUST NOT_ use Cygwin's textmode.
>>
>> Yes, of course! Who would use Cygwin's textmode :) ?
>
> People who I'm working with. Cygwin's converts CVS working
> copies to Windows line endings if you use textmode. And this
> is what they want.
>
> And as long as textmode is an option in Cygwin's installer
> user will select this option. And after it was removed from
> the installer it will still be there for a couple of years,
> until all existing installations finally disappear.
>
> Because of this situation, I started to work on msysgit.
> I need git without Cygwin.
And btw, no one told me that git is only working in Cygwin if
Cygwin is configured the right way. So I started to advertise
git on Cygwin and people came back to me and told me:
"What crappy tool are you suggesting to use. It's not
even capable of cloning it's own development repository.
I'll not use that tool. Don't steal my time."
Steffen
^ permalink raw reply
* git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-03 8:19 UTC (permalink / raw)
To: git
There are a few svn repositories that use non-standard layout like this:
<path_to_project>/trunk
<path_to_project>/production
<path_to_project>/some_branch
production and some_branch are indeed branched from trunk.
1. How do you init/clone svn repositories like that?
2. Is there a way to add a new svn branch like that (say production
or some_branch) to an existing git-svn repository that has trunk cloned?
Thanks!
__Luke
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-03 8:23 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <72D5CB06-9067-47C4-ABDF-4E1F6F4A679D@zib.de>
Steffen Prohaska a écrit :
> "What crappy tool are you suggesting to use. It's not
> even capable of cloning it's own development repository.
> I'll not use that tool. Don't steal my time."
Well it's not because people don't understand how Cygwin is working that
it is to be taken for granted that Cygwin/Git is crap! As I said git svn
is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
repositories without problem. So experience may vary :)
Cygwin is by far the best toolset for Windows developers who don't want
to mess with plain (read very limited) Windows environment.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Andreas Ericsson @ 2007-11-03 8:36 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: git
In-Reply-To: <67837cd60711021303q488e0873lea363b93fc90d591@mail.gmail.com>
Ronald Landheer-Cieslak wrote:
>
> This is also available through git at
> git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
>
This mode of specifying a repository + branch was just thoroughly shot
down in a list discussion, and git certainly doesn't grok it. I'd be a
happier fella if you didn't use it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 9:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When forcing to overwrite an annotated tag, there are good chances one
wants to keep the old annotation, or modify it, not start from scratch.
This is obviously only triggered for annotated tagging (-a or -s).
Signed-off-by: Mike Hommey <mh@glandium.org>
---
The write_annotation function could be made more generic and be used in
various different coming builtins such as git-commit. Also, it could be
used in show_reference() in builtin-tag.c.
builtin-tag.c | 47 ++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 66e5a58..cfd8017 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -247,9 +247,42 @@ static int git_tag_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static void write_annotation(int fd, const unsigned char *sha1)
+{
+ int i;
+ unsigned long size;
+ enum object_type type;
+ char *buf, *sp, *eol;
+ size_t len;
+
+ sp = buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return;
+ if (!size || (type != OBJ_TAG)) {
+ free(buf);
+ return;
+ }
+ /* skip header */
+ while (sp + 1 < buf + size &&
+ !(sp[0] == '\n' && sp[1] == '\n'))
+ sp++;
+ /* strip the signature */
+ for (i = 0, sp += 2; sp < buf + size &&
+ prefixcmp(sp, PGP_SIGNATURE "\n");
+ i++) {
+ eol = memchr(sp, '\n', size - (sp - buf));
+ len = eol ? eol - sp : size - (sp - buf);
+ write_or_die(fd, sp, len + 1);
+ if (!eol)
+ break;
+ sp = eol + 1;
+ }
+ free(buf);
+}
+
static void create_tag(const unsigned char *object, const char *tag,
struct strbuf *buf, int message, int sign,
- unsigned char *result)
+ unsigned char *prev, unsigned char *result)
{
enum object_type type;
char header_buf[1024];
@@ -282,6 +315,10 @@ static void create_tag(const unsigned char *object, const char *tag,
if (fd < 0)
die("could not create file '%s': %s",
path, strerror(errno));
+
+ if (prev)
+ write_annotation(fd, prev);
+
write_or_die(fd, tag_template, strlen(tag_template));
close(fd);
@@ -308,7 +345,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf;
unsigned char object[20], prev[20];
- int annotate = 0, sign = 0, force = 0, lines = 0, message = 0;
+ int annotate = 0, sign = 0, force = 0, lines = 0,
+ message = 0, existed = 0;
char ref[PATH_MAX];
const char *object_ref, *tag;
int i;
@@ -417,9 +455,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
hashclr(prev);
else if (!force)
die("tag '%s' already exists", tag);
+ else
+ existed = 1;
if (annotate)
- create_tag(object, tag, &buf, message, sign, object);
+ create_tag(object, tag, &buf, message, sign,
+ existed ? prev : NULL, object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
--
1.5.3.5
^ permalink raw reply related
* Re: Git-windows and git-svn?
From: Abdelrazak Younes @ 2007-11-03 9:33 UTC (permalink / raw)
To: git
In-Reply-To: <472C2FF8.2000603@obry.net>
Pascal Obry wrote:
> Steffen Prohaska a écrit :
>> "What crappy tool are you suggesting to use. It's not
>> even capable of cloning it's own development repository.
>> I'll not use that tool. Don't steal my time."
>
> Well it's not because people don't understand how Cygwin is working that
> it is to be taken for granted that Cygwin/Git is crap! As I said git svn
> is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
> repositories without problem. So experience may vary :)
OK, thanks for the info.
>
> Cygwin is by far the best toolset for Windows developers who don't want
> to mess with plain (read very limited) Windows environment.
Well some people (including unix people) prefer GUI and context menus
instead of command-line. I must say that I am quite used to TortoiseSVN
and I like it. Never had to do anything at the command-line in order to
use svn. Hum, I am not sure this is the right forum to say this... :-)
Abdel.
^ permalink raw reply
* Re: git rm --cached
From: Remi Vanicat @ 2007-11-03 9:39 UTC (permalink / raw)
To: git
In-Reply-To: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com>
Jing Xue <jingxue@digizenstudio.com> writes:
> 2. The FAQ entry "Why 'git rm' is not inverse of 'git add'" says "a
> natural inverse of 'add' is 'un-add', and that operation is called 'rm
> --cached',..." Now I realize that only applies to adding a new file,
> but not changes on an existing file.
Well, so it seem that to think of "git rm --cached" as inverse to
"git add" is also confusing. The FAQ entry should probably be
rewrite. Or at least clarified.
--
Rémi Vanicat
^ permalink raw reply
* StGIT fails to clean patch series, and to go to a patch
From: Jakub Narebski @ 2007-11-03 9:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I have patch series with empty patch in the middle of the stack.
After trying to stg-clean (and failing) stack looks like below:
1167:[gitweb/web!git]$ stg series -e -s
+ gitweb-Always-set-from_file-to_file
+ gitweb-Add-status_str-diffinfo
+ gitweb-Easier-adding-parameters-to-current-URL
+ gitweb-Use-replay-to-generate-pagination
> gitweb-Use-replay-to-generate-alt-views
0 gitweb-Update-INSTALL-file
- gitweb-No-CGI_Carp-in-test
- gitweb-Test-config-override
- gitweb-Config-reader
- gitweb-Use-config-more
Now stg-rebase works, but stg-goto doesn't work. It returns
the following error.
1164:[gitweb/web!git]$ stg goto gitweb-Use-config-more
Checking for changes in the working directory ... done
Traceback (most recent call last):
File "/usr/bin/stg", line 43, in ?
main()
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/lib/python2.4/site-packages/stgit/commands/goto.py", line 63, in func
push_patches(patches)
File "/usr/lib/python2.4/site-packages/stgit/commands/common.py", line 165, in push_patches
forwarded = crt_series.forward_patches(patches)
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 954, in forward_patches
bottom_tree = git.get_commit(bottom).get_tree()
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 136, in get_commit
commit = Commit(id_hash)
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 77, in __init__
lines = _output_lines(['git-cat-file', 'commit', id_hash])
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 196, in _output_lines
raise GitException, '%s failed (%s)' % (' '.join(cmd),
TypeError: sequence item 2: expected string, NoneType found
1165:[gitweb/web!git]$ stg version
Stacked GIT 0.13
git version 1.5.3.5
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 9:47 UTC (permalink / raw)
To: Pascal Obry; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <472C2FF8.2000603@obry.net>
On Nov 3, 2007, at 9:23 AM, Pascal Obry wrote:
> Steffen Prohaska a écrit :
>> "What crappy tool are you suggesting to use. It's not
>> even capable of cloning it's own development repository.
>> I'll not use that tool. Don't steal my time."
>
> Well it's not because people don't understand how Cygwin is working
> that
> it is to be taken for granted that Cygwin/Git is crap! As I said
> git svn
> is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
> repositories without problem. So experience may vary :)
Right. The experience should be good if you use binmode.
But never use textmode. You'll not get an error right away.
At first git seems to work. But later it reports weird errors.
The experience is really bad. Don't do that.
And if you advertise git on Cygwin please tell people to
avoid textmode. It is an important detail.
Steffen
^ permalink raw reply
* Re: [PATCH 5/5] Migrate git-am.sh to use git-rev-parse --parseopt
From: Alex Riesen @ 2007-11-03 9:55 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, torvalds, git
In-Reply-To: <1194043193-29601-6-git-send-email-madcoder@debian.org>
Pierre Habouzit, Fri, Nov 02, 2007 23:39:52 +0100:
> diff --git a/git-am.sh b/git-am.sh
> index 2514d07..e5ed6a7 100755
> --- a/git-am.sh
> +++ b/git-am.sh
...
> - usage ;;
> - *)
> - break ;;
> + -i|--interactive)
> + interactive=t ;;
> + -b|--binary)
> + binary=t ;;
Did you really have to change the indentation?
^ 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