* Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
From: Matthias Urlichs @ 2005-07-31 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20050731082430.GG32263@mythryan2.michonline.com>
Hi, Ryan Anderson wrote:
> And yes, I did generate this thread with this script - so I have proof
> that it works nicely.
It might make sense to create a "Patch 0/N" with a short explanation, and
have the actual patches be replies to that -- or to patch 1/N if that's
not necessary.
As it is, patch N hangs off patch N-1 in my email threading view, which
gets slightly cumbersome if N>10.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nothing makes a person more productive than the last minute.
^ permalink raw reply
* Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
From: Ryan Anderson @ 2005-07-31 8:24 UTC (permalink / raw)
To: junkio, git
In-Reply-To: <11227978451100@foobar.com>
On Sun, Jul 31, 2005 at 04:17:25AM -0400, Ryan Anderson wrote:
> This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
> all the nice things a good subsystem maintainer does when forwarding a patch or
> 50 upstream:
>
> All the prior handlers of the patch, as determined by the
> Signed-off-by: lines, and/or the author of the commit, are cc:ed on the
> email.
>
> All emails are sent as a reply to the previous email, making it easy to
> skip a collection of emails that are uninteresting.
>
> Signed-off-by: Ryan Anderson <ryan@michonline.com>
And yes, I did generate this thread with this script - so I have proof
that it works nicely.
Actually, with this:
git format-patch -n --mbox -o ../pending/ origin
git send-email ../pending/
<answer some questions>
In 2-3 minutes I should have my git tree at
rsync://h4x0r5.com/git-ryan.git/ updated with these changes, and my
SYNOPSIS draft. (I haven't added the short tutorial that Sam suggested
yet, that's a task for another 4am hackfest.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 2/3] Add documentation for git-send-email-script
From: Ryan Anderson @ 2005-07-31 8:17 UTC (permalink / raw)
To: junkio, git; +Cc: ryan
In-Reply-To: <11227978451100@foobar.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-send-email-script.txt | 61 +++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-send-email-script.txt
799a6320d3b07347869093beec303afbc005cf26
diff --git a/Documentation/git-send-email-script.txt b/Documentation/git-send-email-script.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-send-email-script.txt
@@ -0,0 +1,61 @@
+git-send-email-script(1)
+=======================
+v0.1, July 2005
+
+NAME
+----
+git-send-email-script - Send a collection of patches as emails
+
+
+SYNOPSIS
+--------
+'git-send-email-script' [options] <file|directory> [... file|directory]
+
+
+
+DESCRIPTION
+-----------
+Takes the patches given on the command line and emails them out.
+
+The header of the email is configurable by command line options. If not
+specified on the command line, the user will be prompted with a ReadLine
+enabled interface to provide the necessary information.
+
+The options available are:
+
+ --to
+ Specify the primary recipient of the emails generated.
+ Generally, this will be the upstream maintainer of the
+ project involved.
+
+ --from
+ Specify the sender of the emails. This will default to
+ the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+ The user will still be prompted to confirm this entry.
+
+ --subject
+ Specify the initial subject of the email thread.
+
+ --in-reply-to
+ Specify the contents of the first In-Reply-To header.
+ Subsequent emails will refer to the previous email
+ instead of this.
+ When overriding on the command line, it may be necessary
+ to set this to a space. For example
+ --in-reply-to=" "
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com>
+
+git-send-email-script is originally based upon
+send_lots_of_email.pl by Greg Kroah-Hartman.
+
+Documentation
+--------------
+Documentation by Ryan Anderson
+
+GIT
+---
+Part of the link:git.html[git] suite
+
^ permalink raw reply
* [PATCH 3/3] Add new dependencies caused by git-send-email-script to debian/control
From: Ryan Anderson @ 2005-07-31 8:17 UTC (permalink / raw)
To: junkio, git; +Cc: ryan
In-Reply-To: <112279784541@foobar.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
debian/control | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
6dbf602b0931608831888e779612fcc89b90d16f
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
-Recommends: rsync, curl, ssh
+Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl
Conflicts: git
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
^ permalink raw reply
* [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
From: Ryan Anderson @ 2005-07-31 8:17 UTC (permalink / raw)
To: junkio, git; +Cc: ryan
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
all the nice things a good subsystem maintainer does when forwarding a patch or
50 upstream:
All the prior handlers of the patch, as determined by the
Signed-off-by: lines, and/or the author of the commit, are cc:ed on the
email.
All emails are sent as a reply to the previous email, making it easy to
skip a collection of emails that are uninteresting.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Makefile | 2
git-send-email-script | 265 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 266 insertions(+), 1 deletions(-)
create mode 100755 git-send-email-script
55d4b5b7a11448d60eb00b5a7081954663842b06
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -62,7 +62,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
- git-request-pull-script
+ git-request-pull-script git-send-email-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-send-email-script b/git-send-email-script
new file mode 100755
--- /dev/null
+++ b/git-send-email-script
@@ -0,0 +1,265 @@
+#!/usr/bin/perl -w
+# horrible hack of a script to send off a large number of email messages, one after
+# each other, all chained together. This is useful for large numbers of patches.
+#
+# Use at your own risk!!!!
+#
+# greg kroah-hartman Jan 8, 2002
+# <greg@kroah.com>
+#
+# GPL v2 (See COPYING)
+#
+# Ported to support git "mbox" format files by Ryan Anderson <ryan@michonline.com>
+#
+# Sends emails to the email listed on the command line.
+#
+# updated to give a valid subject and CC the owner of the patch - Jan 2005
+# first line of the message is who to CC,
+# and second line is the subject of the message.
+#
+
+use strict;
+use warnings;
+use Term::ReadLine;
+use Mail::Sendmail;
+use Getopt::Long;
+use Data::Dumper;
+use Email::Valid;
+
+# Variables we fill in automatically, or via prompting:
+my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from);
+
+# Example of them
+# modify these options each time you run the script
+#$to = 'torvalds@osdl.org,git@vger.kernel.org';
+#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
+#$initial_subject = "[PATCH] Deb package build fixes";
+#@files = (qw(
+#0001-Make-debian-rules-executable-and-correct-the-spelling-of-rsync-in.txt
+#0002-Debian-packages-should-include-the-binaries.txt
+#0003-The-deb-package-building-needs-these-two-new-files-to-work-correctly.txt
+#));
+
+# change this to your email address.
+#$from = "Ryan Anderson <ryan\@michonline.com>";
+
+my $term = new Term::ReadLine 'git-send-email';
+
+# Begin by accumulating all the variables (defined above), that we will end up
+# needing, first, from the command line:
+
+my $rc = GetOptions("from=s" => \$from,
+ "in-reply-to=s" => \$initial_reply_to,
+ "subject=s" => \$initial_subject,
+ "to=s" => \@to,
+ );
+
+# Now, let's fill any that aren't set in with defaults:
+
+open(GITVAR,"-|","git-var","-l")
+ or die "Failed to open pipe from git-var: $!";
+
+my ($author,$committer);
+while(<GITVAR>) {
+ chomp;
+ my ($var,$data) = split /=/,$_,2;
+ my @fields = split /\s+/, $data;
+
+ my $ident = join(" ", @fields[0...(@fields-3)]);
+
+ if ($var eq 'GIT_AUTHOR_IDENT') {
+ $author = $ident;
+ } elsif ($var eq 'GIT_COMMITTER_IDENT') {
+ $committer = $ident;
+ }
+}
+close(GITVAR);
+
+
+if (!defined $from) {
+ $from = $author || $committer;
+ 1 while (!defined ($_ = $term->readline("Who should the emails appear to be from? ",
+ $from)));
+ $from = $_;
+ print "Emails will be sent from: ", $from, "\n";
+}
+
+if (!@to) {
+ 1 while (!defined ($_ = $term->readline("Who should the emails be sent to? ",
+ "")));
+ my $to = $_;
+ push @to, split /,/, $to;
+}
+
+if (!defined $initial_subject) {
+ 1 while (!defined ($_ =
+ $term->readline("What subject should the emails start with? ",
+ $initial_subject)));
+ $initial_subject = $_;
+}
+
+if (!defined $initial_reply_to) {
+ 1 while (!defined ($_ =
+ $term->readline("Message-ID to be used as In-Reply-To? ",
+ $initial_reply_to)));
+ $initial_reply_to = $_;
+}
+
+# Now that all the defaults are set, process the rest of the command line
+# arguments and collect up the files that need to be processed.
+for my $f (@ARGV) {
+ if (-d $f) {
+ opendir(DH,$f)
+ or die "Failed to opendir $f: $!";
+
+ push @files, map { +$f . "/" . $_ } grep !/^\.{1,2}$/,
+ sort readdir(DH);
+ } elsif (-f $f) {
+ push @files, $f;
+
+ } else {
+ print STDERR "Skipping $f - not found.\n";
+ }
+}
+
+if (@files) {
+ print $_,"\n" for @files;
+} else {
+ print <<EOT;
+git-send-email-script [options] <file | directory> [... file | directory ]
+Options:
+ --from Specify the "From:" line of the email to be sent.
+ --to Specify the primary "To:" line of the email.
+ --subject Specify the initial "Subject:" line.
+ --in-reply-to Specify the first "In-Reply-To:" header line.
+
+Error: Please specify a file or a directory on the command line.
+EOT
+ exit(1);
+}
+
+# Variables we set as part of the loop over files
+our ($message_id, $cc, %mail, $subject, $reply_to, $message);
+
+
+# Usually don't need to change anything below here.
+
+# we make a "fake" message id by taking the current number
+# of seconds since the beginning of Unix time and tacking on
+# a random number to the end, in case we are called quicker than
+# 1 second since the last time we were called.
+sub make_message_id
+{
+ my $date = `date "+\%s"`;
+ chomp($date);
+ my $pseudo_rand = int (rand(4200));
+ $message_id = "<$date$pseudo_rand\@foobar.com>";
+ print "new message id = $message_id\n";
+}
+
+
+
+$cc = "";
+
+sub send_message
+{
+ my %to;
+ $to{lc(Email::Valid->address($_))}++ for (@to);
+
+ my $to = join(",", keys %to);
+
+ %mail = ( To => $to,
+ From => $from,
+ CC => $cc,
+ Subject => $subject,
+ Message => $message,
+ 'Reply-to' => $from,
+ 'In-Reply-To' => $reply_to,
+ 'Message-ID' => $message_id,
+ 'X-Mailer' => "git-send-email-script",
+ );
+
+ $mail{smtp} = 'localhost';
+
+ #print Data::Dumper->Dump([\%mail],[qw(*mail)]);
+
+ sendmail(%mail) or die $Mail::Sendmail::error;
+
+ print "OK. Log says:\n", $Mail::Sendmail::log;
+ print "\n\n"
+}
+
+
+$reply_to = $initial_reply_to;
+make_message_id();
+$subject = $initial_subject;
+
+foreach my $t (@files) {
+ my $F = $t;
+ open(F,"<",$t) or die "can't open file $t";
+
+ @cc = ();
+ my $found_mbox = 0;
+ my $header_done = 0;
+ $message = "";
+ while(<F>) {
+ if (!$header_done) {
+ $found_mbox = 1, next if (/^From /);
+ chomp;
+
+ if ($found_mbox) {
+ if (/^Subject:\s+(.*)$/) {
+ $subject = $1;
+
+ } elsif (/^(Cc|From):\s+(.*)$/) {
+ printf("(mbox) Adding cc: %s from line '%s'\n",
+ $2, $_);
+ push @cc, $2;
+ }
+
+ } else {
+ # In the traditional
+ # "send lots of email" format,
+ # line 1 = cc
+ # line 2 = subject
+ # So let's support that, too.
+ if (@cc == 0) {
+ printf("(non-mbox) Adding cc: %s from line '%s'\n",
+ $_, $_);
+
+ push @cc, $_;
+
+ } elsif (!defined $subject) {
+ $subject = $_;
+ }
+ }
+
+ # A whitespace line will terminate the headers
+ if (m/^\s*$/) {
+ $header_done = 1;
+ }
+ } else {
+ $message .= $_;
+ if (/^Signed-off-by: (.*)$/i) {
+ my $c = $1;
+ chomp $c;
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_);
+ }
+ }
+ }
+ close F;
+
+ my %clean_ccs;
+ $clean_ccs{lc(Email::Valid->address($_))}++ for @cc;
+
+ $cc = join(",", keys %clean_ccs);
+
+ send_message();
+
+ # set up for the next message
+ $reply_to = $message_id;
+ make_message_id();
+# $subject = "Re: ".$initial_subject;
+}
^ permalink raw reply
* Re: Dump http servers still slow?
From: Junio C Hamano @ 2005-07-31 6:51 UTC (permalink / raw)
To: git; +Cc: Darrin Thompson, barkalow
In-Reply-To: <1122645821.4263.6.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> 1. Pack files should reduce the number of http round trips.
> 2. What I'm seeing when I check out mainline git is the acquisition of a
> single large pack, then 600+ more recent objects. Better than before,
> but still hundreds of round trips.
I've packed the git.git repository, by the way. It has 43
unpacked objects totalling 224 kilobytes, so cloning over dumb
http should go a lot faster until we accumulate more unpacked
objects.
Some of you may have noticed that in the proposed updates queue
("pu" branch) I have a couple of commits related to pulling from
a packed dumb http server. There are two "git fetch http://"
commits to let you pull from such, and another stupid "count
objects" script that you can use to see how many unpacked
objects you have in your repository; the latter is to help
you decide when to repack.
Brave souls may want to try out the dumb http fetch. For
example, it _should_ do the right thing even if you do the
following:
$ git clone http://www.kernel.org/pub/scm/git/git.git/ newdir
$ cd newdir
$ mv .git/objects/pack/pack-* . ;# even if you unpack packs on your
$ rm -f pack-*.idx ;# end, it should do the right thing.
$ for pack in pack-*.pack; do
git-unpack-objects <$pack
rm -f "$pack"
done
$ rm -f .git/refs/heads/pu
$ git prune ;# lose objects in "pu" but still not in "master"
$ git pull origin pu
$ git ls-remote origin |
while read sha1 refname
do
case "$refname" in
refs/heads/master) echo $sha1 >".git/$refname" ;;
esac
done ;# revert master to upstream master
$ old=$(git-rev-parse master^^^^^^^^^^)
$ echo "$old" >.git/refs/heads/master ;# rewind further
$ git checkout -f master
$ git prune ;# try losing a bit more objects.
$ git pull origin master
$ git ls-remote ./. ;# show me my refs
$ git ls-remote origin ;# show me his refs
Unlike my other shell scripts I usually write in my e-mail
buffer, I have actually run the above ;-).
-jc
^ permalink raw reply
* Re: send-pack question.
From: Linus Torvalds @ 2005-07-31 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1x5fwmpk.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jul 2005, Junio C Hamano wrote:
>
> * Right now, "send-pack --all" into an empty repository does
> not do anything, but "send-pack --all master" into an empty
> repository pushes all local heads. This is because we do not
> check "send_all" when deciding if we want to call try_match
> on local references. I am assuming this is an oversight; am
> I correct? If so, does the attached patch look OK?
Yeah, that sounds like me just not having taken my 'meds. The patch looks
fine.
> * It appears to me that you can say "send-pack net", and
> depending on how the remote lists its refs, you can end up
> updating their refs/heads/net or refs/tags/net.
Yeh. I was wanting to sort the refs to make everything be totally
repeatable, but that was more of an urge than a real plan.
> More
> confusingly, you could say "send-pack net net" to update
> both. More realistically, you could get confused with a
> remote that has refs/heads/jgarzik/net and
> refs/heads/dsmiller/net in this way. I think it should
> detect, stop and warn about the ambiguity and require the
> user to be more explicit. Am I reading the current code
> correctly?
Yes, warning on ambiguity sounds like a sound plan, and then you don't
need to sort.
You also probably to come up with a syntax for saying "xyz is the local
name, abc is the remote name". That's needed for both the pulling and the
pushing side, but I didn't ever do it.
> I've always _hated_ the interface to path_match() which
> pretends to be just a boolean function but actually has a
> grave side effect, by the way.
It's "interesting" but useful. But I agree, we've had one bug already due
to the interesting part.
If you do the ambiguity thing, you might mark them used some separate way,
and maybe avoid that side effect (or rather - the side effect would still
exist, but instead of removing the entry, it would just mark it as
"seen", ie make it less drastic).
Linus
^ permalink raw reply
* send-pack question.
From: Junio C Hamano @ 2005-07-31 5:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
I have been looking at send-pack because some people seem to
want to push into a remote repository that names heads
differently from local. I have some questions that do not have
to do with anything about their request, but about what
the current code intends to do.
* Right now, "send-pack --all" into an empty repository does
not do anything, but "send-pack --all master" into an empty
repository pushes all local heads. This is because we do not
check "send_all" when deciding if we want to call try_match
on local references. I am assuming this is an oversight; am
I correct? If so, does the attached patch look OK?
* It appears to me that you can say "send-pack net", and
depending on how the remote lists its refs, you can end up
updating their refs/heads/net or refs/tags/net. More
confusingly, you could say "send-pack net net" to update
both. More realistically, you could get confused with a
remote that has refs/heads/jgarzik/net and
refs/heads/dsmiller/net in this way. I think it should
detect, stop and warn about the ambiguity and require the
user to be more explicit. Am I reading the current code
correctly?
I've always _hated_ the interface to path_match() which
pretends to be just a boolean function but actually has a
grave side effect, by the way.
---
# - pu: git-fetch-script http fix.
# + (working tree)
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -4,7 +4,8 @@
#include "pkt-line.h"
static const char send_pack_usage[] =
-"git-send-pack [--exec=git-receive-pack] [host:]directory [heads]*";
+"git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\n"
+" --all and explicit <head> specification are mutually exclusive.";
static const char *exec = "git-receive-pack";
static int send_all = 0;
static int force_update = 0;
@@ -214,7 +215,7 @@ static int send_pack(int in, int out, in
/*
* See if we have any refs that the other end didn't have
*/
- if (nr_match) {
+ if (nr_match || send_all) {
local_ref_nr_match = nr_match;
local_ref_match = match;
local_ref_list = ref_list;
@@ -281,6 +282,8 @@ int main(int argc, char **argv)
}
if (!dest)
usage(send_pack_usage);
+ if (heads && send_all)
+ usage(send_pack_usage);
pid = git_connect(fd, dest, exec);
if (pid < 0)
return 1;
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Junio C Hamano @ 2005-07-31 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter Osterlund, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507302142380.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 31 Jul 2005, Peter Osterlund wrote:
>>
>> > I bet there is a smarter way to do this, but this _should_ fix the problem
>> > Peter sees. Peter?
>>
>> Yes, it does fix the problem. Thanks.
>
> Ok, Junio, can you apply the git-merge-base patch? It's not perfect, but
> it's clearly better than what's there right now.
>
> Add a "Signed-off-by: Linus Torvalds <torvalds@osdl.org>" and edit the
> description a bit, perhaps.
OK. It's already sitting at the top of the "pu" branch, so I'll
just advance "master" with your sign off added.
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-31 4:44 UTC (permalink / raw)
To: Peter Osterlund; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m3ack3nb3c.fsf@telia.com>
On Sat, 31 Jul 2005, Peter Osterlund wrote:
>
> > I bet there is a smarter way to do this, but this _should_ fix the problem
> > Peter sees. Peter?
>
> Yes, it does fix the problem. Thanks.
Ok, Junio, can you apply the git-merge-base patch? It's not perfect, but
it's clearly better than what's there right now.
Add a "Signed-off-by: Linus Torvalds <torvalds@osdl.org>" and edit the
description a bit, perhaps.
Linus
^ permalink raw reply
* Re: [PATCH] add NO_CURL option to the Makefile
From: Linus Torvalds @ 2005-07-31 4:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vk6j7ye6b.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jul 2005, Junio C Hamano wrote:
>
> I love it I can just slow down and let others submit obviously
> correct patches, which I can just slurp in.
You're obviously doing well as a maintainer. Only stupid people try to do
everything themselves.
Personally, I spend a _lot_ of time communicating, because even if it's a
lot more work to explain (in detail) what I want done, and it doesn't work
out all the time, and I sometimes have to do it myself _anyway_, if it
works even just occasionally, it not only gets people involved, it makes
them do it themselves next time around without prodding, and then you just
sit back, sip a foofy tropical drink, and take the credit.
Linus
^ permalink raw reply
* Re: [PATCH] add NO_CURL option to the Makefile
From: Junio C Hamano @ 2005-07-31 1:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507310213110.13590@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This patch implements Linus' idea that if you are not interested in
> pulling by HTTP, you can now say
>
> NO_CURL=1 make
>
> to compile everything except git-http-pull (thus not needing curl at all).
Thanks. Obviously this does not take care of the use of curl
executable to handle http:// URL in clone and fetch, but I do
not think that is worth the trouble (we should document it
though).
I love it I can just slow down and let others submit obviously
correct patches, which I can just slurp in.
^ permalink raw reply
* [PATCH] Making it easier to find which change introduced a bug
From: Junio C Hamano @ 2005-07-31 1:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0507300919320.29650@g5.osdl.org>
I have placed this, after slight reworking, in the master
branch.
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the next thing you would want to do after telling it
"bad" and "good" is always to bisect, this version does it
automatically for you.
- I think the termination condition was wrong. The original
version checked if the set of revisions reachable from next
bisection but not rechable from any of the known good ones
is empty, but if the current bisection was a bad one, this
would not terminate, so I changed it to terminate it when
the set becomes a singleton or empty.
- Removed the use of shell array variable.
]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 -
git-bisect-script | 158 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 159 insertions(+), 1 deletions(-)
create mode 100755 git-bisect-script
8cc6a083198877fc32224b73c61ec6e6cf8a96f5
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -62,7 +62,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
- git-request-pull-script
+ git-request-pull-script git-bisect-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-bisect-script b/git-bisect-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-script
@@ -0,0 +1,158 @@
+#!/bin/sh
+. git-sh-setup-script || dir "Not a git archive"
+
+usage() {
+ echo >&2 'usage: git bisect [start | bad | good | next | reset]
+git bisect start reset bisect state and start bisection.
+git bisect bad [<rev>] mark <rev> a known-bad revision.
+git bisect good [<rev>...] mark <rev>... known-good revisions.
+git bisect next find next bisection to test and check it out.
+git bisect reset [<branch>] finish bisection search and go back to branch.'
+ exit 1
+}
+
+bisect_autostart() {
+ test -d "$GIT_DIR/refs/bisect" || {
+ echo >&2 'You need to start by "git bisect start"'
+ if test -t 0
+ then
+ echo >&2 -n 'Do you want me to do it for you [Y/n]? '
+ read yesno
+ case "$yesno" in
+ [Nn]*)
+ exit ;;
+ esac
+ bisect_start
+ else
+ exit 1
+ fi
+ }
+}
+
+bisect_start() {
+ case "$#" in 0) ;; *) usage ;; esac
+ #
+ # Verify HEAD. If we were bisecting before this, reset to the
+ # top-of-line master first!
+ #
+ head=$(readlink $GIT_DIR/HEAD) || die "Bad HEAD - I need a symlink"
+ case "$head" in
+ refs/heads/bisect*)
+ git checkout master || exit
+ ;;
+ refs/heads/*)
+ ;;
+ *)
+ die "Bad HEAD - strange symlink"
+ ;;
+ esac
+
+ #
+ # Get rid of any old bisect state
+ #
+ rm -f "$GIT_DIR/refs/heads/bisect"
+ rm -rf "$GIT_DIR/refs/bisect/"
+ mkdir "$GIT_DIR/refs/bisect"
+}
+
+bisect_bad() {
+ bisect_autostart
+ case "$#" in 0 | 1) ;; *) usage ;; esac
+ rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
+ echo "$rev" > "$GIT_DIR/refs/bisect/bad"
+ bisect_auto_next
+}
+
+bisect_good() {
+ bisect_autostart
+ case "$#" in
+ 0) revs=$(git-rev-parse --verify HEAD) || exit ;;
+ *) revs=$(git-rev-parse --revs-only "$@") || exit ;;
+ esac
+ for rev in $revs
+ do
+ echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev"
+ done
+ bisect_auto_next
+}
+
+bisect_next_check() {
+ next_ok=no
+ test -f "$GIT_DIR/refs/bisect/bad" &&
+ case "$(cd "$GIT_DIR" && echo refs/bisect/good-*)" in
+ refs/bisect/good-\*) ;;
+ *) next_ok=yes ;;
+ esac
+ case "$next_ok,$1" in
+ no,) false ;;
+ no,fail)
+ echo >&2 'You need to give me at least one good and one bad revisions.'
+ exit 1 ;;
+ *)
+ true ;;
+ esac
+}
+
+bisect_auto_next() {
+ bisect_next_check && bisect_next
+}
+
+bisect_next() {
+ case "$#" in 0) ;; *) usage ;; esac
+ bisect_autostart
+ bisect_next_check fail
+ bad=$(git-rev-parse --verify refs/bisect/bad) &&
+ good=$(git-rev-parse --sq --revs-only --not \
+ $(cd "$GIT_DIR" && ls refs/bisect/good-*)) &&
+ rev=$(eval "git-rev-list --bisect $good $bad") || exit
+ nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
+ if [ "$nr" -le "1" ]; then
+ echo "$bad is first bad commit"
+ git-diff-tree --pretty $bad
+ exit 0
+ fi
+ echo "Bisecting: $nr revisions left to test after this"
+ echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
+ git checkout new-bisect || exit
+ mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
+ ln -sf refs/heads/bisect "$GIT_DIR/HEAD"
+}
+
+bisect_reset() {
+ case "$#" in
+ 0) branch=master ;;
+ 1) test -f "$GIT_DIR/refs/heads/$1" || {
+ echo >&2 "$1 does not seem to be a valid branch"
+ exit 1
+ }
+ branch="$1" ;;
+ *)
+ usage ;;
+ esac
+ git checkout "$branch" &&
+ rm -fr "$GIT_DIR/refs/bisect"
+ rm -f "$GIT_DIR/refs/reads/bisect"
+}
+
+case "$#" in
+0)
+ usage ;;
+*)
+ cmd="$1"
+ shift
+ case "$cmd" in
+ start)
+ bisect_start "$@" ;;
+ bad)
+ bisect_bad "$@" ;;
+ good)
+ bisect_good "$@" ;;
+ next)
+ # Not sure we want "next" at the UI level anymore.
+ bisect_next "$@" ;;
+ reset)
+ bisect_reset "$@" ;;
+ *)
+ usage ;;
+ esac
+esac
^ permalink raw reply
* [PATCH] add NO_CURL option to the Makefile
From: Johannes Schindelin @ 2005-07-31 0:14 UTC (permalink / raw)
To: git
This patch implements Linus' idea that if you are not interested in
pulling by HTTP, you can now say
NO_CURL=1 make
to compile everything except git-http-pull (thus not needing curl at all).
---
Makefile | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
b2e1e7eb6876b5f385bc52bf78e9551d1457215b
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -69,7 +69,7 @@ PROG= git-update-cache git-diff-files
git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
git-check-files git-ls-tree git-merge-base git-merge-cache \
git-unpack-file git-export git-diff-cache git-convert-cache \
- git-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \
+ git-ssh-push git-ssh-pull git-rev-list git-mktag \
git-diff-helper git-tar-tree git-local-pull git-hash-object \
git-get-tar-commit-id git-apply git-stripspace \
git-diff-stages git-rev-parse git-patch-id git-pack-objects \
@@ -78,6 +78,10 @@ PROG= git-update-cache git-diff-files
git-show-index git-daemon git-var git-peek-remote \
git-update-server-info git-show-rev-cache git-build-rev-cache
+ifndef NO_CURL
+PROG+= git-http-pull
+endif
+
LIB_FILE=libgit.a
LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h csum-file.h \
pack.h pkt-line.h refs.h
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Peter Osterlund @ 2005-07-30 23:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507301507390.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 30 Jul 2005, Linus Torvalds wrote:
> >
> > Yup, it's git-merge-base, and it is confused by the same thing that
> > confused git-rev-list.
> >
> > Thanks, I'll fix it.
>
> Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
> somebody else can come up with a better one. I think this one ends up
> being quite a bit more expensive than the old one (it will look up _all_
> common parents that have a child that isn't common, and then select the
> newest one of the bunch), but I haven't really thought it through very
> much.
>
> I bet there is a smarter way to do this, but this _should_ fix the problem
> Peter sees. Peter?
Yes, it does fix the problem. Thanks.
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-30 22:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vek9igfgw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Having said that, I do not particulary think allowing push to
> write into different ref is an unreasonable thing. As you
> pointed out long time ago when send-pack was first done, the
> protocol is not so easily extensible, so this may require either
> backward incompatible protocol change, or introduction of a new
> program pair send-pack-2 / receive-pack-2. I'll take a look
> sometime this weekend. Bedtime.
Again, what Linus designed turns out to be perfect. It does not
appear to need a protocol level change at all. I'll code up
something over the weekend if I am lucky.
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 22:10 UTC (permalink / raw)
To: Peter Osterlund; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507301428300.29650@g5.osdl.org>
On Sat, 30 Jul 2005, Linus Torvalds wrote:
>
> Yup, it's git-merge-base, and it is confused by the same thing that
> confused git-rev-list.
>
> Thanks, I'll fix it.
Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
somebody else can come up with a better one. I think this one ends up
being quite a bit more expensive than the old one (it will look up _all_
common parents that have a child that isn't common, and then select the
newest one of the bunch), but I haven't really thought it through very
much.
I bet there is a smarter way to do this, but this _should_ fix the problem
Peter sees. Peter?
Linus
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -2,54 +2,50 @@
#include "cache.h"
#include "commit.h"
-static struct commit *process_list(struct commit_list **list_p, int this_mark,
- int other_mark)
-{
- struct commit *item = (*list_p)->item;
-
- if (item->object.flags & other_mark) {
- return item;
- } else {
- pop_most_recent_commit(list_p, this_mark);
- }
- return NULL;
-}
-
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
- struct commit_list *rev1list = NULL;
- struct commit_list *rev2list = NULL;
+ struct commit_list *list = NULL;
+ struct commit_list *result = NULL;
- commit_list_insert(rev1, &rev1list);
- rev1->object.flags |= 0x1;
- commit_list_insert(rev2, &rev2list);
- rev2->object.flags |= 0x2;
+ if (rev1 == rev2)
+ return rev1;
parse_commit(rev1);
parse_commit(rev2);
- while (rev1list || rev2list) {
- struct commit *ret;
- if (!rev1list) {
- // process 2
- ret = process_list(&rev2list, 0x2, 0x1);
- } else if (!rev2list) {
- // process 1
- ret = process_list(&rev1list, 0x1, 0x2);
- } else if (rev1list->item->date < rev2list->item->date) {
- // process 2
- ret = process_list(&rev2list, 0x2, 0x1);
- } else {
- // process 1
- ret = process_list(&rev1list, 0x1, 0x2);
+ rev1->object.flags |= 1;
+ rev2->object.flags |= 2;
+ insert_by_date(rev1, &list);
+ insert_by_date(rev2, &list);
+
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *tmp = list, *parents;
+ int flags = commit->object.flags & 3;
+
+ list = list->next;
+ free(tmp);
+ switch (flags) {
+ case 3:
+ insert_by_date(commit, &result);
+ continue;
+ case 0:
+ die("git-merge-base: commit without either parent?");
}
- if (ret) {
- free_commit_list(rev1list);
- free_commit_list(rev2list);
- return ret;
+ parents = commit->parents;
+ while (parents) {
+ struct commit *p = parents->item;
+ parents = parents->next;
+ if ((p->object.flags & flags) == flags)
+ continue;
+ parse_commit(p);
+ p->object.flags |= flags;
+ insert_by_date(p, &list);
}
}
- return NULL;
+ if (!result)
+ return NULL;
+ return result->item;
}
int main(int argc, char **argv)
@@ -64,6 +60,8 @@ int main(int argc, char **argv)
}
rev1 = lookup_commit_reference(rev1key);
rev2 = lookup_commit_reference(rev2key);
+ if (!rev1 || !rev2)
+ return 1;
ret = common_ancestor(rev1, rev2);
if (!ret)
return 1;
^ permalink raw reply
* Shipping gitk as part of core git.
From: Junio C Hamano @ 2005-07-30 21:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vy87o6htm.fsf@assigned-by-dhcp.cox.net>
It appears that gitk gets wider test coverage only after it is
pulled into git.git repository. I think it would be a good idea
for me to pull from you often.
Recently there was a discussion with binary packaging folks.
While I do not mind, and actually I would prefer, shipping gitk
as part of the core GIT, I have never heard about your
preference. As long as gitk is just a single file (or even a
handful files in the future) project that does not have a
filename that overlaps with core GIT, I can continue pulling
from you and I think the binary packaging folks can produce
separate git-core and gitk package out of git.git tree without
problems. However, once you start wanting to have your own
Makefile and maybe debian/rules file for packaging, for example,
I suspect the way currently things are set up would break
miserably. It's all Linus' fault to have merged with your tree
in the first place ;-).
Anyhow, I have one bug to report. I selected one rev, and then
said "diff this -> selected" from right-click menu on an
adjacent one, and I got this:
wrong # args: should be "startdiff ids"
wrong # args: should be "startdiff ids"
while executing
"startdiff $newid [list $oldid]"
(procedure "diffvssel" line 28)
invoked from within
"diffvssel 0"
invoked from within
".rowctxmenu invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 47)
invoked from within
"tk::MenuInvoke .rowctxmenu 1"
(command bound to event)
The following seems to fix it.
------------
Fix diff invoked from the right-click menu.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
# - master: [PATCH] Making it easier to find which change introduced a bug
# + (working tree)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -2700,7 +2700,7 @@ proc diffvssel {dirn} {
$ctext conf -state disabled
$ctext tag delete Comments
$ctext tag remove found 1.0 end
- startdiff $newid [list $oldid]
+ startdiff [list $newid $oldid]
}
proc mkpatch {} {
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 21:32 UTC (permalink / raw)
To: Peter Osterlund; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507302259140.26128@telia.com>
On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > Can you send me your HEAD and MERGE_HEAD (don't do the merge).
>
> HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2
> MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c
Bingo.
Yup, it's git-merge-base, and it is confused by the same thing that
confused git-rev-list.
Thanks, I'll fix it.
Linus
^ permalink raw reply
* Stacked GIT 0.5
From: Catalin Marinas @ 2005-07-30 21:32 UTC (permalink / raw)
To: GIT
Stacked GIT 0.5 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
Note that StGIT is not an SCM interface on top of GIT and it expects a
previously initialised GIT repository. For standard SCM operations,
either use plain GIT commands or the Cogito tool.
For more information, see the README file in the archive.
What's new in this release (the full ChangeLog is in the archive):
* Improved help for commands
* 'mail' command to automatically e-mail a range of patches. The
e-mail format is fully configurable via templates
* 'import' command to import a GNU diff patch. The patch file can
be a standard e-mail message or a normal file with the patch
description at the top
* 'pull' command to automatically advance the base of the stack
and merge the changes into the applied patches
* 'clean' command to delete the empty patches in a series
* 'rename' command to change the name of a patch
* '--range' option for the 'export' command
* '--force' option for the 'new' command to create a patch even if
there are local changes in the tree
* Default templates for the 'export' and 'mail' commands
(installed in /usr/share/stgit/templates/)
* Bug fixes
--
Catalin
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Peter Osterlund @ 2005-07-30 21:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507301354000.29650@g5.osdl.org>
On Sat, 30 Jul 2005, Linus Torvalds wrote:
> On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > OK, but note that I didn't do any editing of any local files myself.
> > Both commit ids are from your public linux kernel git tree. What I did
> > was equivalent to:
> >
> > 1. rsync from rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > 2. waited a day or so.
> > 3. git-pull-script from the same kernel.org repository.
> >
> > Is it expected that you end up with merge conflicts in this case?
>
> Nope. Something went wrong.
>
> > I think it should be possible to just fast forward to the new HEAD in
> > this situation.
>
> Indeed.
>
> Can you send me your HEAD and MERGE_HEAD (don't do the merge).
HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2
MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 20:56 UTC (permalink / raw)
To: Peter Osterlund; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m3fytwm313.fsf@telia.com>
On Sat, 30 Jul 2005, Peter Osterlund wrote:
>
> OK, but note that I didn't do any editing of any local files myself.
> Both commit ids are from your public linux kernel git tree. What I did
> was equivalent to:
>
> 1. rsync from rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> 2. waited a day or so.
> 3. git-pull-script from the same kernel.org repository.
>
> Is it expected that you end up with merge conflicts in this case?
Nope. Something went wrong.
> I think it should be possible to just fast forward to the new HEAD in
> this situation.
Indeed.
Can you send me your HEAD and MERGE_HEAD (don't do the merge).
Sounds like maybe "git-merge-base" is confused, and thinks HEAD is not
reachable from FETCH_HEAD. It could have a similar bug git-rev-list had.
Linus
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Peter Osterlund @ 2005-07-30 20:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507300913000.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > I have problems pulling linux kernel changes from
> > 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
> > b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
> > I thought your patch would fix it, but it doesn't:
>
> No, this is a merge conflict failure, and you simply have conflicts in the
> tree. git did everything right, it just couldn't do an automatic merge.
OK, but note that I didn't do any editing of any local files myself.
Both commit ids are from your public linux kernel git tree. What I did
was equivalent to:
1. rsync from rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
2. waited a day or so.
3. git-pull-script from the same kernel.org repository.
Is it expected that you end up with merge conflicts in this case? If
that's the case, is there a better way to pull changes that doesn't
involve having to resolve conflicts in files you didn't even know
existed?
I think it should be possible to just fast forward to the new HEAD in
this situation.
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: [PATCH 0/2] Bits from git-pb
From: Junio C Hamano @ 2005-07-30 17:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <7v8xzo42ru.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I have not answered this because I have not made up my mind.
> Certainly (iii) is probably the least work for me.
Certainly? Probably? Which one? I should not start typing
before having a cup of coffee. **BLUSH**
Anyway, yes I would appreciate if you take (iii) for the time
being but if that is too much work for you then don't worry I'll
learn to cope with any of the above.
^ permalink raw reply
* Re: [PATCH 0/2] Bits from git-pb
From: Junio C Hamano @ 2005-07-30 17:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20050730103103.GB26188@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
>> (iii) Do wild things in the git-pb branch and send you patches.
>
> So I assume (iii) holds?
I have not answered this because I have not made up my mind.
Certainly (iii) is probably the least work for me.
My gut feeling is that I can deal with any of the above, but
even when I pull from your tree, I expect to pull into "pu"
first and after that the patches will go through my regular
reshuffling cycle just like other patches I receive from
e-mails. This may or may not cause "interesting" troubles when
I merge again from git-pb, but we will see.
^ 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