* 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
* 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: 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
* 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: 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
* 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: 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: 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 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: 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
* 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: 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
* 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
* 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: [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
* 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: 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
* t5501-old-fetch-and-upload.sh fails with NO_PYTHON=1
From: Dennis Stosberg @ 2006-04-11 17:05 UTC (permalink / raw)
To: git
Hello,
t/t5501-old-fetch-and-upload.sh fails on Solaris 9 with NO_PYTHON=1.
The test doesn't work correctly on Linux with NO_PYTHON=1, too, but it
doesn't cause a failure there.
When NO_PYTHON=1 is set, t/Makefile passes "--no-python" to the test as
an argument. That causes the $list variable to be set to "--no-python"
instead of "fetch upload". Since that string does not identify a
program to be tested, $pgm remains unset.
On Linux the return code of "which $pgm" is 1 in that case, which
causes the test to do nothing and exit without failure. In contrast,
the return code of "which" without any argument is 0 on Solaris, so
the test is being run and fails.
I have attached a simple fix, but is this test still useful at all?
Regards,
Dennis
diff --git a/t/t5501-old-fetch-and-upload.sh b/t/t5501-old-fetch-and-upload.sh
index 596c88b..df69d97 100755
--- a/t/t5501-old-fetch-and-upload.sh
+++ b/t/t5501-old-fetch-and-upload.sh
@@ -13,10 +13,11 @@ tmp=`pwd`/.tmp$$
retval=0
-if [ -z "$1" ]; then
+tests=`echo "$@"| sed -e 's/--[a-zA-Z\-]*//g'`
+if [ -z "$tests" ]; then
list="fetch upload"
else
- list="$@"
+ list="$tests"
fi
for i in $list; do
^ permalink raw reply related
* Build fixes for Solaris 9
From: Dennis Stosberg @ 2006-04-11 16:37 UTC (permalink / raw)
To: git
Hello,
The attached patch allows git to be built on Solaris 9, which does
not have setenv() and unsetenv().
Also, Solaris needs strings.h for index(). A few days ago there was
a thread about this on the list and the result was that strchr() is
more portable than index() and is used everywhere in git anyway. So
instead of including strings.h, this patch replaces all remaining
calls to index() by strchr().
Regards,
Dennis
diff --git a/Makefile b/Makefile
index c0409f3..ff645d8 100644
--- a/Makefile
+++ b/Makefile
@@ -248,6 +248,10 @@ ifeq ($(uname_S),SunOS)
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
endif
+ ifeq ($(uname_R),5.9)
+ NO_UNSETENV = YesPlease
+ NO_SETENV = YesPlease
+ endif
INSTALL = ginstall
TAR = gtar
ALL_CFLAGS += -D__EXTENSIONS__
diff --git a/http-fetch.c b/http-fetch.c
index 71a7daf..861644b 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -597,7 +597,7 @@ static void process_alternates_response(
newalt->packs = NULL;
path = strstr(target, "//");
if (path) {
- path = index(path+2, '/');
+ path = strchr(path+2, '/');
if (path)
newalt->path_len = strlen(path);
}
@@ -678,7 +678,7 @@ static void
xml_start_tag(void *userData, const char *name, const char **atts)
{
struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = index(name, ':');
+ const char *c = strchr(name, ':');
int new_len;
if (c == NULL)
@@ -707,7 +707,7 @@ static void
xml_end_tag(void *userData, const char *name)
{
struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = index(name, ':');
+ const char *c = strchr(name, ':');
char *ep;
ctx->userFunc(ctx, 1);
@@ -1261,7 +1261,7 @@ int main(int argc, char **argv)
alt->next = NULL;
path = strstr(url, "//");
if (path) {
- path = index(path+2, '/');
+ path = strchr(path+2, '/');
if (path)
alt->path_len = strlen(path);
}
diff --git a/http-push.c b/http-push.c
index 57cefde..994ee90 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1211,7 +1211,7 @@ static void
xml_start_tag(void *userData, const char *name, const char **atts)
{
struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = index(name, ':');
+ const char *c = strchr(name, ':');
int new_len;
if (c == NULL)
@@ -1240,7 +1240,7 @@ static void
xml_end_tag(void *userData, const char *name)
{
struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = index(name, ':');
+ const char *c = strchr(name, ':');
char *ep;
ctx->userFunc(ctx, 1);
@@ -2350,7 +2350,7 @@ int main(int argc, char **argv)
char *path = strstr(arg, "//");
remote->url = arg;
if (path) {
- path = index(path+2, '/');
+ path = strchr(path+2, '/');
if (path)
remote->path_len = strlen(path);
}
^ permalink raw reply related
* Re: What's in git.git
From: Petr Baudis @ 2006-04-11 15:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604110645060.3722@g5.osdl.org>
Dear diary, on Tue, Apr 11, 2006 at 03:50:14PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> 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.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-04-11 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgk7mhy.fsf@assigned-by-dhcp.cox.net>
On Mon, 10 Apr 2006, Junio C Hamano wrote:
>
> Retire git-log.sh
> Retire git-log.sh (take#2)
I think you need a (take#3).
This creates "git-log" as a link to "git", but does so at _build_ time,
not install time.
Which means that when it actually gets installed, it gets installed as a
copy of that link, and you get two different executables instead of one
single executable that is just linked to two names:
[torvalds@g5 git]$ ls -li /home/torvalds/bin/git ~/bin/git-log
67272830 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git
67272781 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git-log
so it _works_, but it wastes 300kB+ for each "builtin". Which was kind of
against the whole point.
I think the builtins should be a install-time only issue.
Linus
^ permalink raw reply
* [PATCH] Separate the raw diff and patch with a newline
From: Petr Baudis @ 2006-04-11 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7456jb4.fsf@assigned-by-dhcp.cox.net>
More friendly for human reading I believe, and possibly friendlier to some
parsers (although only by an epsilon).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
combine-diff.c | 1 +
diff.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 748dc30..0e25788 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -867,6 +867,7 @@ const char *diff_tree_combined_merge(con
header = NULL;
}
opt->output_format = DIFF_FORMAT_PATCH;
+ putchar(opt->line_termination);
}
for (p = paths; p; p = p->next) {
if (show_combined_diff(p, num_parent, dense,
diff --git a/diff.c b/diff.c
index 00c79aa..86e4251 100644
--- a/diff.c
+++ b/diff.c
@@ -1322,6 +1322,7 @@ void diff_flush(struct diff_options *opt
struct diff_filepair *p = q->queue[i];
flush_one_pair(p, DIFF_FORMAT_RAW, options);
}
+ putchar(options->line_termination);
}
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
^ permalink raw reply related
* [PATCH] Rename --with-raw to --patch-with-raw and document it
From: Petr Baudis @ 2006-04-11 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7456jb4.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/diff-options.txt | 3 +++
diff.c | 2 +-
diff.h | 2 ++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index ec6811c..338014c 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -4,6 +4,9 @@
-u::
Synonym for "-p".
+--patch-with-raw::
+ Generate patch but keep also the default raw diff output.
+
-z::
\0 line termination on output
diff --git a/diff.c b/diff.c
index 12924f2..00c79aa 100644
--- a/diff.c
+++ b/diff.c
@@ -862,7 +862,7 @@ int diff_opt_parse(struct diff_options *
const char *arg = av[0];
if (!strcmp(arg, "-p") || !strcmp(arg, "-u"))
options->output_format = DIFF_FORMAT_PATCH;
- else if (!strcmp(arg, "--with-raw")) {
+ else if (!strcmp(arg, "--patch-with-raw")) {
options->output_format = DIFF_FORMAT_PATCH;
options->with_raw = 1;
}
diff --git a/diff.h b/diff.h
index 07b153b..c5372b9 100644
--- a/diff.h
+++ b/diff.h
@@ -113,6 +113,8 @@ #define COMMON_DIFF_OPTIONS_HELP \
" -z output diff-raw with lines terminated with NUL.\n" \
" -p output patch format.\n" \
" -u synonym for -p.\n" \
+" --patch-with-raw\n" \
+" output both a patch and the diff-raw format.\n" \
" --name-only show only names of changed files.\n" \
" --name-status show names and status of changed files.\n" \
" --full-index show full object name on index lines.\n" \
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-04-11 4:40 UTC (permalink / raw)
To: git
No real 1.3.0 yet...
* The 'master' branch has these since the last announcement.
All of them are fixes and clean-ups (except --parents stuff
from Linus which seems safe enough).
Junio C Hamano:
git-log: match rev-list --abbrev and --abbrev-commit
diff: fix output of total-rewrite diff.
diffcore-rename: fix merging back a broken pair.
Retire diffcore-pathspec.
Retire git-log.sh
Retire git-log.sh (take#2)
Linus Torvalds:
Make "--parents" logs also be incremental
Marco Roeland:
xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
Petr Baudis:
Improve the git-diff-tree -c/-cc documentation
* The 'next' branch, in addition, has these.
- diff-* --patch-with-raw
- Implement limited context matching in git-apply (Eric W. Biederman)
- log-tree: separate major part of diff-tree.
- git log [diff-tree options]...
I should not be moving anything new from "next" to "master"
before 1.3.0, but I am inclined to include the --patch-with-raw
change, which Cogito wants. Also apply -Cn by Eric seems safe
enough; as long as you do not ask for it, it keeps the existing
behaviour. The initial part of "git log with diff-tree options"
seems safe enough so it is also in 'next'.
I have the rest of "git log with diff-tree options", along with
its fallouts, which turned out to be more than what I wanted to
see, in "pu".
^ permalink raw reply
* Re: [PATCH] git log [diff-tree options]...
From: Randal L. Schwartz @ 2006-04-11 0:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060411003126.GX27689@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> Dear diary, on Tue, Apr 11, 2006 at 02:12:11AM CEST, I got a letter
Petr> where Junio C Hamano <junkio@cox.net> said that...
>> There is no reason for them to be *absolutely* identical
Petr> One is that people expect them to be. It's been implied that "git xyzzy"
Petr> is functionally fully equivalent to "git-xyzzy" for too long to silently
Petr> break this now.
Yes, this is what I was referencing. I would *never* have considered
that git-log and "git log" be different things now that it's been firmly
engrained that they are the same. Please don't violate the model.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
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