* Resurrecting symlink problem
From: dormando @ 2006-06-22 23:00 UTC (permalink / raw)
To: git
Hey,
We have an issue with cogito/git and not being able to remove symlinks
from a central remote repo.
First try: cg-rm symlinks*
Complains that I'm trying to delete directories without the -r option.
So it's resolving the symlinks to the target directory.
git rm -f symlinks*
works. Symlinks are gone, push to repo, everything's happy.
However:
user A git rm -f's the symlinks, pushes to origin
user B cg-update's, then cg-commit's, cg-push's a one line change in an
unrelated file.
user A cg-update's, and the symlinks come back.
This happens over and over. They appear to disappear if cg-update does a
fast forward, but not if it does a merge. Any suggestions on how to
resolve this issue?
I'm still looking at what exactly is going on when user B does that
cg-update.
Thanks,
-Dormando
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 22:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v7j38j144.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Well, I admit I do not use colorized diffs myself. As a matter
> of fact, I use specialized terminfo to disable coloring on my
> terminal session, since fontifying in GNUS otherwise gives me
> unreadable screen and I am too lazy to figure out how to turn it
> off.
>
> I do however usually test colored stuff with at least white and
> black backgrounds,
By the way, in the ancient history, in commit 3443546 you did:
--- a/Makefile
+++ b/Makefile
@@ -544,12 +545,18 @@ init-db.o: init-db.c
-DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c
$(LIB_OBJS): $(LIB_H)
-$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H)
+$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIBS)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
which we kept until today. This causes checkout-index.o and
friends to be recompiled when we touch diff.c (I do not mind
relinking git-checkout-index because libgit.a has changed, but
recompiling checkout-index.c is unneeded). I think this was
done to make sure anything that includes xdiff/*.h files via
"xdiff-interface.h" are recompiled when xdiff/*.h are changed,
so I am thinking about loosening it a bit to depend on our
headers and xdiff/*.h headers, perhaps like this:
diff --git a/Makefile b/Makefile
index a5b6784..e29e3fa 100644
--- a/Makefile
+++ b/Makefile
@@ -582,7 +582,7 @@ git-http-push$X: revision.o http.o http-
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
-$(patsubst git-%$X,%.o,$(PROGRAMS)): $(GITLIBS)
+$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
diff --git a/diff.c b/diff.c
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
^ permalink raw reply related
* [PATCH] Git.pm: Implement Git::exec_path()
From: Petr Baudis @ 2006-06-22 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch implements Git::exec_path() (as a direct XS call).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.pm | 20 +++++++++++++++++++-
perl/Git.xs | 10 ++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 4bb7c50..516c065 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -47,7 +47,8 @@ require Exporter;
@EXPORT = qw();
# Methods which can be called as standalone functions as well:
-@EXPORT_OK = qw(command command_oneline command_pipe command_noisy);
+@EXPORT_OK = qw(command command_oneline command_pipe command_noisy
+ exec_path hash_object);
=head1 DESCRIPTION
@@ -213,6 +214,7 @@ sub command {
}
}
+
=item command_oneline ( COMMAND [, ARGUMENTS... ] )
Execute the given C<COMMAND> in the same way as command()
@@ -231,6 +233,7 @@ sub command_oneline {
return $line;
}
+
=item command_pipe ( COMMAND [, ARGUMENTS... ] )
Execute the given C<COMMAND> in the same way as command()
@@ -253,6 +256,7 @@ sub command_pipe {
return $fh;
}
+
=item command_noisy ( COMMAND [, ARGUMENTS... ] )
Execute the given C<COMMAND> in the same way as command() does but do not
@@ -283,6 +287,20 @@ sub command_noisy {
}
}
+
+=item exec_path ()
+
+Return path to the git sub-command executables (the same as
+C<git --exec-path>). Useful mostly only internally.
+
+Implementation of this function is very fast; no external command calls
+are involved.
+
+=cut
+
+# Implemented in Git.xs.
+
+
=item hash_object ( FILENAME [, TYPE ] )
=item hash_object ( FILEHANDLE [, TYPE ] )
diff --git a/perl/Git.xs b/perl/Git.xs
index 33bb3ca..d1f94a4 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -6,6 +6,7 @@ #include <ctype.h>
/* libgit interface */
#include "../cache.h"
+#include "../exec_cmd.h"
/* XS and Perl interface */
#include "EXTERN.h"
@@ -19,6 +20,15 @@ MODULE = Git PACKAGE = Git
# /* TODO: xs_call_gate(). See Git.pm. */
+
+const char *
+xs_exec_path()
+CODE:
+ RETVAL = git_exec_path();
+OUTPUT:
+ RETVAL
+
+
char *
xs_hash_object(file, type = "blob")
SV *file;
^ permalink raw reply related
* stgit: bunch of bugreports/wishes
From: Yann Dirson @ 2006-06-22 22:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
Here are a number of problems I encountered while playing with
uncommit with 0.10:
- uncommit ignores grafts. This causes "uncommit -n" to through
"graft merges" without asking, and surely gives unexpected result
when a graft is used to change an ancestor rather than adding one.
- the previous behaviour causes strange interactions with merge
commits (eg. "stg show" cannot show the diff)
- uncommit could allow to go through a merge (indeed ignoring grafts
as it did was a gain of time for me, since it was in a couple of cases
precisely what I wanted to do ;). One possible interface to such a
feature would be to allow this if HEAD is the merge, and the branch to
follow is explicitely specified. The issue mentionned above seems to
indicate that when uncommitting a merge, a new commit for the
newly-uncommitted patch has to be created right away, to ensure it has
a single parent.
- uncommit could be more flexible to help with mass-uncommitting,
eg. with something like "--to <commit>" (to avoid counting manually),
or "--to-merge" to cleanly stop on first merge instead of failing
there. This may have an impact on how uncommits are numbered.
- uncommit synopsis is incomplete (lacks " | -n <n> <basename>")
- after mass-uncommitting, more help to look at the stack would be
needed. Eg. a "stg series" flag to print more commit info (author,
files), or to limit the listing to a given author (like "stg patches"
limits for a file).
Additionally, a couple of non-uncommit-related thing:
- when a push is not committed because of a conflict, looking at the
previous diff for the patch would help. Maybe something like "stg
show --old" ?
- the help string for push should say "patches", and possibly document
more precisely the syntax, something like:
--- a/stgit/commands/push.py
+++ b/stgit/commands/push.py
@@ -24,8 +24,8 @@ from stgit.utils import *
from stgit import stack, git
-help = 'push a patch on top of the series'
-usage = """%prog [options] [<patch1> [<patch2>...]]
+help = 'push patches on top of the series'
+usage = """%prog [options] [<patch1> [<patch2>...] | -n <n> <patchroot>]
Push a patch (defaulting to the first unapplied one) or range of
patches to the stack. The 'push' operation allows patch reordering by
- "push --undo" is not robust. On the occasion reproduced below, I
had to rollback the push myself by hand-modifying the stgit data,
which took me some effort. I'll have to gather precise info, but the
issue occurs on patch reordering, on a genuine conflict, and seems to
be involve a change to a non-existent file, when that file would have
been added by a non-applied patch originally below the one I attempted
to apply.
I do agree there is a conflict, but "push --undo" should definitely be
able to rollback in any case.
Here is the log:
========
Now at patch "patch9"
Pushing patch "patch10"...The merge failed during "push". Use "refresh"
after fixing the conflicts
stg push: GIT index merging failed (possible conflicts)
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
stg push: local changes in the tree. Use "refresh" to commit them
ydirson$ stg push --undo
Undoing the "patch10" push...stg push: ['git-diff-index', 'HEAD', 'path/to/the/file.java'] failed (fatal: ambiguous argument
'path/to/the/file.java': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions)
========
Best regards,
--
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: What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 22:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606221301500.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 22 Jun 2006, Junio C Hamano wrote:
>>
>> - diff --color (Johannes).
>
> I like colorized diffs, but let's face it, those particular color choices
> will make most people decide to pick out their eyes with a fondue fork.
Well, I admit I do not use colorized diffs myself. As a matter
of fact, I use specialized terminfo to disable coloring on my
terminal session, since fontifying in GNUS otherwise gives me
unreadable screen and I am too lazy to figure out how to turn it
off.
I do however usually test colored stuff with at least white and
black backgrounds,
> This patch does:
>
> - always reset the color _before_ printing out the newline.
Sorry, although I did notice this (interrupting a long diff, or
running it with "less -r" and quitting it would leave the
terminal in funny color), I did not bother to fix it.
> - default to red/green for old/new lines. That's the norm, I'd think.
OK.
> - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping)
> purple color for metadata, use bold-face for file headers, and cyan for
> the frag headers. I actually prefer the "gray background" for that, but
> it only works well in xterms, so COLOR_CYAN it is..
Replacing it with COLOR_GRAYBG did not work out too well with
either xterm nor kterm for me, although it did work under
gnome-terminal.
Cyan foreground color is unreadable on white background and that
was why I did magenta in my original patch, but it may be just
that I am color challenged in that spectrum.
^ permalink raw reply
* [PATCH] Introduce Git.pm (v3)
From: Petr Baudis @ 2006-06-22 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch introduces a very basic and barebone Git.pm module
with a sketch of how the generic interface would look like;
most functions are missing, but this should give some good base.
I will continue expanding it.
Most desirable now is more careful error reporting, generic_in() for feeding
input to Git commands and the repository() constructor doing some poking
with git-rev-parse to get the git directory and subdirectory prefix.
Those three are basically the prerequisities for converting git-mv.
Currently Git.pm just wraps up exec()s of Git commands, but even that
is not trivial to get right and various Git perl scripts do it in
various inconsistent ways. In addition to Git.pm, there is now also
Git.xs which provides barebone Git.xs for directly interfacing with
libgit.a, and as an example providing the hash_object() function using
libgit.
This adds the Git module, integrates it to the build system and as
an example converts the git-fmt-merge-msg.perl script to it (the result
is not very impressive since its advantage is not quite apparent in this
one, but I just picked up the simplest Git user around).
The changes since v1 are:
* s/generic/command/ in the API, added command_pipe() and
changed behaviour of command() in the scalar context
* Added hash_object() and Git.xs providing the fast implementation
* Better error reporting
* Plenty of random minor stuff
It's a good thing v2 didn't make it to the list since it contained a huge
file which turns out that can be autogenerated at the build time, so v3
just changes that (and adds .gitignore file and makes some other minor
changes).
I consider this patch "stable" now. Further enhancements will be posted
as patches on top of this.
My current working state is available all the time at
http://pasky.or.cz/~xpasky/git-perl/Git.pm
and an irregularily updated API documentation is at
http://pasky.or.cz/~xpasky/git-perl/Git.html
Many thanks to Jakub Narebski, Junio and others for their feedback.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 12 +
git-fmt-merge-msg.perl | 10 +
perl/.gitignore | 7 +
perl/Git.pm | 401 ++++++++++++++++++++++++++++++++++++++++++++++++
perl/Git.xs | 60 +++++++
perl/Makefile.PL | 21 +++
6 files changed, 504 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index a5b6784..4d20b22 100644
--- a/Makefile
+++ b/Makefile
@@ -476,7 +476,8 @@ ### Build rules
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk
-all:
+all: perl/Makefile
+ $(MAKE) -C perl
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@@ -508,7 +509,7 @@ common-cmds.h: Documentation/git-*.txt
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
rm -f $@ $@+
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@+
chmod +x $@+
@@ -594,6 +595,9 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
+perl/Makefile: perl/Git.pm perl/Makefile.PL
+ (cd perl && $(PERL_PATH) Makefile.PL PREFIX="$(prefix)" DEFINE="$(ALL_CFLAGS)" LIBS="$(LIBS)")
+
doc:
$(MAKE) -C Documentation all
@@ -649,6 +653,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates install
+ $(MAKE) -C perl install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
@@ -716,7 +721,8 @@ clean:
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
$(MAKE) -C Documentation/ clean
- $(MAKE) -C templates clean
+ [ ! -e perl/Makefile ] || $(MAKE) -C perl/ clean
+ $(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 5986e54..c32cafb 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -6,6 +6,9 @@ # Read .git/FETCH_HEAD and make a human
# by grouping branches and tags together to form a single line.
use strict;
+use Git;
+
+my $repo = Git->repository();
my @src;
my %src;
@@ -28,13 +31,12 @@ sub andjoin {
}
sub repoconfig {
- my ($val) = qx{git-repo-config --get merge.summary};
+ my ($val) = $repo->command_oneline('repo-config', '--get', 'merge.summary');
return $val;
}
sub current_branch {
- my ($bra) = qx{git-symbolic-ref HEAD};
- chomp($bra);
+ my ($bra) = $repo->command_oneline('symbolic-ref', 'HEAD');
$bra =~ s|^refs/heads/||;
if ($bra ne 'master') {
$bra = " into $bra";
@@ -47,7 +49,7 @@ sub current_branch {
sub shortlog {
my ($tip) = @_;
my @result;
- foreach ( qx{git-log --no-merges --topo-order --pretty=oneline $tip ^HEAD} ) {
+ foreach ($repo->command('log', '--no-merges', '--topo-order', '--pretty=oneline', $tip, '^HEAD')) {
s/^[0-9a-f]{40}\s+//;
push @result, $_;
}
diff --git a/perl/.gitignore b/perl/.gitignore
new file mode 100644
index 0000000..6d778f3
--- /dev/null
+++ b/perl/.gitignore
@@ -0,0 +1,7 @@
+Git.bs
+Git.c
+Makefile
+blib
+blibdirs
+pm_to_blib
+ppport.h
diff --git a/perl/Git.pm b/perl/Git.pm
new file mode 100644
index 0000000..4bb7c50
--- /dev/null
+++ b/perl/Git.pm
@@ -0,0 +1,401 @@
+=head1 NAME
+
+Git - Perl interface to the Git version control system
+
+=cut
+
+
+package Git;
+
+use strict;
+
+
+BEGIN {
+
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
+
+# Totally unstable API.
+$VERSION = '0.01';
+
+
+=head1 SYNOPSIS
+
+ use Git;
+
+ my $version = Git::command_oneline('version');
+
+ Git::command_noisy('update-server-info');
+
+ my $repo = Git->repository (Directory => '/srv/git/cogito.git');
+
+
+ my @revs = $repo->command('rev-list', '--since=last monday', '--all');
+
+ my $fh = $repo->command_pipe('rev-list', '--since=last monday', '--all');
+ my $lastrev = <$fh>; chomp $lastrev;
+ close $fh; # You may want to test rev-list exit status here
+
+ my $lastrev = $repo->command_oneline('rev-list', '--all');
+
+=cut
+
+
+require Exporter;
+
+@ISA = qw(Exporter);
+
+@EXPORT = qw();
+
+# Methods which can be called as standalone functions as well:
+@EXPORT_OK = qw(command command_oneline command_pipe command_noisy);
+
+
+=head1 DESCRIPTION
+
+This module provides Perl scripts easy way to interface the Git version control
+system. The modules have an easy and well-tested way to call arbitrary Git
+commands; in the future, the interface will also provide specialized methods
+for doing easily operations which are not totally trivial to do over
+the generic command interface.
+
+While some commands can be executed outside of any context (e.g. 'version'
+or 'init-db'), most operations require a repository context, which in practice
+means getting an instance of the Git object using the repository() constructor.
+(In the future, we will also get a new_repository() constructor.) All commands
+called as methods of the object are then executed in the context of the
+repository.
+
+TODO: In the future, we might also do
+
+ my $subdir = $repo->subdir('Documentation');
+ # Gets called in the subdirectory context:
+ $subdir->command('status');
+
+ my $remoterepo = $repo->remote_repository (name => 'cogito', branch => 'master');
+ $remoterepo ||= Git->remote_repository ('http://git.or.cz/cogito.git/');
+ my @refs = $remoterepo->refs();
+
+So far, all functions just die if anything goes wrong. If you don't want that,
+make appropriate provisions to catch the possible deaths. Better error recovery
+mechanisms will be provided in the future.
+
+Currently, the module merely wraps calls to external Git tools. In the future,
+it will provide a much faster way to interact with Git by linking directly
+to libgit. This should be completely opaque to the user, though (performance
+increate nonwithstanding).
+
+=cut
+
+
+use Carp qw(carp croak);
+
+require XSLoader;
+XSLoader::load('Git', $VERSION);
+
+}
+
+
+=head1 CONSTRUCTORS
+
+=over 4
+
+=item repository ( OPTIONS )
+
+=item repository ( DIRECTORY )
+
+=item repository ()
+
+Construct a new repository object.
+C<OPTIONS> are passed in a hash like fashion, using key and value pairs.
+Possible options are:
+
+B<Repository> - Path to the Git repository.
+
+B<WorkingCopy> - Path to the associated working copy; not strictly required
+as many commands will happily crunch on a bare repository.
+
+B<Directory> - Path to the Git working directory in its usual setup. This
+is just for convenient setting of both C<Repository> and C<WorkingCopy>
+at once: If the directory as a C<.git> subdirectory, C<Repository> is pointed
+to the subdirectory and the directory is assumed to be the working copy.
+If the directory does not have the subdirectory, C<WorkingCopy> is left
+undefined and C<Repository> is pointed to the directory itself.
+
+B<GitPath> - Path to the C<git> binary executable. By default the C<$PATH>
+is searched for it.
+
+You should not use both C<Directory> and either of C<Repository> and
+C<WorkingCopy> - the results of that are undefined.
+
+Alternatively, a directory path may be passed as a single scalar argument
+to the constructor; it is equivalent to setting only the C<Directory> option
+field.
+
+Calling the constructor with no options whatsoever is equivalent to
+calling it with C<< Directory => '.' >>.
+
+=cut
+
+sub repository {
+ my $class = shift;
+ my @args = @_;
+ my %opts = ();
+ my $self;
+
+ if (defined $args[0]) {
+ if ($#args % 2 != 1) {
+ # Not a hash.
+ $#args == 0 or croak "bad usage";
+ %opts = (Directory => $args[0]);
+ } else {
+ %opts = @args;
+ }
+
+ if ($opts{Directory}) {
+ -d $opts{Directory} or croak "Directory not found: $!";
+ if (-d $opts{Directory}."/.git") {
+ # TODO: Might make this more clever
+ $opts{WorkingCopy} = $opts{Directory};
+ $opts{Repository} = $opts{Directory}."/.git";
+ } else {
+ $opts{Repository} = $opts{Directory};
+ }
+ delete $opts{Directory};
+ }
+ }
+
+ $self = { opts => \%opts };
+ bless $self, $class;
+}
+
+
+=back
+
+=head1 METHODS
+
+=over 4
+
+=item command ( COMMAND [, ARGUMENTS... ] )
+
+Execute the given Git C<COMMAND> (specify it without the 'git-'
+prefix), optionally with the specified extra C<ARGUMENTS>.
+
+The method can be called without any instance or on a specified Git repository
+(in that case the command will be run in the repository context).
+
+In scalar context, it returns all the command output in a single string
+(verbatim).
+
+In array context, it returns an array containing lines printed to the
+command's stdout (without trailing newlines).
+
+In both cases, the command's stdin and stderr are the same as the caller's.
+
+=cut
+
+sub command {
+ my $fh = command_pipe(@_);
+
+ if (not defined wantarray) {
+ _cmd_close($fh);
+
+ } elsif (not wantarray) {
+ local $/;
+ my $text = <$fh>;
+ _cmd_close($fh);
+ return $text;
+
+ } else {
+ my @lines = <$fh>;
+ _cmd_close($fh);
+ chomp @lines;
+ return @lines;
+ }
+}
+
+=item command_oneline ( COMMAND [, ARGUMENTS... ] )
+
+Execute the given C<COMMAND> in the same way as command()
+does but always return a scalar string containing the first line
+of the command's standard output.
+
+=cut
+
+sub command_oneline {
+ my $fh = command_pipe(@_);
+
+ my $line = <$fh>;
+ _cmd_close($fh);
+
+ chomp $line;
+ return $line;
+}
+
+=item command_pipe ( COMMAND [, ARGUMENTS... ] )
+
+Execute the given C<COMMAND> in the same way as command()
+does but return a pipe filehandle from which the command output can be
+read.
+
+=cut
+
+sub command_pipe {
+ my ($self, $cmd, @args) = _maybe_self(@_);
+
+ $cmd =~ /^[a-z0-9A-Z_-]+$/ or croak "bad command: $cmd";
+
+ my $pid = open(my $fh, "-|");
+ if (not defined $pid) {
+ croak "open failed: $!";
+ } elsif ($pid == 0) {
+ _cmd_exec($self, $cmd, @args);
+ }
+ return $fh;
+}
+
+=item command_noisy ( COMMAND [, ARGUMENTS... ] )
+
+Execute the given C<COMMAND> in the same way as command() does but do not
+capture the command output - the standard output is not redirected and goes
+to the standard output of the caller application.
+
+While the method is called command_noisy(), you might want to as well use
+it for the most silent Git commands which you know will never pollute your
+stdout but you want to avoid the overhead of the pipe setup when calling them.
+
+The function returns only after the command has finished running.
+
+=cut
+
+sub command_noisy {
+ my ($self, $cmd, @args) = _maybe_self(@_);
+
+ $cmd =~ /^[a-z0-9A-Z_-]+$/ or croak "bad command: $cmd";
+
+ my $pid = fork;
+ if (not defined $pid) {
+ croak "fork failed: $!";
+ } elsif ($pid == 0) {
+ _cmd_exec($self, $cmd, @args);
+ }
+ if (waitpid($pid, 0) > 0 and $? != 0) {
+ croak "exit status: $?";
+ }
+}
+
+=item hash_object ( FILENAME [, TYPE ] )
+
+=item hash_object ( FILEHANDLE [, TYPE ] )
+
+Compute the SHA1 object id of the given C<FILENAME> (or data waiting in
+C<FILEHANDLE>) considering it is of the C<TYPE> object type (C<blob>
+(default), C<commit>, C<tree>).
+
+In case of C<FILEHANDLE> passed instead of file name, all the data
+available are read and hashed, and the filehandle is automatically
+closed. The file handle should be freshly opened - if you have already
+read anything from the file handle, the results are undefined (since
+this function works directly with the file descriptor and internal
+PerlIO buffering might have messed things up).
+
+The method can be called without any instance or on a specified Git repository,
+it makes zero difference.
+
+The function returns the SHA1 hash.
+
+Implementation of this function is very fast; no external command calls
+are involved.
+
+=cut
+
+# Implemented in Git.xs.
+
+
+=back
+
+=head1 TODO
+
+This is still fairly crude.
+We need some good way to report errors back except just dying.
+
+=head1 COPYRIGHT
+
+Copyright 2006 by Petr Baudis E<lt>pasky@suse.czE<gt>.
+
+This module is free software; it may be used, copied, modified
+and distributed under the terms of the GNU General Public Licence,
+either version 2, or (at your option) any later version.
+
+=cut
+
+
+# Take raw method argument list and return ($obj, @args) in case
+# the method was called upon an instance and (undef, @args) if
+# it was called directly.
+sub _maybe_self {
+ # This breaks inheritance. Oh well.
+ ref $_[0] eq 'Git' ? @_ : (undef, @_);
+}
+
+# When already in the subprocess, set up the appropriate state
+# for the given repository and execute the git command.
+sub _cmd_exec {
+ my ($self, @args) = @_;
+ if ($self) {
+ $self->{opts}->{Repository} and $ENV{'GIT_DIR'} = $self->{opts}->{Repository};
+ $self->{opts}->{WorkingCopy} and chdir($self->{opts}->{WorkingCopy});
+ }
+ my $git = $self->{opts}->{GitPath};
+ $git ||= 'git';
+ exec ($git, @args) or croak "exec failed: $!";
+}
+
+# Close pipe to a subprocess.
+sub _cmd_close {
+ my ($fh) = @_;
+ if (not close $fh) {
+ if ($!) {
+ # It's just close, no point in fatalities
+ carp "error closing pipe: $!";
+ } else {
+ croak "exit status: $?";
+ }
+ }
+}
+
+
+# Trickery for .xs routines: In order to avoid having some horrid
+# C code trying to do stuff with undefs and hashes, we gate all
+# xs calls through the following and in case we are being ran upon
+# an instance call a C part of the gate which will set up the
+# environment properly.
+sub _call_gate {
+ my $xsfunc = shift;
+ my ($self, @args) = _maybe_self(@_);
+
+ if (defined $self) {
+ # XXX: We ignore the WorkingCopy! To properly support
+ # that will require heavy changes in libgit.
+
+ # XXX: And we ignore everything else as well. libgit
+ # at least needs to be extended to let us specify
+ # the $GIT_DIR instead of looking it up in environment.
+ #xs_call_gate($self->{opts}->{Repository});
+ }
+
+ &$xsfunc(@args);
+}
+
+sub AUTOLOAD {
+ my $xsname;
+ our $AUTOLOAD;
+ ($xsname = $AUTOLOAD) =~ s/.*:://;
+ croak "&Git::$xsname not defined" if $xsname =~ /^xs_/;
+ $xsname = 'xs_'.$xsname;
+ _call_gate(\&$xsname, @_);
+}
+
+sub DESTROY { }
+
+
+1; # Famous last words
diff --git a/perl/Git.xs b/perl/Git.xs
new file mode 100644
index 0000000..33bb3ca
--- /dev/null
+++ b/perl/Git.xs
@@ -0,0 +1,60 @@
+/* By carefully stacking #includes here (even if WE don't really need them)
+ * we strive to make the thing actually compile. Git header files aren't very
+ * nice. Perl headers are one of the signs of the coming apocalypse. */
+#include <ctype.h>
+/* Ok, it hasn't been so bad so far. */
+
+/* libgit interface */
+#include "../cache.h"
+
+/* XS and Perl interface */
+#include "EXTERN.h"
+#include "perl.h"
+#include "XSUB.h"
+
+#include "ppport.h"
+
+
+MODULE = Git PACKAGE = Git
+
+# /* TODO: xs_call_gate(). See Git.pm. */
+
+char *
+xs_hash_object(file, type = "blob")
+ SV *file;
+ char *type;
+CODE:
+ unsigned char sha1[20];
+
+ if (SvTYPE(file) == SVt_RV)
+ file = SvRV(file);
+
+ if (SvTYPE(file) == SVt_PVGV) {
+ /* Filehandle */
+ PerlIO *pio;
+
+ pio = IoIFP(sv_2io(file));
+ if (!pio)
+ croak("You passed me something weird - a dir glob?");
+ /* XXX: I just hope PerlIO didn't read anything from it yet.
+ * --pasky */
+ if (index_pipe(sha1, PerlIO_fileno(pio), type, 0))
+ croak("Unable to hash given filehandle");
+ /* Avoid any nasty surprises. */
+ Perl_io_close(sv_2io(file), 1);
+
+ } else {
+ /* String */
+ char *path = SvPV_nolen(file);
+ int fd = open(path, O_RDONLY);
+ struct stat st;
+
+ if (fd < 0 ||
+ fstat(fd, &st) < 0 ||
+ index_fd(sha1, fd, &st, 0, type))
+ croak("Unable to hash %s", path);
+ close(fd);
+ }
+ RETVAL = sha1_to_hex(sha1);
+OUTPUT:
+ RETVAL
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
new file mode 100644
index 0000000..dd61056
--- /dev/null
+++ b/perl/Makefile.PL
@@ -0,0 +1,21 @@
+use ExtUtils::MakeMaker;
+
+sub MY::postamble {
+ return <<'MAKE_FRAG';
+instlibdir:
+ @echo $(INSTALLSITELIB)
+
+MAKE_FRAG
+}
+
+WriteMakefile(
+ NAME => 'Git',
+ VERSION_FROM => 'Git.pm',
+ MYEXTLIB => '../libgit.a',
+ INC => '-I. -I..',
+);
+
+
+use Devel::PPPort;
+
+-s 'ppport.h' or Devel::PPPort::WriteFile();
^ permalink raw reply related
* Re: What's in git.git and announcing v1.4.1-rc1
From: Petr Baudis @ 2006-06-22 21:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, linux-kernel
In-Reply-To: <e7f1pk$l1q$1@sea.gmane.org>
> >> Isn't manually numbering the enum choices somewhat pointless, though?
> >> (Actually makes it more difficult to do changes in it later.)
> >
> > Yeah, I just mindlessly followed Johannes' original scheme.
>
> You might want to start at 0, just in case...
C99 (6.7.2.2) guarantees the enumeration constants start at 0 if not
specified otherwise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Jakub Narebski @ 2006-06-22 21:24 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606221402140.6483@g5.osdl.org>
Linus Torvalds wrote:
>
>
> On Thu, 22 Jun 2006, Petr Baudis wrote:
>>
>> Isn't manually numbering the enum choices somewhat pointless, though?
>> (Actually makes it more difficult to do changes in it later.)
>
> Yeah, I just mindlessly followed Johannes' original scheme.
You might want to start at 0, just in case...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [GIT PATCH] USB patches for 2.6.17
From: Linus Torvalds @ 2006-06-22 21:07 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andrew Morton, Greg KH, linux-kernel, git, linux-usb-devel
In-Reply-To: <Pine.LNX.4.64.0606221354070.6483@g5.osdl.org>
On Thu, 22 Jun 2006, Linus Torvalds wrote:
>
> After that, I'm not quite sure what you mean by "--dry-run". Do you mean
> to know about file-level conflicts? You do need to do the merge in order
> to know whether the conflicts can be resolved, but even without doing the
> merge you can look for _file_level_ conflicts by other means.
Btw, what you can always do is just
git pull <other-end>
.. look at the result ..
git reset --hard ORIG_HEAD
and you should be ok. It's obviously not a dry-run, it's more of a "do it
and then undo it", but hey, it should _work_.
(Look out for dirty state, though. "git pull" will happily pull into a
dirty tree if the changes don't actually affect any dirty files. The "git
reset --hard" thing will undo all dirty state, though).
Linus
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [PATCH] add GIT-CFLAGS to .gitignore
From: Matthias Kestenholz @ 2006-06-22 21:06 UTC (permalink / raw)
To: junkio, git
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 65aa939..7b954d5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
+GIT-CFLAGS
GIT-VERSION-FILE
git
git-add
--
1.4.1.rc1
^ permalink raw reply related
* Re: What's in git.git and announcing v1.4.1-rc1
From: Linus Torvalds @ 2006-06-22 21:02 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20060622205859.GF21864@pasky.or.cz>
On Thu, 22 Jun 2006, Petr Baudis wrote:
>
> Isn't manually numbering the enum choices somewhat pointless, though?
> (Actually makes it more difficult to do changes in it later.)
Yeah, I just mindlessly followed Johannes' original scheme.
Linus
^ permalink raw reply
* Re: [GIT PATCH] USB patches for 2.6.17
From: Linus Torvalds @ 2006-06-22 21:01 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Greg KH, Andrew Morton, linux-kernel, linux-usb-devel, git
In-Reply-To: <20060622200147.GA10712@mars.ravnborg.org>
On Thu, 22 Jun 2006, Sam Ravnborg wrote:
>
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R
git fetch linus
git log ..linus
Yes, it will fetch the things into your database, unlike BK, but that's
kind of the point. That's what makes branches so powerful (you can do a
lot more than "bk changes -R").
> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.
Hmm? Again, do
git fetch <thing-to-be-fetched>
into a local branch first. That gets it into your repo, so that you can do
things.
After that, I'm not quite sure what you mean by "--dry-run". Do you mean
to know about file-level conflicts? You do need to do the merge in order
to know whether the conflicts can be resolved, but even without doing the
merge you can look for _file_level_ conflicts by other means.
I don't think anybody has done it, but a script like
OTHER="$1"
BASE=$(git-merge-base HEAD $OTHER) || exit
git-merge-tree $BASE HEAD $OTHER | grep -v '^0'
will show if there were file-level conflicts (in a pretty strange format,
admittedly).
Of course, 99% of the time, a three-way merge will just handle those fine
(the output from "git-merge-tree" is enough to know to do a three-way
merge on temp-files, if you want to try that).
Linus
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Petr Baudis @ 2006-06-22 20:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0606221301500.5498@g5.osdl.org>
Dear diary, on Thu, Jun 22, 2006 at 10:53:31PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> So in order to avoid a lot of blind git users, please apply this patch.
Great, since this also seems to make git diff more or less consistent
with cg diff in the colors choice.
> enum color_diff {
> - DIFF_PLAIN = 0,
> - DIFF_METAINFO = 1,
> - DIFF_FILE_OLD = 2,
> - DIFF_FILE_NEW = 3,
> + DIFF_RESET = 0,
> + DIFF_PLAIN = 1,
> + DIFF_METAINFO = 2,
> + DIFF_FRAGINFO = 3,
> + DIFF_FILE_OLD = 4,
> + DIFF_FILE_NEW = 5,
> };
Isn't manually numbering the enum choices somewhat pointless, though?
(Actually makes it more difficult to do changes in it later.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Linus Torvalds @ 2006-06-22 20:53 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <7v8xnpj7hg.fsf@assigned-by-dhcp.cox.net>
On Thu, 22 Jun 2006, Junio C Hamano wrote:
>
> - diff --color (Johannes).
I like colorized diffs, but let's face it, those particular color choices
will make most people decide to pick out their eyes with a fondue fork.
And that's not good. Digging in your eye-sockets with a fondue fork is
strictly considered to be bad for your health, and seven out of nine
optometrists are dead set against the practice.
So in order to avoid a lot of blind git users, please apply this patch.
This patch does:
- always reset the color _before_ printing out the newline.
This is actually important. You (and Johannes) didn't see it, because
it only matters if you set the background, but if you don't do this,
you get some random and funky behaviour if you pick a color with a
non-default background (which still potentially has problems with tabs
etc, but less so).
- allow people to have a different color for the "file headers"
(DIFF_METAINFO) and for the "fragment header" (DIFF_FRAGINFO). Also,
make a difference between "normal color" and "reset colors"
- default to red/green for old/new lines. That's the norm, I'd think.
- instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping)
purple color for metadata, use bold-face for file headers, and cyan for
the frag headers. I actually prefer the "gray background" for that, but
it only works well in xterms, so COLOR_CYAN it is..
Hmm?
Linus
---
diff.c | 99 +++++++++++++++++++++++++++++++++++++---------------------------
1 files changed, 58 insertions(+), 41 deletions(-)
diff --git a/diff.c b/diff.c
index 22b643c..07e9d56 100644
--- a/diff.c
+++ b/diff.c
@@ -26,17 +26,41 @@ int git_diff_config(const char *var, con
}
enum color_diff {
- DIFF_PLAIN = 0,
- DIFF_METAINFO = 1,
- DIFF_FILE_OLD = 2,
- DIFF_FILE_NEW = 3,
+ DIFF_RESET = 0,
+ DIFF_PLAIN = 1,
+ DIFF_METAINFO = 2,
+ DIFF_FRAGINFO = 3,
+ DIFF_FILE_OLD = 4,
+ DIFF_FILE_NEW = 5,
};
+#define COLOR_NORMAL ""
+#define COLOR_BOLD "\033[1m"
+#define COLOR_DIM "\033[2m"
+#define COLOR_UL "\033[4m"
+#define COLOR_BLINK "\033[5m"
+#define COLOR_REVERSE "\033[7m"
+#define COLOR_RESET "\033[m"
+
+#define COLOR_BLACK "\033[30m"
+#define COLOR_RED "\033[31m"
+#define COLOR_GREEN "\033[32m"
+#define COLOR_YELLOW "\033[33m"
+#define COLOR_BLUE "\033[34m"
+#define COLOR_MAGENTA "\033[35m"
+#define COLOR_CYAN "\033[36m"
+#define COLOR_WHITE "\033[37m"
+
+#define COLOR_CYANBG "\033[46m"
+#define COLOR_GRAYBG "\033[47m" // Good for xterm
+
static const char *diff_colors[] = {
- "\033[0;0m",
- "\033[1;35m",
- "\033[1;31m",
- "\033[1;34m",
+ [DIFF_RESET] = COLOR_RESET,
+ [DIFF_PLAIN] = COLOR_NORMAL,
+ [DIFF_METAINFO] = COLOR_BOLD,
+ [DIFF_FRAGINFO] = COLOR_CYAN,
+ [DIFF_FILE_OLD] = COLOR_RED,
+ [DIFF_FILE_NEW] = COLOR_GREEN,
};
static char *quote_one(const char *str)
@@ -196,22 +220,23 @@ struct emit_callback {
const char **label_path;
};
-static inline void color_diff(int diff_use_color, enum color_diff ix)
+static inline const char *get_color(int diff_use_color, enum color_diff ix)
{
if (diff_use_color)
- fputs(diff_colors[ix], stdout);
+ return diff_colors[ix];
+ return "";
}
static void fn_out_consume(void *priv, char *line, unsigned long len)
{
int i;
struct emit_callback *ecbdata = priv;
+ const char *set = get_color(ecbdata->color_diff, DIFF_METAINFO);
+ const char *reset = get_color(ecbdata->color_diff, DIFF_RESET);
if (ecbdata->label_path[0]) {
- color_diff(ecbdata->color_diff, DIFF_METAINFO);
- printf("--- %s\n", ecbdata->label_path[0]);
- color_diff(ecbdata->color_diff, DIFF_METAINFO);
- printf("+++ %s\n", ecbdata->label_path[1]);
+ printf("%s--- %s%s\n", set, ecbdata->label_path[0], reset);
+ printf("%s+++ %s%s\n", set, ecbdata->label_path[1], reset);
ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
}
@@ -222,10 +247,10 @@ static void fn_out_consume(void *priv, c
;
if (2 <= i && i < len && line[i] == ' ') {
ecbdata->nparents = i - 1;
- color_diff(ecbdata->color_diff, DIFF_METAINFO);
+ set = get_color(ecbdata->color_diff, DIFF_FRAGINFO);
}
else if (len < ecbdata->nparents)
- color_diff(ecbdata->color_diff, DIFF_PLAIN);
+ set = reset;
else {
int nparents = ecbdata->nparents;
int color = DIFF_PLAIN;
@@ -235,10 +260,11 @@ static void fn_out_consume(void *priv, c
else if (line[i] == '+')
color = DIFF_FILE_NEW;
}
- color_diff(ecbdata->color_diff, color);
+ set = get_color(ecbdata->color_diff, color);
}
- fwrite(line, len, 1, stdout);
- color_diff(ecbdata->color_diff, DIFF_PLAIN);
+ if (len > 0 && line[len-1] == '\n')
+ len--;
+ printf("%s%.*s%s\n", set, (int) len, line, reset);
}
static char *pprint_rename(const char *a, const char *b)
@@ -589,40 +615,32 @@ static void builtin_diff(const char *nam
mmfile_t mf1, mf2;
const char *lbl[2];
char *a_one, *b_two;
+ const char *set = get_color(o->color_diff, DIFF_METAINFO);
+ const char *reset = get_color(o->color_diff, DIFF_PLAIN);
a_one = quote_two("a/", name_a);
b_two = quote_two("b/", name_b);
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
- color_diff(o->color_diff, DIFF_METAINFO);
- printf("diff --git %s %s\n", a_one, b_two);
+ printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
if (lbl[0][0] == '/') {
/* /dev/null */
- color_diff(o->color_diff, DIFF_METAINFO);
- printf("new file mode %06o\n", two->mode);
- if (xfrm_msg && xfrm_msg[0]) {
- color_diff(o->color_diff, DIFF_METAINFO);
- puts(xfrm_msg);
- }
+ printf("%snew file mode %06o%s\n", set, two->mode, reset);
+ if (xfrm_msg && xfrm_msg[0])
+ printf("%s%s%s\n", set, xfrm_msg, reset);
}
else if (lbl[1][0] == '/') {
- printf("deleted file mode %06o\n", one->mode);
- if (xfrm_msg && xfrm_msg[0]) {
- color_diff(o->color_diff, DIFF_METAINFO);
- puts(xfrm_msg);
- }
+ printf("%sdeleted file mode %06o%s\n", set, one->mode, reset);
+ if (xfrm_msg && xfrm_msg[0])
+ printf("%s%s%s\n", set, xfrm_msg, reset);
}
else {
if (one->mode != two->mode) {
- color_diff(o->color_diff, DIFF_METAINFO);
- printf("old mode %06o\n", one->mode);
- color_diff(o->color_diff, DIFF_METAINFO);
- printf("new mode %06o\n", two->mode);
- }
- if (xfrm_msg && xfrm_msg[0]) {
- color_diff(o->color_diff, DIFF_METAINFO);
- puts(xfrm_msg);
+ printf("%sold mode %06o%s\n", set, one->mode, reset);
+ printf("%snew mode %06o%s\n", set, two->mode, reset);
}
+ if (xfrm_msg && xfrm_msg[0])
+ printf("%s%s%s\n", set, xfrm_msg, reset);
/*
* we do not run diff between different kind
* of objects.
@@ -630,7 +648,6 @@ static void builtin_diff(const char *nam
if ((one->mode ^ two->mode) & S_IFMT)
goto free_ab_and_return;
if (complete_rewrite) {
- color_diff(o->color_diff, DIFF_PLAIN);
emit_rewrite_diff(name_a, name_b, one, two);
goto free_ab_and_return;
}
^ permalink raw reply related
* Re: [GIT PATCH] USB patches for 2.6.17
From: Petr Baudis @ 2006-06-22 20:52 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel,
linux-usb-devel, git
In-Reply-To: <20060622200147.GA10712@mars.ravnborg.org>
Dear diary, on Thu, Jun 22, 2006 at 10:01:47PM CEST, I got a letter
where Sam Ravnborg <sam@ravnborg.org> said that...
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R
You can cg-fetch / git fetch and then either "cg-log -m" or
"git log -r ..origin".
> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.
What would that involve? Isn't git pull --no-commit enough?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Paolo Ciarrocchi @ 2006-06-22 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v8xnpj7hg.fsf@assigned-by-dhcp.cox.net>
On 6/22/06, Junio C Hamano <junkio@cox.net> wrote:
> I've merged quite a bit of stuff and tagged the tip of "master"
> as GIT 1.4.1-rc1.
Pulled and installed.
When I fire up gitk I see the following error messages, even if gitk
seems to be working fine:
paolo@Italia:~/git$ gitk
invalid command name ".ctop.cdet.left.ctext"
while executing
"$ctext conf -state normal"
(procedure "dispneartags" line 7)
invoked from within
"dispneartags"
(procedure "restartatags" line 28)
invoked from within
"restartatags 869"
("after" script)
--
Paolo
http://paolociarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 20:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xnpj7hg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> * The 'pu' branch, in addition, has these.
>
> Johannes Schindelin:
> Teach diff about -b and -w flags
I am hoping to coordinate the inclusion of this upstream first
and have this hopefully in the real 1.4.1 release.
> Lukas Sandström:
> Make it possible to call cmd_apply multiple times
> Make git-am a builtin
Last time I tried this, it did not work for me, so I am putting
it on hold. I feel, however, "am" is a high-enough-level tool
that we would prefer to keep it scriptable for quick tweaks.
If it is hurting portability because it is written in shell,
maybe this can be moved to all Perl (especially when Pasky's
Git.pm is ready) or Python. Personally I think Windows minded
folks who cannot stand command-line interface Cygwin port gives
would not be satisfied anyway, until somebody writes a native
drag-this-mail-and-drop-on-that-brach tool, so porting the
command out of shell may not be even worth doing. I dunno.
^ permalink raw reply
* Re: Incremental CVS update
From: Jon Smirl @ 2006-06-22 20:08 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Keith Packard, git
In-Reply-To: <46a038f90606221236j2c5c9692yecef924aa769c1c9@mail.gmail.com>
On 6/22/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/23/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
> > to keep it's status in the .git repository and use tags to locate it.
> > You could even have a utility to show when and what was imported. By
> > keeping everything in git it doesn't matter who runs the incremental
> > update commands.
>
> Jon,
>
> what cvsps keeps is a cache of what it knows about the repo history,
> to ask only for new commits. Now, cvsps will always write to STDOUT
> the full history, and git-cvsimport discards the commits it has
> already seen, based on reading the state of each git head.
The cache is 723MB for the Mozilla repo. Since the info gets cached in
my home directory anyone else who needs to sync the repo doesn't get
to use the cache.
[jonsmirl@jonsmirl .cvsps]$ pwd
/home/jonsmirl/.cvsps
[jonsmirl@jonsmirl .cvsps]$ ls -l
total 707492
-rw-rw-r-- 1 jonsmirl jonsmirl 723758657 Jun 15 16:10 #home#mozcvs##mozilla
[jonsmirl@jonsmirl .cvsps]$
Keith is rewriting parsecvs. If you analyze all of the data
structures, the info needed for the conversion should be able to fit
into well under 100MB instead of the ~2GB the current programs are
using.
There are lots of ways to reduce memory consumption. You can turm CVS
revisions into git IDs as soon as the revision is seen. That lets you
get away from tracking file names and long CVS revision numbers. It
also works to turn the author/log fields immediately into a hash. When
possible switching to arrays instead of linked list is smaller too.
Some stats:
1M revisions
200K unique changesets (author/log combos)
200KB symbols
1,800 branches
cvsps has the lowest memory consumption, it uses 1200 bytes per
revision. It looks like it is possible to lower this to less than 100
bytes per rev.
>
> So cvsps + git-cvsimport don't keep any extra data around, and I am
> 100% certain that parsecvs don't need that either.
>
> cheers,
>
>
> martin
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [GIT PATCH] USB patches for 2.6.17
From: Sam Ravnborg @ 2006-06-22 20:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Greg KH, linux-kernel, git, linux-usb-devel
In-Reply-To: <Pine.LNX.4.64.0606221239100.5498@g5.osdl.org>
> I'm just constantly surprised by how people don't even seem to realize
> what it can do sometimes. Part of it is that development has been pretty
> active (and some of the things it can do simply weren't there three months
> ago), but part of it must be because people don't even expect it to be
> able to do something like that.
Personally I'm still missing two things:
1) A command to let me see what this Linus guy have applied compared to
my tree - without touching anything in my tree. bk changes -R
2) A dry-run of a fetch+pull. I can do that if I really study the man
pages I know. But "git pull --dry-run" would be more convinient.
Other than that I will say that I'm pleased with the funtionality that
I use - that's maybe 10% of the possibilities...
Sam
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 19:49 UTC (permalink / raw)
To: git; +Cc: linux-kernel
I've merged quite a bit of stuff and tagged the tip of "master"
as GIT 1.4.1-rc1.
As promised, 1.4.X series will be managed slightly differently,
and this is in preparation of the first installment of it. The
releases will come from the "master" branch to contain both
fixes and enhancements from now on. Hotfix releases when
necessary would have 1.4.X.Y revision numbers, but I am hoping
that we do not have to do that very often.
Since all the exciting and potentially risky developments are to
happen on the "next" branch and they are supposed to graduate to
"master" branch after they are reasonably well cooked, this
change will help the end-users to stay reasonably current
without hopefully not introducing unexpected problems. The
older scheme left out all the enhancements if people followed
packaged versions, and gave big surprises when upgrading from
version X.Y.Z to X.(Y+1).0 which was not so nice.
Notable improvements since v1.4.0 are:
- PPC SHA1 routine can grok more than half-gig of data (Paul
Mackerras)
- rev-list and object-layer in general is less (much less)
space hungry (Linus).
- the source is more friendly to stricter compilers such as
Sun's (Florian Forster).
- git rebase --merge (Eric Wong). This uses the usual 3-way
merge machinery while running rebase, and you can rebase
across renames if you use the recursive strategy which is the
default.
- gitweb updates -- mostly cleanups (Jakub Narebski with help
from Pasky and Timo Hirvonen).
- diff --color (Johannes).
- ~/.gitconfig and $ENV{GIT_CONFIG} (Pasky and Johannes).
- core.sharedrepository can take umask, group or world (Linus
and I)
- "git checkout -f" removes files that becomes untracked from
the working tree
- "git clone/fetch" from a corrupt repository does not
propagate brokenness to the downloaders.
- "git clone/fetch" over the network gives better progress
updates; this may also help TCP timeout problems for people
behind NAT.
- Many more commands are built-in (Lukas Sandström)
- git can now be used on Kiritimati (Paul Eggert)
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Andre Noll:
object-refs: avoid division by zero
David Woodhouse:
Log peer address when git-daemon called from inetd
Dennis Stosberg:
Make t8001-annotate and t8002-blame more portable
Fix t8001-annotate and t8002-blame for ActiveState Perl
Eric W. Biederman:
Fix git-format-patch -s
Check and document the options to prevent mistakes.
Eric Wong:
git-svn: fix --rmdir when using SVN:: libraries
rebase: Allow merge strategies to be used when rebasing
rebase: error out for NO_PYTHON if they use recursive merge
git-svn: fix commit --edit flag when using SVN:: libraries
Florian Forster:
Remove ranges from switch statements.
Initialize FAMs using `FLEX_ARRAY'.
Don't instantiate structures with FAMs.
Cast pointers to `void *' when used in a format.
Don't use empty structure initializers.
Change types used in bitfields to be `int's.
Remove all void-pointer arithmetic.
Jakub Narebski:
Move gitweb style to gitweb.css
gitweb: safely output binary files for 'blob_plain' action
gitweb: text files for 'blob_plain' action without charset by default
Fix gitweb stylesheet
Make CSS file gitweb/gitweb.css more readable
gitweb: add type="text/css" to stylesheet link
Fix: Support for the standard mime.types map in gitweb
gitweb: A couple of page title tweaking
gitweb: style done with stylesheet
gitweb: whitespace cleanup
Add git version to gitweb output
Move $gitbin earlier in gitweb.cgi
gitweb: Make use of $PATH_INFO for project parameter
gitweb: whitespace cleanup around '='
Johannes Schindelin:
diff options: add --color
Initialize lock_file struct to all zero.
Fix setting config variables with an alternative GIT_CONFIG
Read configuration also from $HOME/.gitconfig
repo-config: Fix late-night bug
git_config: access() returns 0 on success, not > 0
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
fetch-pack: give up after getting too many "ack continue"
shared repository: optionally allow reading to "others".
fix rfc2047 formatter.
xdiff: minor changes to match libxdiff-0.21
Restore SIGCHLD to SIG_DFL where we care about waitpid().
checkout -f: do not leave untracked working tree files.
upload-pack: avoid sending an incomplete pack upon failure
upload-pack: prepare for sideband message support.
Retire git-clone-pack
upload-pack/fetch-pack: support side-band communication
Add renaming-rebase test.
daemon: send stderr to /dev/null instead of closing.
rebase --merge: fix for rebasing more than 7 commits.
Makefile: do not force unneeded recompilation upon GIT_VERSION changes
Linus Torvalds:
Shrink "struct object" a bit
Move "void *util" from "struct object" into "struct commit"
Some more memory leak avoidance
Remove "refs" field from "struct object"
Add specialized object allocator
Add "named object array" concept
Fix grow_refs_hash()
Lukas Sandström:
Make git-write-tree a builtin
Make git-mailsplit a builtin
Make git-mailinfo a builtin
Make git-stripspace a builtin
Make git-update-index a builtin
Make git-update-ref a builtin
Paul Eggert:
date.c: improve guess between timezone offset and year.
Paul Mackerras:
Fix PPC SHA1 routine for large input buffers
Petr Baudis:
Support for extracting configuration from different files
Support for the standard mime.types map in gitweb
Rene Scharfe:
git-tar-tree: Simplify write_trailer()
git-tar-tree: documentation update
git-tar-tree: no more void pointer arithmetic
Make release tarballs friendlier to older tar versions
Timo Hirvonen:
gitweb: Use $hash_base as $search_hash if possible
Uwe Zeisberger:
Fix possible out-of-bounds array access
Yakov Lerner:
auto-detect changed prefix and/or changed build flags
Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
* The 'pu' branch, in addition, has these.
Johannes Schindelin:
Teach diff about -b and -w flags
Lukas Sandström:
Make it possible to call cmd_apply multiple times
Make git-am a builtin
^ permalink raw reply
* You gape for shooting like you had seen in those films
From: Lassiter @ 2006-06-22 20:09 UTC (permalink / raw)
To: glenn
Do you wish to increase your volume by up to 500%? http://beauti-full.com/gall/gsm Every man wishes it. It’s absolutely true – just take one before startWorried it won't work?Increase your volume in just days
^ permalink raw reply
* Re: [PATCH] [RFC] Introduce Git.pm
From: Petr Baudis @ 2006-06-22 19:37 UTC (permalink / raw)
To: Junio C Hamano, Eric Wong; +Cc: git
In-Reply-To: <7v64iuxard.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jun 22, 2006 at 03:03:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Currently Git.pm just wraps up exec()s of Git commands, but even that
> > is not trivial to get right and various Git perl scripts do it in
> > various inconsistent ways. And things will get much more interesting
> > when we get to XS-izing libgit.
>
> We would probably need some moderate to major surgery before
> doing that depending on which parts. Worrisome are object layer
> that holds onto parsed objects and keeps flag bits from the
> previous runs, and lockfile that are cleaned up via atexit() --
> there may be others.
Yes, I'm aware of that. Still, some parts should be quite easy...
Dear diary, on Thu, Jun 22, 2006 at 04:31:05AM CEST, I got a letter
where Eric Wong <normalperson@yhbt.net> said that...
> XS-ising libgit would be awesome with all the git-hash-object calls in
> git-svn (and other importers, too, I imagine).
...so I couldn't resist that and did add hash_object() xs-ized
function. Looks pretty sweet:
$ time perl -w -I/home/xpasky/lib/perl5/site_perl/5.8.8 -MGit -le 'print Git::generic_oneline("hash-object", "Makefile") for (1..1000)' >/dev/null
real 0m4.800s
user 0m2.072s
sys 0m2.560s
$ time perl -w -I/home/xpasky/lib/perl5/site_perl/5.8.8 -MGit -le 'print Git::hash_object("Makefile") for (1..1000)' >/dev/null
real 0m0.179s
user 0m0.144s
sys 0m0.032s
Dear diary, on Thu, Jun 22, 2006 at 03:03:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> > @@ -618,6 +622,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> > @FLAGS='$(TRACK_CFLAGS)'; \
> > if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
> > echo 1>&2 " * new build flags or prefix"; \
> > + echo 1>&2 " * $$FLAGS != `cat GIT-CFLAGS 2>/dev/null`"; \
> > echo "$$FLAGS" >GIT-CFLAGS; \
> > fi
> >
>
> Offtopic; do people mind if we drop $GIT_VERSION from
> TRACK_CFLAGS? Every time I switch branches or make a new commit
> it ends up rebuilding everything needlessly.
Please, please, _do_! :-)
I'm sorry about this hunk, I added it to just figure out why the heck it
keeps rebuilding everything from scratch and forgot to drop it.
> > sub current_branch {
> > - my ($bra) = qx{git-symbolic-ref HEAD};
> > + my ($bra) = $repo->generic_oneline('symbolic-ref', 'HEAD');
> > chomp($bra);
> > $bra =~ s|^refs/heads/||;
> > if ($bra ne 'master') {
>
> Your *_oneline chomps so chomp($bra) is not needed anymore, I think.
Ah, thanks.
> > +require Exporter;
>
> Not "use"?
The idiom is to require, I guess; we don't need to import anything.
I don't think it matters and I'm not entirely sure about all the
implications of the difference between the two, so if you wish,
I can change it.
> > +# Methods which can be called as standalone functions as well:
> > +@EXPORT_OK = qw(generic generic_oneval generic_vocal);
>
> I am not sure generic_xxx is a good name. Perhaps command_xxx?
Technically, other methods can be commands, too. ;-) But yet, it sounds
better. I've changed it.
> Also as you say in the comment, "vocal" sounds a bit funny.
> I wonder if we can use wantarray to detect the case where the
> caller wants _no_ value, and do the "not piping" optimization in
> that case.
I think that would be rather confusing since generic_vocal does not make
the output go away but makes it go to stdout, while if you just throw
away return value of generic(), you expect it to go nowhere.
At least I will change 'vocal' to 'noisy' so that it does not sound
so weird.
Dear diary, on Thu, Jun 22, 2006 at 04:31:05AM CEST, I got a letter
where Eric Wong <normalperson@yhbt.net> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> > + my $pid = open(my $fh, "-|");
> > + if ($pid < 0) {
> > + die "generic($cmd, @args) open: $!";
>
> In Perl, fork returns undef instead of $pid < 0 on failure.
Thanks!
> Doing join(' ',@args) will also make the error message more readable, too :)
@args should get automagically interpolated by having the members
separated by $" (space by default).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Incremental CVS update
From: Martin Langhoff @ 2006-06-22 19:36 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606220526o14ebe76ala4d327f012a0e8f5@mail.gmail.com>
On 6/23/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
> to keep it's status in the .git repository and use tags to locate it.
> You could even have a utility to show when and what was imported. By
> keeping everything in git it doesn't matter who runs the incremental
> update commands.
Jon,
what cvsps keeps is a cache of what it knows about the repo history,
to ask only for new commits. Now, cvsps will always write to STDOUT
the full history, and git-cvsimport discards the commits it has
already seen, based on reading the state of each git head.
So cvsps + git-cvsimport don't keep any extra data around, and I am
100% certain that parsecvs don't need that either.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622175815.GC21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... while the Git.pm module should be available systemwide even
> for non-Git applications, so it's really best to leave it to Perl where
> to put it.
OK, if that is the intention passing prefix might be sensible.
^ permalink raw reply
* Re: [PATCH] Make -p --stat and --stat -p behave like --patch-with-stat
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060622162511.4788505e.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> git log log only
> git log --stat log with stat
> git log -p log with patch
> git log --stat -p log with patch (no stat!)
> git log -p --stat log with stat (no patch!)
> git log --patch-with-stat log with patch and stat
>
> This patch makes -p --stat and --stat -p work like --patch-with-stat.
>
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
> ---
>
> Maybe DIFF_FORMAT_* should be reworked instead but this was easy.
>
> Only negative impact of this patch is that if you have a alias
>
> l=log --stat
>
> then you can't override --stat with "git l -p", it will still show
> diffstat, but I don't think it matters.
I do not think it matters that much either, but DIFF_FORMAT_*
really should be reworked regardless. --with-foo should really
be independent switches that can be added together, perhaps.
So how would we go about this? A strawman.
The diff output has four parts, each of which can independently
be enabled. When no options are specified on the command line,
each command has its own default but in general the low-level
commands default to raw output only, and the higher-level ones
default to patch output only.
The four parts are controlled with a bit each, and are output in
the fixed order (iow the order of the options given from the
command line does not matter): raw, stat, summary and patch.
When --name-only or --name-status is specified, that would be
the only thing that is output (iow the above four parts would
not be shown, just names optionally with the status are shown).
The four switches are: --raw, --stat, --summary and --patch.
Existing flags are supported as obvious shorthands to turn on
the corresponding bits:
-p, -u --patch
--patch-with-raw --raw --patch
--patch-with-stat --stat --patch
Anybody interested in doing a patch?
^ 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