* Re: What's in git.git
From: Junio C Hamano @ 2006-04-11 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <20060411155518.GY27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> I think the builtins should be a install-time only issue.
>
> I don't care about git-log in particular since I don't use it, but I use
> development Git versions without actually installing them and if it's
> not a huge hurdle, it would be nice to keep this possible.
Also not making the link would probably break test suite (I do
not know if we have git-log test right now, though).
But installing *copies* is obviously not right as you pointed out.
^ permalink raw reply
* Re: t5501-old-fetch-and-upload.sh fails with NO_PYTHON=1
From: Junio C Hamano @ 2006-04-11 18:06 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git, Johannes Schindelin
In-Reply-To: <20060411170508.G14ba7e47@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> I have attached a simple fix, but is this test still useful at all?
Thanks. I am inclined to say that when we need the "make sure
this updated send-pack works with older receive-pack and vice
versa" tests the next time, the framework to call the
counterpart program from different vintage might be reusable but
what the test tries to test would be different, so keeping this
particular test would be somewhat useful as reference and
perhaps a starting point for such new test, but otherwise not
very much. And for that kind of usage, "the Net never forgets".
I'd vote for its removal. Thoughts?
^ permalink raw reply
* Re: [PATCH] Implement limited context matching in git-apply.
From: Linus Torvalds @ 2006-04-11 18:23 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1k69xffcz.fsf@ebiederm.dsl.xmission.com>
On Mon, 10 Apr 2006, Eric W. Biederman wrote:
>
> So at a quick inspection it looks to me like:
> About .059s to perform to check for missing files.
> About .019s to write the new tree.
> About .155s in start up overhead, read_cache, and sanity checks.
>
> So at a first glance it looks like librification to
> allow the redundant work to be skipped, is where
> the big speed win on my machine would be.
That sounded wrong to me, so I did a stupid patch to datestamp the
different phases of git-write-tree, and here's what it says for me:
0.000479 setup_git_directory
0.008333 read_cache
0.000813 ce_stage check
0.001838 tree validity check
0.037233 write_tree itself
real 0m0.051s
user 0m0.044s
sys 0m0.008s
all times are in seconds.
There is some overhead from the actual process startup (the timestamp
numbers add up to 0.048696 seconds, which is less than the 0.051 reported
by "time" - since I didn't datestamp everything), but the biggest chunk by
far (about three quarters of the total time, including _all_ the setup
like executing the process) is the actual call to write_tree() itself.
So it probably wouldn't actually be that big a win performance-wise to
make write_tree() a library and call it directly from git-apply with some
flag.
To really speed up write-tree, you'd have to know which trees to write,
and just skip the rest (and know what SHA1's the ones you skipped had:
it's not enough to just skip them, since you need the SHA1's of even the
trees you skipped to write the parent tree, and you _will_ change at
least the top parent tree if you had a valid patch).
Which would imply pretty major surgery - you'd have to add the tree entry
information to the index file, and make sure they got invalidated properly
(all the way to the root) whenever adding/deleting/updating a path in the
index file.
Quite frankly, I don't think it's really worth it.
Yes, it would speed up applying of huge patch-sets, but it's not like
we're really slow at that even now, and I suspect you'd be better off
trying to either live with it, or trying to see if you could change your
workflow. There clearly _are_ tools that are better at handling pure
patches, with quilt being the obvious example.
I routinely apply 100-200 patches in a go, and that's fast enough to not
even be an issue. Yes, I have reasonably fast hardware, but we're likely
talking thousands of patches in a series for it to be _really_ painful
even on pretty basic developer hardware. Even a slow machine should do a
few hundred patches in a couple of minutes.
Maybe enough time to get a cup of coffee, but no more than it would take
to compile the project.
Linus
^ permalink raw reply
* cg-admin-rewritehist --tree-filter revives removed files
From: Johannes Sixt @ 2006-04-11 19:26 UTC (permalink / raw)
To: git
I ran this on a small project:
cg-admin-rewritehist --tree-filter ':' testbranch
Thereafter, the tree in testbranch has all files that had been removed in the
original history. I used cg-switch testbranch to check this.
The main loop in cg-admin-rewritehist does this (among others) for each commit
in the original history:
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
eval "$filter_tree"
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
git-ls-files --others | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
fi
Appearently, once files are checked out, they stay in the working directory
and are readded in all subsequent iterations if the current commit's tree
does not contain them.
I'm not proficient enough to fix this problem myself, so I hope for help from
the list.
Thanks,
-- Hannes
^ permalink raw reply
* Re: t5501-old-fetch-and-upload.sh fails with NO_PYTHON=1
From: Johannes Schindelin @ 2006-04-11 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkuc56m9.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 11 Apr 2006, Junio C Hamano wrote:
> [...] so keeping this particular test would be somewhat useful as
> reference and perhaps a starting point for such new test, but otherwise
> not very much. And for that kind of usage, "the Net never forgets".
Not only that. Git itself never forgets. "git-cat-file blob 596c88b" will
probably work virtually forever.
> I'd vote for its removal. Thoughts?
Yeah.
Ciao,
Dscho
^ permalink raw reply
* Re: Fix up diffcore-rename scoring
From: Junio C Hamano @ 2006-04-11 22:04 UTC (permalink / raw)
To: Geert Bosch; +Cc: git
In-Reply-To: <DFDDA9C5-D8D2-413F-8A06-4D727C8F9EED@adacore.com>
Geert Bosch <bosch@adacore.com> writes:
> On Mar 13, 2006, at 02:44, Linus Torvalds wrote:
>
>> It might be that the fast delta thing is a good way to ask
>> "is this even worth considering", to cut down the O(m*n)
>> rename/copy detection to something much smaller, and then use
>> xdelta() to actually figure out what is a good rename and
>> what isn't from a much smaller set of potential targets.
>
>
> Here's a possible way to do that first cut. Basically,
> compute a short (256-bit) fingerprint for each file, such
> that the Hamming distance between two fingerprints is a measure
> for their similarity. I'll include a draft write up below.
Thanks for starting this.
There are a few things I need to talk about the way "similarity"
is _used_ in the current algorithms.
Rename/copy detection outputs "similarity" but I suspect what
the algorithm wants is slightly different from what humans think
of "similarity". It is somewhere between "similarity" and
"commonness". When you are grading a 130-page report a student
submitted, you would want to notice that last 30 pages are
almost verbatim copy from somebody else's report. The student
in question added 100-page original contents so maybe this is
not too bad, but if the report were a 30-page one, and the
entier 30 pages were borrowed from somebody else's 130-page
report, you would _really_ want to notice.
While reorganizaing a program, a nontrivial amount of text is
often removed from an existing file and moved to a newly created
file. Right now, the way similarity score is calculated has a
heuristical cap to reject two files whose sizes are very
different, but to detect and show this kind of file split, the
sizes of files should matter less.
On the other hand, taking this "commonness matters" to its
extreme is not what we want. We are producing "diff", so if a
30-line new file was created by moving these 30 lines from
originally 130-line file (which is now 100 lines long), showing
it as "copy from the-130-line-file" with a diff to remove
100-lines is usually not what we want. That's why the size cap
makes sense in rename similarity estimator.
Another place we use "similarity" is to break a file that got
modified too much. This is done for two independent purposes.
One is to detect a case like this:
mv B C
mv A B
small-edit B
File B's content is not related to what it had originally, but
is derived from what was originally in A. Usually rename/copy
detection tries to find rename/copy into files that _disappear_
from the result, but with the above sequence, B never
disappears. By looking at how dissimilar the preimage and
postimage of B are, we tell the rename/copy detector that B,
although it does not disappear, might have been renamed/copied
from somewhere else.
Another is to present the final diff output as a complete
rewrite. When -B (break) is used without -M (rename) or -C
(copy), or a file that got a lot of edit and got "broken" turned
out to be purely a total edit (i.e. not renamed/copied from
somewhere else), we would present it as diff output that has
only one hunk, with bunch of '-' (removal) to remove all
original contents first and then '+' (addition) to add all the
new contents, which is often easier to read than ordinary
unidiff between two unrelated contents that matches up lines
that happen to be the same. Empirically, it seems to give
better result if the "similarity" threshold to "break" a file
(i.e. to consider it might have been renamed/copied from
somewhere else) is set lower than the threashold to show the
diff as a complete rewrite patch.
Also we can make commonness matter even more in the similarlity
used to "break" a file than rename detector, because if we are
going to break it, we will not have to worry about the issue of
showing an annoying diff that removes 100 lines after copying a
130-line file. This implies that the break algorithm needs to
use two different kinds of similarity, one for breaking and then
another for deciding how to show the broken pieces as a diff.
Sorry if this write-up does not make much sense. It ended up
being a lot more incoherent than I hoped it to be.
Anyway, sometime this week I'll find time to play with your code
myself.
^ permalink raw reply
* Adding color to git diff output.
From: sean @ 2006-04-11 22:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Linus posted a colorize program a while back[1] but it wasn't taken into git.
The patch below takes a different approach, adding a GIT_DIFF_PAGER variable.
You can use it by assigning a filter to the environment variable, like so:
export GIT_DIFF_PAGER="colordiff | less -RS"
Sean
P.S. .gitignore is missing a few entries: "git.spec" (rpm build), "tags"
(ctags), and ".*.swp" (vi editor temp files).
[1] http://marc.theaimsgroup.com/?l=git&m=114315063918024&w=2
diff --git a/git-diff.sh b/git-diff.sh
index dc0dd31..f792340 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -69,4 +69,8 @@ case "$rev" in
;;
esac
+if [ -n "$GIT_DIFF_PAGER" ]; then
+ cmd="$cmd | $GIT_DIFF_PAGER"
+fi
+
eval "$cmd"
^ permalink raw reply related
* Re: Adding color to git diff output.
From: Junio C Hamano @ 2006-04-11 23:12 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP08B0DB32592225AAD0838AAECD0@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> Linus posted a colorize program a while back[1] but it wasn't taken into git.
> The patch below takes a different approach, adding a GIT_DIFF_PAGER variable.
> You can use it by assigning a filter to the environment variable, like so:
>
> export GIT_DIFF_PAGER="colordiff | less -RS"
Sounds like a nice idea, even maybe suitable in a FAQ.
Unfortunately colordiff does not seem to grok diff --cc output,
but that is fine ;-).
^ permalink raw reply
* Re: Adding color to git diff output.
From: Linus Torvalds @ 2006-04-12 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sean, git
In-Reply-To: <7virpf4sg4.fsf@assigned-by-dhcp.cox.net>
On Tue, 11 Apr 2006, Junio C Hamano wrote:
> sean <seanlkml@sympatico.ca> writes:
>
> > Linus posted a colorize program a while back[1] but it wasn't taken into git.
> > The patch below takes a different approach, adding a GIT_DIFF_PAGER variable.
> > You can use it by assigning a filter to the environment variable, like so:
> >
> > export GIT_DIFF_PAGER="colordiff | less -RS"
>
> Sounds like a nice idea, even maybe suitable in a FAQ.
> Unfortunately colordiff does not seem to grok diff --cc output,
> but that is fine ;-).
Well, the real problem - at least as far as my usage is concerned - is
that I'd want colorization to be more integrated so that it can be turned
off when not appropriate.
Think "colorized 'ls'", where if you enable colorization by default, it
only colorizes when the output is a tty, so that you can still script
things and output things to a file or so, without it getting colorized.
Because most "patch" programs (git-apply included) do not want to see
colorization ;)
So I'd suggest that the "git diff" script at a minimum first check whether
the output is to a tty before it decides to use GIT_DIFF_PAGER. With
perhaps an option to _force_ colorization if you want to.
Now, I don't actually enable ls-colorization by default, and I probably
wouldn't do it for git diff either, but at least for diffs I _might_. But
I'd definitely want it to be turned off automatically so that I can do
git diff .. > ~/patch-file
without having to remember to turn it off explicitly.
Linus
^ permalink raw reply
* Re: Adding color to git diff output.
From: sean @ 2006-04-12 0:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0604111725590.14565@g5.osdl.org>
On Tue, 11 Apr 2006 17:34:10 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 11 Apr 2006, Junio C Hamano wrote:
>
> > sean <seanlkml@sympatico.ca> writes:
> >
> > > Linus posted a colorize program a while back[1] but it wasn't taken into git.
> > > The patch below takes a different approach, adding a GIT_DIFF_PAGER variable.
> > > You can use it by assigning a filter to the environment variable, like so:
> > >
> > > export GIT_DIFF_PAGER="colordiff | less -RS"
> >
> > Sounds like a nice idea, even maybe suitable in a FAQ.
> > Unfortunately colordiff does not seem to grok diff --cc output,
> > but that is fine ;-).
>
> Well, the real problem - at least as far as my usage is concerned - is
> that I'd want colorization to be more integrated so that it can be turned
> off when not appropriate.
>
> Think "colorized 'ls'", where if you enable colorization by default, it
> only colorizes when the output is a tty, so that you can still script
> things and output things to a file or so, without it getting colorized.
>
> Because most "patch" programs (git-apply included) do not want to see
> colorization ;)
>
> So I'd suggest that the "git diff" script at a minimum first check whether
> the output is to a tty before it decides to use GIT_DIFF_PAGER. With
> perhaps an option to _force_ colorization if you want to.
>
> Now, I don't actually enable ls-colorization by default, and I probably
> wouldn't do it for git diff either, but at least for diffs I _might_. But
> I'd definitely want it to be turned off automatically so that I can do
>
> git diff .. > ~/patch-file
>
> without having to remember to turn it off explicitly.
>
What I have is a script ~/bin/gitcdiff:
#!/bin/sh
tty -s <&1 || exec cat
colordiff | less -RS
And then setting GIT_DIFF_PAGER="~/bin/gitcdiff". When piping to a file
it just uses cat, but when the output is a terminal device it uses the
colordiff.
I thought about integrating that logic into git-diff.sh, but i'm not sure
it's always appropriate.
Sean
^ permalink raw reply
* Re: Adding color to git diff output.
From: Linus Torvalds @ 2006-04-12 1:03 UTC (permalink / raw)
To: sean; +Cc: junkio, git
In-Reply-To: <BAYC1-PASMTP119CAD2588D00764DB3EA3AEC20@CEZ.ICE>
On Tue, 11 Apr 2006, sean wrote:
>
> What I have is a script ~/bin/gitcdiff:
>
> #!/bin/sh
> tty -s <&1 || exec cat
> colordiff | less -RS
>
> And then setting GIT_DIFF_PAGER="~/bin/gitcdiff". When piping to a file
> it just uses cat, but when the output is a terminal device it uses the
> colordiff.
>
> I thought about integrating that logic into git-diff.sh, but i'm not sure
> it's always appropriate.
Yeah, that's close to what I'd have suggested:
Linus
----
diff --git a/git-diff.sh b/git-diff.sh
index dc0dd31..f0bea80 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -69,4 +69,8 @@ case "$rev" in
;;
esac
+if [ "$GIT_DIFF_PAGER" ] && tty -s <&1; then
+ cmd="$cmd | $GIT_DIFF_PAGER"
+fi
+
eval "$cmd"
^ permalink raw reply related
* Re: Adding color to git diff output.
From: Junio C Hamano @ 2006-04-12 6:19 UTC (permalink / raw)
To: sean; +Cc: Linus Torvalds, git
In-Reply-To: <BAYC1-PASMTP119CAD2588D00764DB3EA3AEC20@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> What I have is a script ~/bin/gitcdiff:
>
> #!/bin/sh
> tty -s <&1 || exec cat
> colordiff | less -RS
>
> And then setting GIT_DIFF_PAGER="~/bin/gitcdiff". When piping to a file
> it just uses cat, but when the output is a terminal device it uses the
> colordiff.
>
> I thought about integrating that logic into git-diff.sh, but i'm not sure
> it's always appropriate.
What Linus posted seems sensible. And here is a hacked version
that is git-aware ;-).
-- >8 --
Subject: [PATCH] Add colordiff for git to contrib/colordiff.
I hacked it up to teach it the git extended diff headers, made
it not to read the whole patch in the array.
Also, the original program, when arguments are given, ran "diff"
with the given arguments and showed the output from it. Of
course, I changed it to run "git diff" ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
contrib/colordiff/README | 2
contrib/colordiff/colordiff.perl | 196 ++++++++++++++++++++++++++++++++++++++
2 files changed, 198 insertions(+), 0 deletions(-)
create mode 100644 contrib/colordiff/README
create mode 100755 contrib/colordiff/colordiff.perl
2ee04989119dd5c00e066f740efb8f2155d81ede
diff --git a/contrib/colordiff/README b/contrib/colordiff/README
new file mode 100644
index 0000000..2678fdf
--- /dev/null
+++ b/contrib/colordiff/README
@@ -0,0 +1,2 @@
+This is "colordiff" (http://colordiff.sourceforge.net/) by Dave
+Ewart <davee@sungate.co.uk>, modified specifically for git.
diff --git a/contrib/colordiff/colordiff.perl b/contrib/colordiff/colordiff.perl
new file mode 100755
index 0000000..37c3559
--- /dev/null
+++ b/contrib/colordiff/colordiff.perl
@@ -0,0 +1,196 @@
+#!/usr/bin/perl -w
+#
+# $Id: colordiff.pl,v 1.4.2.10 2004/01/04 15:02:59 daveewart Exp $
+
+########################################################################
+# #
+# ColorDiff - a wrapper/replacment for 'diff' producing #
+# colourful output #
+# #
+# Copyright (C)2002-2004 Dave Ewart (davee@sungate.co.uk) #
+# #
+########################################################################
+# #
+# This program is free software; you can redistribute it and/or modify #
+# it under the terms of the GNU General Public License as published by #
+# the Free Software Foundation; either version 2 of the License, or #
+# (at your option) any later version. #
+# #
+# This program is distributed in the hope that it will be useful, #
+# but WITHOUT ANY WARRANTY; without even the implied warranty of #
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #
+# GNU General Public License for more details. #
+# #
+# You should have received a copy of the GNU General Public License #
+# along with this program; if not, write to the Free Software #
+# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. #
+# #
+########################################################################
+
+use strict;
+use Getopt::Long qw(:config pass_through);
+use IPC::Open2;
+
+my $app_name = 'colordiff';
+my $version = '1.0.4';
+my $author = 'Dave Ewart';
+my $author_email = 'davee@sungate.co.uk';
+my $app_www = 'http://colordiff.sourceforge.net/';
+my $copyright = '(C)2002-2004';
+my $show_banner = 1;
+
+# ANSI sequences for colours
+my %colour;
+$colour{white} = "\033[1;37m";
+$colour{yellow} = "\033[1;33m";
+$colour{green} = "\033[1;32m";
+$colour{blue} = "\033[1;34m";
+$colour{cyan} = "\033[1;36m";
+$colour{red} = "\033[1;31m";
+$colour{magenta} = "\033[1;35m";
+$colour{black} = "\033[1;30m";
+$colour{darkwhite} = "\033[0;37m";
+$colour{darkyellow} = "\033[0;33m";
+$colour{darkgreen} = "\033[0;32m";
+$colour{darkblue} = "\033[0;34m";
+$colour{darkcyan} = "\033[0;36m";
+$colour{darkred} = "\033[0;31m";
+$colour{darkmagenta} = "\033[0;35m";
+$colour{darkblack} = "\033[0;30m";
+$colour{OFF} = "\033[0;0m";
+
+# Default colours if /etc/colordiffrc or ~/.colordiffrc do not exist
+my $plain_text = $colour{OFF};
+my $file_old = $colour{red};
+my $file_new = $colour{blue};
+my $diff_stuff = $colour{magenta};
+
+# Locations for personal and system-wide colour configurations
+my $HOME = $ENV{HOME};
+my $etcdir = '/etc';
+
+my ($setting, $value);
+my @config_files = ("$etcdir/colordiffrc", "$HOME/.colordiffrc");
+my $config_file;
+
+foreach $config_file (@config_files) {
+ if (open(COLORDIFFRC, "<$config_file")) {
+ while (<COLORDIFFRC>) {
+ chop;
+ next if (/^#/ || /^$/);
+ s/\s+//g;
+ ($setting, $value) = split ('=');
+ if ($setting eq 'banner') {
+ if ($value eq 'no') {
+ $show_banner = 0;
+ }
+ next;
+ }
+ if (!defined $colour{$value}) {
+ print "Invalid colour specification ($value) in $config_file\n";
+ next;
+ }
+ if ($setting eq 'plain') {
+ $plain_text = $colour{$value};
+ }
+ elsif ($setting eq 'oldtext') {
+ $file_old = $colour{$value};
+ }
+ elsif ($setting eq 'newtext') {
+ $file_new = $colour{$value};
+ }
+ elsif ($setting eq 'diffstuff') {
+ $diff_stuff = $colour{$value};
+ }
+ else {
+ print "Unknown option in $etcdir/colordiffrc: $setting\n";
+ }
+ }
+ close COLORDIFFRC;
+ }
+}
+
+# colordiff specfic options here. Need to pre-declare if using variables
+GetOptions(
+ "no-banner" => sub { $show_banner = 0 },
+ "plain-text=s" => \&set_color,
+ "file-old=s" => \&set_color,
+ "file-new=s" => \&set_color,
+ "diff-stuff=s" => \&set_color
+);
+
+if ($show_banner == 1) {
+ print STDERR "$app_name $version ($app_www)\n";
+ print STDERR "$copyright $author, $author_email\n\n";
+}
+
+if (defined $ARGV[0]) {
+ # More reliable way of pulling in arguments
+ open2(\*INPUTSTREAM, undef, "git", "diff", @ARGV);
+}
+else {
+ *INPUTSTREAM = \*STDIN;
+}
+
+my $record;
+my $nrecs = 0;
+my $inside_file_old = 1;
+my $nparents = undef;
+
+while (<INPUTSTREAM>) {
+ $nrecs++;
+ if (/^(\@\@+) -[-+0-9, ]+ \1/) {
+ print "$diff_stuff";
+ $nparents = length($1) - 1;
+ }
+ elsif (/^diff -/ || /^index / ||
+ /^old mode / || /^new mode / ||
+ /^deleted file mode / || /^new file mode / ||
+ /^similarity index / || /^dissimilarity index / ||
+ /^copy from / || /^copy to / ||
+ /^rename from / || /^rename to /) {
+ $nparents = undef;
+ print "$diff_stuff";
+ }
+ elsif (defined $nparents) {
+ if ($nparents == 1) {
+ if (/^\+/) {
+ print $file_new;
+ }
+ elsif (/^-/) {
+ print $file_old;
+ }
+ else {
+ print $plain_text;
+ }
+ }
+ elsif (/^ {$nparents}/) {
+ print "$plain_text";
+ }
+ elsif (/^[+ ]{$nparents}/) {
+ print "$file_new";
+ }
+ elsif (/^[- ]{$nparents}/) {
+ print "$file_old";
+ }
+ else {
+ print $plain_text;
+ }
+ }
+ elsif (/^--- / || /^\+\+\+ /) {
+ print $diff_stuff;
+ }
+ else {
+ print "$plain_text";
+ }
+ s/$/$colour{OFF}/;
+ print "$_";
+}
+close INPUTSTREAM;
+
+sub set_color {
+ my ($type, $color) = @_;
+
+ $type =~ s/-/_/;
+ eval "\$$type = \$colour{$color}";
+}
--
1.3.0.rc3.g72c1
^ permalink raw reply related
* Re: Adding color to git diff output.
From: Alex Riesen @ 2006-04-12 7:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, junkio, git
In-Reply-To: <Pine.LNX.4.64.0604111801270.14565@g5.osdl.org>
On 4/12/06, Linus Torvalds <torvalds@osdl.org> wrote:
> +if [ "$GIT_DIFF_PAGER" ] && tty -s <&1; then
Maybe use "-t" here? I have at least one system which has no tty installed.
Like this:
if [ -n "$GIT_DIFF_PAGER" -a -t ]; then
...
^ permalink raw reply
* how to make a git-format patch
From: Aubrey @ 2006-04-12 10:28 UTC (permalink / raw)
To: git
Hi list,
When I use GIT to generate a patch, I can use git-diff, if one file
changed, I can get the following patch:
=================================
diff --git a/net/packet/Kconfig b/net/packet/Kconfig
index 34ff93f..959c272 100644
--- a/net/packet/Kconfig
+++ b/net/packet/Kconfig
@@ -17,7 +17,7 @@ config PACKET
config PACKET_MMAP
bool "Packet socket: mmapped IO"
- depends on PACKET
+ depends on PACKET && MMU
help
If you say Y here, the Packet protocol driver will use an IO
mechanism that results in faster communication.
=================================
But I saw most of the git-format patches have a header in the front of
the patch file, like:
=================================
* Added xxxxxx support
Signed-off-by: xxxxxxxx <xxxxxxx@email.com>
---
net/packet/Kconfig | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/net/packet/Kconfig b/net/packet/Kconfig
index 34ff93f..959c272 100644
--- a/net/packet/Kconfig
+++ b/net/packet/Kconfig
----snip----
=================================
Just want to know how this kind of patch format generated.
Thanks for any hints.
Regards,
-Aubrey
^ permalink raw reply related
* Re: how to make a git-format patch
From: Jakub Narebski @ 2006-04-12 11:12 UTC (permalink / raw)
To: git
In-Reply-To: <6d6a94c50604120328ufa09f0do76c04472206ae15f@mail.gmail.com>
Aubrey wrote:
> But I saw most of the git-format patches have a header in the front of
> the patch file, like:
> =================================
> * Added xxxxxx support
>
> Signed-off-by: xxxxxxxx <xxxxxxx@email.com>
> ---
>
> net/packet/Kconfig | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/net/packet/Kconfig b/net/packet/Kconfig
> index 34ff93f..959c272 100644
> --- a/net/packet/Kconfig
> +++ b/net/packet/Kconfig
>
> ----snip----
> =================================
>
> Just want to know how this kind of patch format generated.
> Thanks for any hints.
Perhaps git-format-patch(1) is what you want?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Some Commit Messages Scare git-rev-list
From: Darrin Thompson @ 2006-04-12 13:11 UTC (permalink / raw)
To: git
This scripts exhibits some odd behavior. Apparently git-rev-list
mishandles commit messages which do not end in a newline. This as best I
can tell this is a problem introduced since 1.1.5.
Here is a script to reproduce the problem:
rm -rf git-test
mkdir git-test
cd git-test
git-init-db
echo hello > hello
git-add hello
# send scary message to git-commit -F -
echo -n "test commit" | git-commit -F - -a
echo world > world
git-add world
git-update-index --add world
treeid=$(git-write-tree)
# send scary message directly to git-commit-tree
commitid=$(echo -n "another-test" | git-commit-tree $treeid -p HEAD)
git-update-ref HEAD $commitid
# see the wreckage
git-rev-list --pretty HEAD
Running gitk will also show the problem.
--
Darrin
^ permalink raw reply
* Re: how to make a git-format patch
From: Mathieu Chouquet-Stringer @ 2006-04-12 14:04 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50604120328ufa09f0do76c04472206ae15f@mail.gmail.com>
aubreylee@gmail.com (Aubrey) writes:
> But I saw most of the git-format patches have a header in the front of
> the patch file, like:
I believe you're talking about 'git whatchanged -p' which not only displays
the diffs but also the commit comments.
--
Mathieu Chouquet-Stringer
^ permalink raw reply
* Re: Adding color to git diff output.
From: Linus Torvalds @ 2006-04-12 15:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: sean, junkio, git
In-Reply-To: <81b0412b0604120038q2e4aef8cn55ba4cfa68e18b34@mail.gmail.com>
On Wed, 12 Apr 2006, Alex Riesen wrote:
>
> Maybe use "-t" here? I have at least one system which has no tty installed.
> Like this:
>
> if [ -n "$GIT_DIFF_PAGER" -a -t ]; then
I assume you mean "-t 1". It needs the FD number. But yes.
Linus
^ permalink raw reply
* Re: Adding color to git diff output.
From: Alex Riesen @ 2006-04-12 15:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, junkio, git
In-Reply-To: <Pine.LNX.4.64.0604120846000.14565@g5.osdl.org>
On 4/12/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > Maybe use "-t" here? I have at least one system which has no tty installed.
> > Like this:
> >
> > if [ -n "$GIT_DIFF_PAGER" -a -t ]; then
>
> I assume you mean "-t 1". It needs the FD number. But yes.
>
yes, tpyo
(bash doesn't give an error here, btw. Just always 0)
^ permalink raw reply
* Re: Some Commit Messages Scare git-rev-list
From: Linus Torvalds @ 2006-04-12 17:23 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1144847462.5213.6.camel@localhost.localdomain>
On Wed, 12 Apr 2006, Darrin Thompson wrote:
>
> This scripts exhibits some odd behavior. Apparently git-rev-list
> mishandles commit messages which do not end in a newline. This as best I
> can tell this is a problem introduced since 1.1.5.
Fixed like so..
However, your script shows another problem: the "#" added at the end of
the line for a
echo -n "duh" | git-commit -F - -a
seems to be because we append the "git status" output to it, and then we
drop the lines that start with a '#', but due to the "-n", the first #
ends up being at the end of the line.
I suspect that when we get the commit message like that, we should _not_
do any of the commit message editing at all.
That's a separate issue, though, and not fixed by this patch.
Linus
---
diff --git a/commit.c b/commit.c
index d534c9b..c7bb8db 100644
--- a/commit.c
+++ b/commit.c
@@ -400,11 +400,11 @@ static int get_one_line(const char *msg,
while (len--) {
char c = *msg++;
+ if (!c)
+ break;
ret++;
if (c == '\n')
break;
- if (!c)
- return 0;
}
return ret;
}
^ permalink raw reply related
* Re: Some Commit Messages Scare git-rev-list
From: Junio C Hamano @ 2006-04-12 18:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Darrin Thompson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604121002220.14565@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Fixed like so..
Thanks.
> However, your script shows another problem: the "#" added at the end of
> the line for a
>
> echo -n "duh" | git-commit -F - -a
>
> seems to be because we append the "git status" output to it, and then we
> drop the lines that start with a '#', but due to the "-n", the first #
> ends up being at the end of the line.
>
> I suspect that when we get the commit message like that, we should _not_
> do any of the commit message editing at all.
True.
-- >8 --
[PATCH] git-commit: do not muck with commit message when no_edit is set.
Spotted by Linus and Darrin Thompson. When we took a commit
message from -F <file> with an incomplete line, we appended "git
status" output, which ended up attaching a lone "#" at the end.
We still need the "do we have anything to commit?" check by
running "status" (which has to know what to do in different
cases with -i/-o/-a), but there is no point appending its output
to the proposed commit message given by the user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit.sh | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
475443c8489d9167b944367d8ec8bfef77bee0a5
diff --git a/git-commit.sh b/git-commit.sh
index 1e7c09e..bd3dc71 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -537,7 +537,7 @@ t)
;;
esac
-if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
+if test -f "$GIT_DIR/MERGE_HEAD" && test -z "$no_edit"; then
echo "#"
echo "# It looks like you may be committing a MERGE."
echo "# If this is not correct, please remove the file"
@@ -605,16 +605,23 @@ else
current=
fi
-{
- test -z "$only_include_assumed" || echo "$only_include_assumed"
- run_status
-} >>"$GIT_DIR"/COMMIT_EDITMSG
+if test -z "$no_edit"
+then
+ {
+ test -z "$only_include_assumed" || echo "$only_include_assumed"
+ run_status
+ } >>"$GIT_DIR"/COMMIT_EDITMSG
+else
+ # we need to check if there is anything to commit
+ run_status >/dev/null
+fi
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" -a -z "$amend" ]
then
rm -f "$GIT_DIR/COMMIT_EDITMSG"
run_status
exit 1
fi
+
case "$no_edit" in
'')
case "${VISUAL:-$EDITOR},$TERM" in
--
1.3.0.rc3.g72c1
^ permalink raw reply related
* Re: [PATCH] Handle branch names with slashes
From: Yann Dirson @ 2006-04-12 19:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <tnxbqx6z592.fsf@arm.com>
On Fri, Feb 17, 2006 at 09:47:21AM +0000, Catalin Marinas wrote:
> Karl Hasselström <kha@treskal.com> wrote:
> > Let StGIT grok branch names with slashes in them. It used to fall flat
> > on its face when confronted with them.
>
> Thanks for the patches you sent. I'll have a look at them tomorrow.
Is this still being worked on ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Some Commit Messages Scare git-rev-list
From: Junio C Hamano @ 2006-04-12 19:39 UTC (permalink / raw)
To: git; +Cc: Darrin Thompson, Linus Torvalds
In-Reply-To: <7v3bgi4op7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> We still need the "do we have anything to commit?" check by
> running "status" (which has to know what to do in different
> cases with -i/-o/-a), but there is no point appending its output
> to the proposed commit message given by the user.
BTW, this does not quite work as expected if you did something
like this:
echo -n 'incomplete line' | git commit -a -s -F -
because we would want to append the Signed-off-by: line. I am
almost tempted to say "then do not do it", but it might make
sense to do this as well.
-- >8 --
[PATCH] stripspace: make sure not to leave an incomplete line.
When dealing with a commit log message for human consumption, it
never makes sense to keep a log that ends with an incomplete
line, so make it a part of the clean-up process done with
git-stripspace.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/stripspace.c b/stripspace.c
index 96cd0a8..dee1ef0 100644
--- a/stripspace.c
+++ b/stripspace.c
@@ -6,9 +6,9 @@ #include <ctype.h>
* Remove empty lines from the beginning and end.
*
* Turn multiple consecutive empty lines into just one
- * empty line.
+ * empty line. Return true if it is an incomplete line.
*/
-static void cleanup(char *line)
+static int cleanup(char *line)
{
int len = strlen(line);
@@ -21,16 +21,19 @@ static void cleanup(char *line)
len--;
line[len] = 0;
} while (len > 1);
+ return 0;
}
+ return 1;
}
int main(int argc, char **argv)
{
int empties = -1;
+ int incomplete = 0;
char line[1024];
while (fgets(line, sizeof(line), stdin)) {
- cleanup(line);
+ incomplete = cleanup(line);
/* Not just an empty line? */
if (line[0] != '\n') {
@@ -44,5 +47,7 @@ int main(int argc, char **argv)
continue;
empties++;
}
+ if (incomplete)
+ putchar('\n');
return 0;
}
^ permalink raw reply related
* Re: Some Commit Messages Scare git-rev-list
From: Linus Torvalds @ 2006-04-12 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Darrin Thompson
In-Reply-To: <7vy7ya37o2.fsf@assigned-by-dhcp.cox.net>
On Wed, 12 Apr 2006, Junio C Hamano wrote:
>
> [PATCH] stripspace: make sure not to leave an incomplete line.
Ack.
Linus
^ permalink raw reply
* [PATCH 0/3] Add a testsuite to stgit
From: Yann Dirson @ 2006-04-12 21:16 UTC (permalink / raw)
To: git
The following steals the testsuite system from git-core and adapts it to stgit,
adds a couple of items to the TODO file, and adds a first testsuite to
demonstrate a problem with branch renaming, to serve as a non-reg test.
To run the testsuite, just "make -C t", there is no integration in the python-generated
toplevel Makefile.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ 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