* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-10 21:38 UTC (permalink / raw)
To: gitzilla; +Cc: git, junkio
In-Reply-To: <43ED0368.7020204@gmail.com>
Thanks; good catch. I think we should export GIT_*_{NAME,EMAIL}
variables explicitly for this particular problem. We probably
do _not_ want to do the same for GIT_*_DATE though.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-10 21:38 UTC (permalink / raw)
To: git
In-Reply-To: <20060210211740.GO31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> One thing I dislike on both StGIT and pg is that they both try to
> build a full-fledged porcelain on top of GIT, instead of just focusing
> on the patch management, doing it well and providing a convenient user
> interface (well, can't say about pg's interface, didn't try it yet).
> Instead of having pg-add, pg-log, or pg-status it might be more fruitful
> to contribute the features you are missing to git-core or Cogito.
Very valid points. Before writing pg I used Cogito exclusively
and found git-core too cumbersome to use directly. When I started
writing pg I didn't intend on replacing everything GIT and Cogito
offers; I was trying to only create the patch stack but still use
the Cogito tools for everything else.
But two things happened:
1) Cogito didn't run well on a Solaris box I wanted to try and
use it in; apparently we don't have enough GNU shell commands
available and Cogito fell over. (But right now I'd bet pg
will behave the same if not worse. I haven't had time to try
it. *sigh*)
2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
than 'git-log' and 'git-diff'. Call it future muscle memory?
I hadn't written either of these scripts so I was getting a lot
of '-bash: pg-log: command not found' errors from my shell.
So they both became 1 line wrappers around the git-core
versions, just to save my sanity.
I would agree with trying to integrate some of the workflow idealogy
presented by StGIT and pg into something more mainstream such as
git-core or Cogito. Right now I'm using pg as a proving ground to
feel out how some of that might work in one particular environment:
A development team I work with is stuck using PVCS Version
Manager 6. Moving source code from a developer to a tester is a
huge nightmare; not only must the developer check the code into
the version control system but he/she must also write a bug report
in a bug database to tell someone else to get the source file
and give it to the tester. Its a horrible workflow. GIT + pg +
additional custom scripts seems to be easing the pain somewhat;
but sadly we can't just rip out PVCS Version Manager and use GIT.
> > And for those so inclined:
> >
> > Homepage: http://www.spearce.org/projects/scm/pg/
> > GIT Repository: http://www.spearce.org/projects/scm/pg.git
>
> But while it claims to be compatible with all the porcelains, it at
> least cannot be clone by them. ;) The GIT repository is not quite a
> valid GIT repository since it is missing the HEAD and Cogito clones
> based on this file instead of just assuming that your head is on the
> master branch.
Fixed. That's my fault - my hosting provider doesn't have GIT
installed and thus I had to publish my repository over rsync+ssh.
But git-push doesn't support that protocol type anymore. :-| So
I packed everything into pack files, pruned the object directory,
and rsync'd it up. I guess my rsync script didn't copy HEAD.
> Also, when cloning it gives me a little unnerving errors like
>
> error: File 6427c0154400f578d9cdff178e01e946db6f714f
> (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
> corrupt
I've seen the same. I think it is either a bug in my rsync script
or a bug in the GIT http clone code; because that is the current
tip commit of the master branch. And I've only seen that error for
the tip commit, and only if the object doesn't exist in the object
directory because I've done git-pack && git-prune-packed.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-10 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060210213818.GB1604@spearce.org>
Dear diary, on Fri, Feb 10, 2006 at 10:38:18PM CET, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> But two things happened:
>
> 1) Cogito didn't run well on a Solaris box I wanted to try and
> use it in; apparently we don't have enough GNU shell commands
> available and Cogito fell over. (But right now I'd bet pg
> will behave the same if not worse. I haven't had time to try
> it. *sigh*)
I'm always listening for bugreports. Besides requiring bash, Cogito _is_
expected to run on POSIX stuff!
> 2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
> than 'git-log' and 'git-diff'. Call it future muscle memory?
> I hadn't written either of these scripts so I was getting a lot
> of '-bash: pg-log: command not found' errors from my shell.
> So they both became 1 line wrappers around the git-core
> versions, just to save my sanity.
I see. IIRC Catalin gave the similar reasoning. (Obviously, my
egoistical me might be just hurt by it not wrapping Cogito. ;))
> > But while it claims to be compatible with all the porcelains, it at
> > least cannot be clone by them. ;) The GIT repository is not quite a
> > valid GIT repository since it is missing the HEAD and Cogito clones
> > based on this file instead of just assuming that your head is on the
> > master branch.
>
> Fixed.
Thanks.
> > Also, when cloning it gives me a little unnerving errors like
> >
> > error: File 6427c0154400f578d9cdff178e01e946db6f714f
> > (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
> > corrupt
>
> I've seen the same. I think it is either a bug in my rsync script
> or a bug in the GIT http clone code; because that is the current
> tip commit of the master branch. And I've only seen that error for
> the tip commit, and only if the object doesn't exist in the object
> directory because I've done git-pack && git-prune-packed.
On a second thought, this is probably simply caused by the web server
not reporting 404 on missing files.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Christian Biesinger @ 2006-02-10 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgyvrih.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Does continuing with this kind of "fixups" produce usable
> history, perhaps just some changes missing but trees contained
> in other commits are still faithful reproductions of what the
> CVS repository would have given you? Or does it result in
> unusable history?
I have to admit that I can't actually tell you for sure, since I still
get a failure later (I think it's because cvsps orders changesets
wrongly). However, I was told that the revisions that give me this
CVSPS_NO_BRANCH issue came into existence by (partially) removing tags
from a file, so not listing them should be fine, I think. (This happened
by copying a ,v file and removing its tags, simulating a file copy)
Anyway, based on that, I expect that the history is the same as what I
get from cvs, but I can't verify that.
> Depending on the nature of corruption and its expected use,
> sometimes silently corrupt conversion result is worse than not
> having it at all.
Well, without the patch this error is fatal, and the conversion is very
partial. I'm not sure if that's better.
(This is also not "silent" corruption. I do show a message for it. Would
you rather have it displayed unconditionally?)
Would it be better to have a flag --continue-on-errors?
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Junio C Hamano @ 2006-02-10 22:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060210214723.GP31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On a second thought, this is probably simply caused by the web server
> not reporting 404 on missing files.
I suspect that is it. The webserver is broken^W not being a
good network citizen.
^ permalink raw reply
* Re: Comments on "status -v"
From: Junio C Hamano @ 2006-02-10 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.64.0602101333570.19172@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think I agree. Especially if doing "git commit -v", the _top_ of the
> status message is what you'd normally be most aware of. I think.
Well the exactly same reasoning on my part, who keeps tons of
untracked files in his repository, left the patch output there.
Otherwise I have to scroll off a long "untracked files" list to
get to the patch ;-).
But even with that gripe, I'd agree that patch at the end would
be a better choice. The user asked for a patch so she wouldn't
fail to see it even if many '#' lines precede the patch. With
the current ordering, '#' lines will most likely be ignored.
^ permalink raw reply
* Re: Comments on "status -v"
From: Petr Baudis @ 2006-02-10 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vaccyx6ne.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Feb 10, 2006 at 10:09:41PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Carl Worth <cworth@cworth.org> writes:
>
> > 1) I think the patch should come after the traditional status summary,
> > not before. If something is obviously "wrong" (non-updated file,
> > etc.) that will be more obvious in the summary, so it's good to
> > present that up front, and not bury it after the patch, (which
> > might make it initially invisible without scrolling).
>
> Maybe. A time for a quick poll.
It makes more sense to me. (Not that I'd be ever going to use the
command, though. ;)
> > 2) Using the "^---$" separator to separate the the edited contents
> > into a commit message and ignored content seems risky to me.
We do it for the mails (and Cogito for cg-mkpatch output) and it seems
to work out just fine.
> > Moving the patch after the summary (as discussed above) would help
> > greatly in avoiding the clobbered separator, but wouldn't address
> > the separator-appears-in-commit-message problem.
>
> That is a good argument for (1). Since the diff output never
> has '^---$' in itself,
$ echo -- >a; >b; diff -u a b
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Greg KH @ 2006-02-10 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060210210401.GA1604@spearce.org>
On Fri, Feb 10, 2006 at 04:04:01PM -0500, Shawn Pearce wrote:
> Greg KH <greg@kroah.com> wrote:
> > On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
> > > I just posted the first public version of pg, a GIT porcelain for
> > > managing patches. Think StGIT, but better in some ways:
> > >
> > > Feature Summary:
> >
> > Hm, is there any way to import an existing patch into pg?
>
> Doh! I haven't needed to do that yet. I'll code up a pg-import
> later tonight. But since git and pg play nice together you can
> do this:
>
> pg-new Patch-Name
> git-apply the-patch-file.patch
> pg-ci -m"Importing the-patch-file.patch..."
>
> or even:
>
> pg-new Patch-Name
> git-am mbox
well, as my quilt tree is around 200 patches right now, that would be
annoying to have to do by hand :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Linus Torvalds @ 2006-02-10 23:25 UTC (permalink / raw)
To: Christian Biesinger; +Cc: Junio C Hamano, git
In-Reply-To: <43ED0D63.5090105@web.de>
On Fri, 10 Feb 2006, Christian Biesinger wrote:
>
> I have to admit that I can't actually tell you for sure, since I still get a
> failure later (I think it's because cvsps orders changesets wrongly).
Do you have a recent version of "cvsps"? The wrong ordering happened quite
often with old cvsps versions. So make sure you absolutely have 2.1.
Also, David Mansfield may not be maintaining it horribly actively, but
that's probably because it's purely a "minimal maintenance" project for
him by now. He reacted in a very timely manner when we pointed out
specific bugs, so if you can pinpoint the exact thing cvsps does wrong, I
bet David will be more than happy to apply patches or perhaps even fix it
himself and make a new version.
So while it's fine to work around cvsps problems inside "git cvsimport",
it's even better if you could try to see if you can figure out why they
happen in the first place. The source code wasn't all that unreadable from
what I can remember.
Linus
^ permalink raw reply
* Re: Comments on "status -v"
From: Junio C Hamano @ 2006-02-10 23:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060210225109.GQ31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> That is a good argument for (1). Since the diff output never
>> has '^---$' in itself,
>
> $ echo -- >a; >b; diff -u a b
Thanks. Good point. Forget what I said.
^ permalink raw reply
* [PATCH 1/3] Call extended-semantics commands through variables.
From: Jason Riedy @ 2006-02-10 23:35 UTC (permalink / raw)
To: git
In some places, git shell scripts rely on semantics for
xargs, find, and cpio that do not exist in all versions
of those commands. Both xargs and find rely on -0 for
handling multi-word names, and for some reason the cpio
calls do not work with pkgsrc's default cpio.
Replacing all such calls with calls through variables
allows more portability. Also, the variables can point
to debugging scripts that log arguments, outputs, etc.
The variables are just XARGS, FIND, and CPIO. No GIT_
was appended so a user can set those once for all scripts
that may use them (e.g. configure). A follow-on patch
will modify the Makefile to allow installation-specific
defaults.
Tested on Solaris 8 with those arguments pointing at
GNU tools as well as some Linux versions. (The AIX
machine I use is down for maintenance right now.)
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-add.sh | 3 ++-
git-clone.sh | 10 ++++++----
git-count-objects.sh | 8 +++++---
git-grep.sh | 3 ++-
git-ls-remote.sh | 4 +++-
git-merge.sh | 5 +++--
git-prune.sh | 5 +++--
git-push.sh | 5 +++--
git-repack.sh | 3 ++-
9 files changed, 29 insertions(+), 17 deletions(-)
846024657d04675a762fd9edaba3c0612f616a41
diff --git a/git-add.sh b/git-add.sh
index f719b4b..bd79b4f 100755
--- a/git-add.sh
+++ b/git-add.sh
@@ -3,6 +3,7 @@
USAGE='[-n] [-v] <file>...'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+: ${XARGS:=xargs}
show_only=
verbose=
@@ -35,7 +36,7 @@ else
fi |
case "$show_only" in
true)
- xargs -0 echo ;;
+ ${XARGS} -0 echo ;;
*)
git-update-index --add $verbose -z --stdin ;;
esac
diff --git a/git-clone.sh b/git-clone.sh
index 47f3ec9..2c9b45e 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -7,6 +7,8 @@
# See git-sh-setup why.
unset CDPATH
+: ${FIND:=find}
+: ${CPIO:=cpio}
usage() {
echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
@@ -141,19 +143,19 @@ yes,yes)
no)
# See if we can hardlink and drop "l" if not.
sample_file=$(cd "$repo" && \
- find objects -type f -print | sed -e 1q)
+ ${FIND} objects -type f -print | sed -e 1q)
# objects directory should not be empty since we are cloning!
test -f "$repo/$sample_file" || exit
l=
- if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
+ if ln "$repo/$sample_file" "$DIR/objects/sample" 2>/dev/null
then
l=l
fi &&
rm -f "$GIT_DIR/objects/sample" &&
cd "$repo" &&
- find objects -depth -print | cpio -puamd$l "$GIT_DIR/" || exit 1
+ ${FIND} objects -depth -print | ${CPIO} -puamd$l "$GIT_DIR/" || exit 1
;;
yes)
mkdir -p "$GIT_DIR/objects/info"
@@ -234,7 +236,7 @@ then
"URL: $repo
Pull: $head_points_at:$origin" &&
git-update-ref "refs/heads/$origin" $(git-rev-parse HEAD) &&
- (cd "$GIT_DIR" && find "refs/heads" -type f -print) |
+ (cd "$GIT_DIR" && ${FIND} "refs/heads" -type f -print) |
while read ref
do
head=`expr "$ref" : 'refs/heads/\(.*\)'` &&
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 40c58ef..5a4550c 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -4,6 +4,8 @@
#
GIT_DIR=`git-rev-parse --git-dir` || exit $?
+: ${FIND:=find}
+: ${XARGS:=xargs}
dc </dev/null 2>/dev/null || {
# This is not a real DC at all -- it just knows how
@@ -20,12 +22,12 @@ dc </dev/null 2>/dev/null || {
}
}
-echo $(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
+echo $(${GIT_FIND} "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
$({
echo 0
# "no-such" is to help Darwin folks by not using xargs -r.
- find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
- xargs du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
+ ${FIND} "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
+ ${XARGS} du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
sed -e 's/[ ].*/ +/'
echo p
} | dc) kilobytes
diff --git a/git-grep.sh b/git-grep.sh
index ad4f2fe..a58ab37 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -6,6 +6,7 @@
USAGE='[<option>...] [-e] <pattern> [<path>...]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+: ${XARGS:=xargs}
got_pattern () {
if [ -z "$no_more_patterns" ]
@@ -59,4 +60,4 @@ done
usage
}
git-ls-files -z "${git_flags[@]}" -- "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern" --
+ ${XARGS} -0 grep "${flags[@]}" -e "$pattern" --
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c9a588..340bde0 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -1,6 +1,8 @@
#!/bin/sh
#
+: ${FIND:=find}
+
usage () {
echo >&2 "usage: $0 [--heads] [--tags] [-u|--upload-pack <upload-pack>]"
echo >&2 " <repository> <refs>..."
@@ -63,7 +65,7 @@ rsync://* )
echo "failed slurping"
exit
}
- (cd $tmpdir && find refs -type f) |
+ (cd $tmpdir && ${FIND} refs -type f) |
while read path
do
cat "$tmpdir/$path" | tr -d '\012'
diff --git a/git-merge.sh b/git-merge.sh
index dc17baf..c9b03c8 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -6,6 +6,7 @@
USAGE='[-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+'
. git-sh-setup
+: ${CPIO:=cpio}
LF='
'
@@ -22,14 +23,14 @@ dropsave() {
savestate() {
# Stash away any local modifications.
git-diff-index -z --name-only $head |
- cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
+ ${CPIO} -0 -o >"$GIT_DIR/MERGE_SAVE"
}
restorestate() {
if test -f "$GIT_DIR/MERGE_SAVE"
then
git reset --hard $head
- cpio -iuv <"$GIT_DIR/MERGE_SAVE"
+ ${CPIO} -iuv <"$GIT_DIR/MERGE_SAVE"
git-update-index --refresh >/dev/null
fi
}
diff --git a/git-prune.sh b/git-prune.sh
index c5a5d29..781393f 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -2,6 +2,7 @@
USAGE='[-n] [--] [<head>...]'
. git-sh-setup
+: ${XARGS:=xargs}
dryrun=
echo=
@@ -27,7 +28,7 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs $echo rm -f
+ ${XARGS} $echo rm -f
rmdir 2>/dev/null [0-9a-f][0-9a-f]
}
@@ -37,7 +38,7 @@ if redundant=$(git-pack-redundant --all
then
if test "" = "$dryrun"
then
- echo "$redundant" | xargs rm -f
+ echo "$redundant" | ${XARGS} rm -f
else
echo rm -f "$redundant"
fi
diff --git a/git-push.sh b/git-push.sh
index 706db99..1a6c96d 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -2,6 +2,7 @@
USAGE='[--all] [--tags] [--force] <repository> [<refspec>...]'
. git-sh-setup
+: ${FIND:=find}
# Parse out parameters and then stop at remote, so that we can
# translate it using .git/branches information
@@ -46,9 +47,9 @@ case "$has_all" in
'')
case "$do_tags,$#" in
yes,1)
- set x $(cd "$GIT_DIR/refs" && find tags -type f -print) ;;
+ set x $(cd "$GIT_DIR/refs" && ${FIND} tags -type f -print) ;;
yes,*)
- set x $(cd "$GIT_DIR/refs" && find tags -type f -print) \
+ set x $(cd "$GIT_DIR/refs" && ${FIND} tags -type f -print) \
$(get_remote_refs_for_push "$@") ;;
,*)
set x $(get_remote_refs_for_push "$@") ;;
diff --git a/git-repack.sh b/git-repack.sh
index 1fafb6e..56a33a7 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -5,6 +5,7 @@
USAGE='[-a] [-d] [-l] [-n]'
. git-sh-setup
+: ${FIND:=find}
no_update_info= all_into_one= remove_redundant= local=
while case "$#" in 0) break ;; esac
@@ -36,7 +37,7 @@ case ",$all_into_one," in
# Redundancy check in all-into-one case is trivial.
existing=`cd "$PACKDIR" && \
- find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
+ ${FIND} . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
if [ "$local" ]; then
--
1.1.6.g0d39d
^ permalink raw reply related
* [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-10 23:35 UTC (permalink / raw)
To: git
git-archimport uses find and xargs directly to find and apply patches.
Replace these by File::Find and save one call to find. Tested on
Solaris 8 with a moderately complex, interrelated set of Arch repos.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-archimport.perl | 34 ++++++++++++++++++++++++----------
1 files changed, 24 insertions(+), 10 deletions(-)
5cd391ce78022806bbe12d5fda5ff49843e53207
diff --git a/git-archimport.perl b/git-archimport.perl
index 841738d..17502a4 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -60,6 +60,7 @@ use Getopt::Std;
use File::Temp qw(tempdir);
use File::Path qw(mkpath rmtree);
use File::Basename qw(basename dirname);
+use File::Find;
use Data::Dumper qw/ Dumper /;
use IPC::Open2;
@@ -664,17 +665,30 @@ sub apply_cset {
# get the changeset
safe_pipe_capture($TLA,'get-changeset',$ps->{id},"$tmp/changeset");
die "Cannot get changeset: $!" if $?;
-
+
+ my @patchlist;
+ my $wanted_patches = sub {
+ # We want all those non-empty *.patch files that do not modify
+ # arch state.
+ if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
+ push @patchlist, $File::Find::name;
+ }
+ }; # perl note: This needs to be an anonymous sub to share
+ # @patchlist correctly.
+
# apply patches
- if (`find $tmp/changeset/patches -type f -name '*.patch'`) {
- # this can be sped up considerably by doing
- # (find | xargs cat) | patch
- # but that cna get mucked up by patches
- # with missing trailing newlines or the standard
- # 'missing newline' flag in the patch - possibly
- # produced with an old/buggy diff.
- # slow and safe, we invoke patch once per patchfile
- `find $tmp/changeset/patches -type f -name '*.patch' -print0 | grep -zv '{arch}' | xargs -iFILE -0 --no-run-if-empty patch -p1 --forward -iFILE`;
+
+ # this can be sped up considerably by applying all the patches in
+ # one pass, as with
+ # (find | xargs cat) | patch
+ # but that can get mucked up by patches with missing trailing
+ # newlines or the standard 'missing newline' flag in the patch -
+ # possibly produced with an old/buggy diff.
+ # slow and safe, we invoke patch once per patchfile
+
+ File::Find ($wanted_patches, $tmp . "/changeset/patches");
+ foreach my $patchname (@patchlist) {
+ safe_pipe_capture("patch", "-p1", "--forward", "-i", $patchname);
die "Problem applying patches! $!" if $?;
}
--
1.1.6.g0d39d
^ permalink raw reply related
* [PATCH 3/3] Use active CPIO, FIND, and XARGS to set built-in defaults.
From: Jason Riedy @ 2006-02-10 23:36 UTC (permalink / raw)
To: git
Move the sed program in the % : %.sh pattern into the shellsedprog
variable. Add clauses to change the CPIO, FIND, and XARGS built-in
defaults if those variables are set. With appropriate settings, all
the current tests pass on Solaris 8 with my personal bizarre setup.
I'll try on a modules-based AIX once the machine's back next week.
I don't really like how I build the sed program, but I can't think of
an easier / better way.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
e512a44ccd488fec29af59e95b35741d4454b118
diff --git a/Makefile b/Makefile
index f240e45..edf785c 100644
--- a/Makefile
+++ b/Makefile
@@ -415,11 +415,21 @@ git$X: git.c $(LIB_FILE)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
+shellsedprog=-e '1s|\#!.*/sh|\#!$(call shq,$(SHELL_PATH))|;'
+shellsedprog+= -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g;'
+ifdef CPIO
+ shellsedprog+= -e 's@^: \$${CPIO:=cpio}@: \$${CPIO:=$(CPIO)}@;'
+endif
+ifdef FIND
+ shellsedprog+= -e 's@^: \$${FIND:=find}@: \$${FIND:=$(FIND)}@;'
+endif
+ifdef XARGS
+ shellsedprog+= -e 's@^: \$${XARGS:=xargs}@: \$${XARGS:=$(XARGS)}@;'
+endif
+
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
- sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.sh >$@
+ sed $(shellsedprog) $@.sh >$@
chmod +x $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
--
1.1.6.g0d39d
^ permalink raw reply related
* Re: [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Randal L. Schwartz @ 2006-02-10 23:47 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1103.1139614557@lotus.CS.Berkeley.EDU>
>>>>> "Jason" == Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
Jason> + if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
If that works, it's only accidentally. Perhaps you wanted !/\{arch\}/ because
curlies are special to regex. Dunno, because I don't know what you're
excluding.
--
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
* Re: [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-11 0:17 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86k6c2ojx6.fsf@blue.stonehenge.com>
And Randal L. Schwartz writes:
- Jason> + if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
-
- If that works, it's only accidentally.
Thanks! Not only is the regex wrong, it's applied to the
wrong quantity. Should be on $File::Find::dir. Looks like
the repos I tested against didn't have any Arch state
patches.
I'll fix this, test it on a nastier set of repos, and re-
send. It'll be an hour or so, at least.
Jason
^ permalink raw reply
* [PATCH] Munge ChangeLog-style commit messages, and grab author name and email.
From: Carl Worth @ 2006-02-11 1:19 UTC (permalink / raw)
To: git
The cairo project has been using ChangeLog-style commit messages, such as:
2006-01-18 Carl Worth <cworth@cworth.org>
* src/cairo-pdf-surface.c: (cairo_pdf_surface_create_for_stream),
(cairo_pdf_surface_create): Fix compilation-breaking typo.
This patch recognizes that style and munges it up into:
Fix compilation-breaking typo.
which results in a much more useful headline within git.
It also grabs the name and email address from the first line and
commits with those as GIT_AUTHOR_NAME and GIT_AUTHOR_MAIL.
It would probably make sense to hide all this munging behind an
appropriate command-line parameter, but I'm offering this up as is in
case it's useful for anyone with similar commit messages.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
---
git-cvsimport.perl | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
2f2002fe619c45cb1be1c0f063416ede242f3552
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 00fc3ba..6b63aa2 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -658,6 +658,12 @@ my $commit = sub {
}
}
+ # Look for name and email from ChangeLog-style commit message
+ if ($logmsg =~ /^\s*\d\d\d\d-\d\d-\d\d\s*(.*)\s*<(.*)>/) {
+ $author_name = $1;
+ $author_email = $2;
+ }
+
exec("env",
"GIT_AUTHOR_NAME=$author_name",
"GIT_AUTHOR_EMAIL=$author_email",
@@ -673,8 +679,73 @@ my $commit = sub {
# compatibility with git2cvs
substr($logmsg,32767) = "" if length($logmsg) > 32767;
+
+ # We do a bunch of munging on the log message here,
+ # particularly for logs that are formatted in a ChangeLog
+ # style.
+
+ my $origlog = $logmsg;
+
+ # Kill initial date/name stamp: YYYY-MM-DD First Last <email@example.com>
+
+ $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^<\n]*<[^>\n]*>\s*$|* \n|mg;
+
+ # Strip out nickle version numbers
+ $logmsg =~ s|^(version )?2.\d\d*$||mg;
+
+ # Remove initial space for each line
+ $logmsg =~ s|^[ \t]+||mg;
+
+ # Collapse space sequences
+ $logmsg =~ s|[ \t]+| |g;
+
+ # Un-fold paragraphs
+ $logmsg =~ s|([^\n])\n([^*+\-\n])|$1 $2|g;
+
+ my @lines = split (/\n/, $logmsg);
+
+ $logmsg = "";
+
+ my $reviews = "";
+
+ foreach my $line (@lines) {
+ # Pull out any reviewed-by name
+ if ($line =~ /^reviewed by:\s*/i) {
+ if ($line !~ /<delete if not using/) {
+ $reviews = $reviews . "\n" . $line;
+ }
+ } else {
+ # find lines begining with '*'
+ if ($line =~ s/^\*\s\s*//) {
+ # strip off filenames
+ while ($line =~ s/^[^ :,]*([,:]| (?=\())\s*// ) {
+ }
+ # strip off function names
+ while ($line =~ s/^\([^)]*\)[,:]*\s*// ) {
+ }
+ }
+ $logmsg = $logmsg . $line . "\n";
+ }
+ }
+ $logmsg = $logmsg . $reviews;
+
+ # Trim initial newlines
+ $logmsg =~ s|^\n+||;
+
+ # Remove initial space for each line
+ $logmsg =~ s|^[ \t]+||mg;
+
+ # Collapse space sequences
+ $logmsg =~ s|[ \t]+| |g;
+
+ # collapse sequences of newlines
+ $logmsg =~ s/\n\n*/\n/g;
+
+ # Remove trailing whitespace
$logmsg =~ s/[\s\n]+\z//;
+# print "<<<< Original\n$origlog\n---- Rewritten\n$logmsg\n<<<<\n";
+
if (@skipped) {
$logmsg .= "\n\n\nSKIPPED:\n\t";
$logmsg .= join("\n\t", @skipped) . "\n";
--
1.1.6.g9da5
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: A Large Angry SCM @ 2006-02-11 1:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd76vqrg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Thanks; good catch. I think we should export GIT_*_{NAME,EMAIL}
> variables explicitly for this particular problem. We probably
> do _not_ want to do the same for GIT_*_DATE though.
Also, git-var complains when used by an account with an empty gcos
field; thereby, breaking all the non-C git commands even when the user
is not committing.
If the _intent_ was to force commiters and author names in commits, why
was the test not placed only in commit-tree.c?
^ permalink raw reply
* [PATCH] Don't propagate SKIPPED warning to future commits.
From: Carl Worth @ 2006-02-11 1:41 UTC (permalink / raw)
To: git
Here's a simple bug fix for the (currently undocumented) -S flag to
git-cvsimport.
The -S flag allows an import to proceed in the face of a missing ,v
file in the CVS repository. It marks this by adding a SKIPPED warning
in the relevant commit.
Without this patch, the SKIPPED warning propagates to all future
commits, (and accumulates with future SKIPPED warnings).
Martin did the original work on -S to fix an import of the cairo
repository.
However, I just discovered that a correct fix for the cairo import
problem was for me to just "rm -rf ~/.cvsps". (I suppose calling with
a -x option would have worked too.)
I don't know how common it is for CVS repositories to change in ways
such that the cvsps cache gets totally confused as in my case, but it
might be worth adding something to cvsimport to help this. Some
options could be:
* Use cvsps -x always, to ignore the cache.
* Warn the user, (perhaps emit some description of stale cache
possibility if the import fails?).
* Add a note to the documentation.
Signed-off-by: Carl Worth <cworth@cworth.org>
---
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
c816d743a1faf65fb209273a471b15c7b51b55df
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 6b63aa2..25db0ed 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -749,6 +749,7 @@ my $commit = sub {
if (@skipped) {
$logmsg .= "\n\n\nSKIPPED:\n\t";
$logmsg .= join("\n\t", @skipped) . "\n";
+ @skipped = ();
}
print $pw "$logmsg\n"
--
1.1.6.g9da5
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-11 2:17 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <43ED3FD3.7020005@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Also, git-var complains when used by an account with an empty gcos
> field; thereby, breaking all the non-C git commands even when the user
> is not committing.
>
> If the _intent_ was to force commiters and author names in commits,
> why was the test not placed only in commit-tree.c?
git-var was more or less intentional. Scripts such as
git-applypatch, git-commit and git-tag use the command to grab
COMMITTER_IDENT to generate sign-off line and tagger information
when asked, and commit-tree.c changes alone would not catch
them.
A user eventually would make commit so it may not be a too bad
to _strongly_ encourage setting up these environment variables,
by being nasty ;-). I agree it would be _very_ annoying until
you either fix your gecos and/or environment.
Ideas welcome.
^ permalink raw reply
* Re: [PATCH] Don't propagate SKIPPED warning to future commits.
From: Junio C Hamano @ 2006-02-11 2:21 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87r76avfhz.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Here's a simple bug fix for the (currently undocumented) -S flag to
> git-cvsimport.
>
> The -S flag allows an import to proceed in the face of a missing ,v
> file in the CVS repository. It marks this by adding a SKIPPED warning
> in the relevant commit.
>
> Without this patch, the SKIPPED warning propagates to all future
> commits, (and accumulates with future SKIPPED warnings).
I might be missing something fundamental, but isn't prapagating
the warning a good thing? If an earlier commit is suspected to
lack some path that needs to be there (I think that is what
"missing ,v file" means), wouldn't later commits built on top of
that one be by definition missing that path?
^ permalink raw reply
* [PATCH] Don't send copies to the From: address
From: Christian Biesinger @ 2006-02-11 2:47 UTC (permalink / raw)
To: git
Sending copies to the from address is pointless. Not
sending copies there makes it possible to do:
git-format-patch --mbox origin
git-send-email 00*
and get a reasonable result.
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
---
git-send-email.perl | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
486a15e29dff39ff5885d7a1e38d6c5c3b70127b
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f1b3ca..31d23d6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -304,9 +304,11 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $2, $_) unless $quiet;
- push @cc, $2;
+ unless ($2 eq $from) {
+ printf("(mbox) Adding cc: %s from line '%s'\n",
+ $2, $_) unless $quiet;
+ push @cc, $2;
+ }
}
} else {
@@ -335,9 +337,11 @@ foreach my $t (@files) {
if (/^Signed-off-by: (.*)$/i) {
my $c = $1;
chomp $c;
- push @cc, $c;
- printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ unless ($c eq $from) {
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_) unless $quiet;
+ }
}
}
}
--
1.1.6.g71f7-dirty
^ permalink raw reply related
* [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-11 2:52 UTC (permalink / raw)
To: git
git-archimport uses find and xargs directly to find and apply patches.
Replace these by File::Find and save one call to find. Tested on
Solaris 8 with a quite complex, interrelated set of Arch repos.
Hopefully handles {arch} subdirectories correctly. Thanks to Randal
Schwartz for pointing out the problem.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-archimport.perl | 39 +++++++++++++++++++++++++++++----------
1 files changed, 29 insertions(+), 10 deletions(-)
8e7119df3d59da189baa741d44b04e7c8da2c421
diff --git a/git-archimport.perl b/git-archimport.perl
index 841738d..ffdf742 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -60,6 +60,7 @@ use Getopt::Std;
use File::Temp qw(tempdir);
use File::Path qw(mkpath rmtree);
use File::Basename qw(basename dirname);
+use File::Find;
use Data::Dumper qw/ Dumper /;
use IPC::Open2;
@@ -664,17 +665,35 @@ sub apply_cset {
# get the changeset
safe_pipe_capture($TLA,'get-changeset',$ps->{id},"$tmp/changeset");
die "Cannot get changeset: $!" if $?;
-
+
+ my @patchlist;
+ my $wanted_patches = sub {
+ # We want all those non-empty *.patch files that do not modify
+ # arch state. The preprocess argument strips out {arch}.
+ if (-f && !-z && /^.*\.patch$/) {
+ push @patchlist, $File::Find::name;
+ }
+ if ($File::Find::dir =~ /\{arch\}/) {
+ print STDERR "AUGH! tested " . $File::Find::name . "\n";
+ }
+ }; # perl note: This needs to be an anonymous sub to share
+ # @patchlist correctly.
+
# apply patches
- if (`find $tmp/changeset/patches -type f -name '*.patch'`) {
- # this can be sped up considerably by doing
- # (find | xargs cat) | patch
- # but that cna get mucked up by patches
- # with missing trailing newlines or the standard
- # 'missing newline' flag in the patch - possibly
- # produced with an old/buggy diff.
- # slow and safe, we invoke patch once per patchfile
- `find $tmp/changeset/patches -type f -name '*.patch' -print0 | grep -zv '{arch}' | xargs -iFILE -0 --no-run-if-empty patch -p1 --forward -iFILE`;
+
+ # this can be sped up considerably by applying all the patches in
+ # one pass, as with
+ # (find | xargs cat) | patch
+ # but that can get mucked up by patches with missing trailing
+ # newlines or the standard 'missing newline' flag in the patch -
+ # possibly produced with an old/buggy diff.
+ # slow and safe, we invoke patch once per patchfile
+
+ File::Find ({wanted => $wanted_patches,
+ preprocess => sub { grep(!/^\{arch\}$/, @_); }},
+ $tmp . "/changeset/patches");
+ foreach my $patchname (@patchlist) {
+ safe_pipe_capture("patch", "-p1", "--forward", "-i", $patchname);
die "Problem applying patches! $!" if $?;
}
--
1.1.6.g0d39d
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: A Large Angry SCM @ 2006-02-11 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvevmtza4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>Also, git-var complains when used by an account with an empty gcos
>>field; thereby, breaking all the non-C git commands even when the user
>>is not committing.
>>
>>If the _intent_ was to force commiters and author names in commits,
>>why was the test not placed only in commit-tree.c?
>
> git-var was more or less intentional. Scripts such as
> git-applypatch, git-commit and git-tag use the command to grab
> COMMITTER_IDENT to generate sign-off line and tagger information
> when asked, and commit-tree.c changes alone would not catch
> them.
>
> A user eventually would make commit so it may not be a too bad
> to _strongly_ encourage setting up these environment variables,
> by being nasty ;-). I agree it would be _very_ annoying until
> you either fix your gecos and/or environment.
>
> Ideas welcome.
It also breaks a lot of commands not related to making commits;
git-fetch for one.
^ permalink raw reply
* Re: [PATCH] Don't send copies to the From: address
From: Junio C Hamano @ 2006-02-11 3:55 UTC (permalink / raw)
To: Christian Biesinger; +Cc: git, Ryan Anderson, Greg Kroah-Hartman
In-Reply-To: <11396260373307-git-send-email-cbiesinger@web.de>
Christian Biesinger <cbiesinger@web.de> writes:
> Sending copies to the from address is pointless.
Ryan, care to defend this part of the code? This behaviour
might have been inherited from Greg's original version.
I cannot speak for Ryan or Greg, but I think the script
deliberately does this to support this workflow:
(1) The original author sends in a patch to a subsystem
maintainer;
(2) The subsystem maintainer applies the patch to her tree,
perhaps with her own sign-off and sign-offs by other people
collected from the list. She examines it and says this
patch is good;
(3) The commit is formatted and sent to higher level of the
foodchain. The message is CC'ed to interested parties in
order to notify that the patch progressed in the
foodchain.
Me, personally I do not like CC: to people on the signed-off-by
list, but dropping a note to From: person makes perfect sense to
me, if it is to notify the progress of the patch.
What you are after _might_ be not CC'ing it if it was your own
patch. Maybe something like this would help, but even if that
is the case I suspect many people want to CC herself so it needs
to be an optional feature.
-- >8 --
[PATCH] Do not CC me
---
git diff
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f1b3ca..a02e2f8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -343,7 +343,7 @@ foreach my $t (@files) {
}
close F;
- $cc = join(", ", unique_email_list(@cc));
+ $cc = join(", ", unique_email_list(grep { $_ ne $from } @cc));
send_message();
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-11 4:14 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <43ED5F60.1010408@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> It also breaks a lot of commands not related to making commits;
> git-fetch for one.
git-sh-setup one is easy to fix. We could say something equally
silly like this instead:
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 1e638e4..157c7e4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -41,7 +41,11 @@ then
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Make sure we are in a valid repository of a vintage we understand.
- GIT_DIR="$GIT_DIR" git-var GIT_AUTHOR_IDENT >/dev/null || exit
+ GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
+ if test $? == 128
+ then
+ exit
+ fi
else
GIT_DIR=$(git-rev-parse --git-dir) || exit
fi
The only thing that code cares about is to use a relatively
cheap command to examine "$GIT_DIR/config" to make sure that the
respository format version recorded in the file is of old enough
vintage we understand; the command to cause .git/config to be
read does not have to be git-var.
So after nixing that one, the remaining users all look like they
do want something reasonable from the user anyway, so for them
git-var that fails when the user has not fixed the unusable
gecos is a desirable thing.
git grep -n git-var '*.sh'
shows:
git-am, git-applypatch, git-format-patch::
use it to add sign-off by the user.
git-commit, git-tag::
use it to record the user identity.
git-pull::
this uses git-var-l which is unfortunate. We should
be able to use git-repo-config instead. Patches
welcome.
^ permalink raw reply related
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