diff options
| -rw-r--r-- | Documentation/git-commit.txt | 19 | ||||
| -rw-r--r-- | Documentation/git-send-email.txt | 10 | ||||
| -rwxr-xr-x | git-bisect.sh | 17 | ||||
| -rwxr-xr-x | git-commit.sh | 6 | ||||
| -rwxr-xr-x | git-rebase.sh | 9 | ||||
| -rwxr-xr-x | git-send-email.perl | 23 | ||||
| -rw-r--r-- | templates/hooks--pre-rebase | 150 |
7 files changed, 206 insertions, 28 deletions
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 5b1b4d378..214ed235c 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -85,27 +85,12 @@ OPTIONS <file>...:: Files to be committed. The meaning of these is different between `--include` and `--only`. Without - either, it defaults `--include` semantics. + either, it defaults `--only` semantics. If you make a commit and then found a mistake immediately after that, you can recover from it with gitlink:git-reset[1]. -WARNING -------- - -The 1.2.0 and its maintenance series 1.2.X will keep the -traditional `--include` semantics as the default when neither -`--only` nor `--include` is specified and `paths...` are given. -This *will* change during the development towards 1.3.0 in the -'master' branch of `git.git` repository. If you are using this -command in your scripts, and you depend on the traditional -`--include` semantics, please update them to explicitly ask for -`--include` semantics. Also if you are used to making partial -commit using `--include` semantics, please train your fingers to -say `git commit --include paths...` (or `git commit -i paths...`). - - Discussion ---------- @@ -121,7 +106,7 @@ even the command is invoked from a subdirectory. That is, update the specified paths to the index and then commit the whole tree. -`git commit --only paths...` largely bypasses the index file and +`git commit paths...` largely bypasses the index file and commits only the changes made to the specified paths. It has however several safety valves to prevent confusion. diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 00537d890..8c58685e2 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -24,6 +24,9 @@ OPTIONS ------- The options available are: +--cc:: + Specify a starting "Cc:" value for each email. + --chain-reply-to, --no-chain-reply-to:: If this is set, each email will be sent as a reply to the previous email sent. If disabled with "--no-chain-reply-to", all emails after @@ -48,6 +51,9 @@ The options available are: Only necessary if --compose is also set. If --compose is not set, this will be prompted for. +--no-signed-off-by-cc:: + Do not add emails foudn in Signed-off-by: lines to the cc list. + --quiet:: Make git-send-email less verbose. One line per email should be all that is output. @@ -61,6 +67,10 @@ The options available are: Only necessary if --compose is also set. If --compose is not set, this will be prompted for. +--suppress-from:: + Do not add the From: address to the cc: list, if it shows up in a From: + line. + --to:: Specify the primary recipient of the emails generated. Generally, this will be the upstream maintainer of the diff --git a/git-bisect.sh b/git-bisect.sh index 07502536c..03df1433e 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -49,9 +49,16 @@ bisect_start() { die "Bad HEAD - I need a symbolic ref" case "$head" in refs/heads/bisect*) - git checkout master || exit + if [ -s "$GIT_DIR/head-name" ]; then + branch=`cat "$GIT_DIR/head-name"` + else + branch=master + fi + git checkout $branch || exit ;; refs/heads/*) + [ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree" + echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name" ;; *) die "Bad HEAD - strange symbolic ref" @@ -159,7 +166,11 @@ bisect_visualize() { bisect_reset() { case "$#" in - 0) branch=master ;; + 0) if [ -s "$GIT_DIR/head-name" ]; then + branch=`cat "$GIT_DIR/head-name"` + else + branch=master + fi ;; 1) test -f "$GIT_DIR/refs/heads/$1" || { echo >&2 "$1 does not seem to be a valid branch" exit 1 @@ -170,7 +181,7 @@ bisect_reset() { esac git checkout "$branch" && rm -fr "$GIT_DIR/refs/bisect" - rm -f "$GIT_DIR/refs/heads/bisect" + rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name" rm -f "$GIT_DIR/BISECT_LOG" rm -f "$GIT_DIR/BISECT_NAMES" } diff --git a/git-commit.sh b/git-commit.sh index fe9b6e752..f7ee1aade 100755 --- a/git-commit.sh +++ b/git-commit.sh @@ -3,7 +3,7 @@ # Copyright (c) 2005 Linus Torvalds # Copyright (c) 2006 Junio C Hamano -USAGE='[-a] [-i] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [--author <author>] [<path>...]' +USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [--author <author>] [[-i | -o] <path>...]' SUBDIRECTORY_OK=Yes . git-sh-setup @@ -341,8 +341,8 @@ case "$#,$also$only" in 0,) ;; *,) - only_include_assumed="# Explicit paths specified without -i nor -o; assuming --include paths..." - also=t + only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..." + also= ;; esac unset only diff --git a/git-rebase.sh b/git-rebase.sh index 16d435983..f84160d32 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -36,6 +36,15 @@ other=$(git-rev-parse --verify "$1^0") || usage # Make sure the branch to rebase is valid. head=$(git-rev-parse --verify "${2-HEAD}^0") || exit +# If a hook exists, give it a chance to interrupt +if test -x "$GIT_DIR/hooks/pre-rebase" +then + "$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || { + echo >&2 "The pre-rebase hook refused to rebase." + exit 1 + } +fi + # If the branch to rebase is given, first switch to it. case "$#" in 2) diff --git a/git-send-email.perl b/git-send-email.perl index 3f1b3ca78..13b85dddd 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -31,10 +31,10 @@ sub cleanup_compose_files(); my $compose_filename = ".msg.$$"; # Variables we fill in automatically, or via prompting: -my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from,$compose); +my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose); # Behavior modification variables -my ($chain_reply_to, $smtp_server, $quiet) = (1, "localhost", 0); +my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0); # Example reply to: #$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>'; @@ -48,10 +48,13 @@ my $rc = GetOptions("from=s" => \$from, "in-reply-to=s" => \$initial_reply_to, "subject=s" => \$initial_subject, "to=s" => \@to, + "cc=s" => \@initial_cc, "chain-reply-to!" => \$chain_reply_to, "smtp-server=s" => \$smtp_server, "compose" => \$compose, "quiet" => \$quiet, + "suppress-from" => \$suppress_from, + "no-signed-off-cc" => \$no_signed_off_cc, ); # Now, let's fill any that aren't set in with defaults: @@ -197,6 +200,9 @@ Options: --to Specify the primary "To:" line of the email. + --cc Specify an initial "Cc:" list for the entire series + of emails. + --compose Use \$EDITOR to edit an introductory message for the patch series. @@ -212,13 +218,19 @@ Options: email sent, rather than to the first email sent. Defaults to on. + --no-signed-off-cc Suppress the automatic addition of email addresses + that appear in a Signed-off-by: line, to the cc: list. + Note: Using this option is not recommended. + --smtp-server If set, specifies the outgoing SMTP server to use. Defaults to localhost. + --suppress-from Supress sending emails to yourself if your address + appears in a From: line. + --quiet Make git-send-email less verbose. One line per email should be all that is output. - Error: Please specify a file or a directory on the command line. EOT exit(1); @@ -290,7 +302,7 @@ $subject = $initial_subject; foreach my $t (@files) { open(F,"<",$t) or die "can't open file $t"; - @cc = (); + @cc = @initial_cc; my $found_mbox = 0; my $header_done = 0; $message = ""; @@ -304,6 +316,7 @@ foreach my $t (@files) { $subject = $1; } elsif (/^(Cc|From):\s+(.*)$/) { + next if ($2 eq $from && $suppress_from); printf("(mbox) Adding cc: %s from line '%s'\n", $2, $_) unless $quiet; push @cc, $2; @@ -332,7 +345,7 @@ foreach my $t (@files) { } } else { $message .= $_; - if (/^Signed-off-by: (.*)$/i) { + if (/^Signed-off-by: (.*)$/i && !$no_signed_off_cc) { my $c = $1; chomp $c; push @cc, $c; diff --git a/templates/hooks--pre-rebase b/templates/hooks--pre-rebase new file mode 100644 index 000000000..981c454cd --- /dev/null +++ b/templates/hooks--pre-rebase @@ -0,0 +1,150 @@ +#!/bin/sh +# +# Copyright (c) 2006 Junio C Hamano +# + +publish=next +basebranch="$1" +if test "$#" = 2 +then + topic="refs/heads/$2" +else + topic=`git symbolic-ref HEAD` +fi + +case "$basebranch,$topic" in +master,refs/heads/??/*) + ;; +*) + exit 0 ;# we do not interrupt others. + ;; +esac + +# Now we are dealing with a topic branch being rebased +# on top of master. Is it OK to rebase it? + +# Is topic fully merged to master? +not_in_master=`git-rev-list --pretty=oneline ^master "$topic"` +if test -z "$not_in_master" +then + echo >&2 "$topic is fully merged to master; better remove it." + exit 1 ;# we could allow it, but there is no point. +fi + +# Is topic ever merged to next? If so you should not be rebasing it. +only_next_1=`git-rev-list ^master "^$topic" ${publish} | sort` +only_next_2=`git-rev-list ^master ${publish} | sort` +if test "$only_next_1" = "$only_next_2" +then + not_in_topic=`git-rev-list "^$topic" master` + if test -z "$not_in_topic" + then + echo >&2 "$topic is already up-to-date with master" + exit 1 ;# we could allow it, but there is no point. + else + exit 0 + fi +else + not_in_next=`git-rev-list --pretty=oneline ^${publish} "$topic"` + perl -e ' + my $topic = $ARGV[0]; + my $msg = "* $topic has commits already merged to public branch:\n"; + my (%not_in_next) = map { + /^([0-9a-f]+) /; + ($1 => 1); + } split(/\n/, $ARGV[1]); + for my $elem (map { + /^([0-9a-f]+) (.*)$/; + [$1 => $2]; + } split(/\n/, $ARGV[2])) { + if (!exists $not_in_next{$elem->[0]}) { + if ($msg) { + print STDERR $msg; + undef $msg; + } + print STDERR " $elem->[1]\n"; + } + } + ' "$topic" "$not_in_next" "$not_in_master" + exit 1 +fi + +exit 0 + +################################################################ + +This sample hook safeguards topic branches that have been +published from being rewound. + +The workflow assumed here is: + + * Once a topic branch forks from "master", "master" is never + merged into it again (either directly or indirectly). + + * Once a topic branch is fully cooked and merged into "master", + it is deleted. If you need to build on top of it to correct + earlier mistakes, a new topic branch is created by forking at + the tip of the "master". This is not strictly necessary, but + it makes it easier to keep your history simple. + + * Whenever you need to test or publish your changes to topic + branches, merge them into "next" branch. + +The script, being an example, hardcodes the publish branch name +to be "next", but it is trivial to make it configurable via +$GIT_DIR/config mechanism. + +With this workflow, you would want to know: + +(1) ... if a topic branch has ever been merged to "next". Young + topic branches can have stupid mistakes you would rather + clean up before publishing, and things that have not been + merged into other branches can be easily rebased without + affecting other people. But once it is published, you would + not want to rewind it. + +(2) ... if a topic branch has been fully merged to "master". + Then you can delete it. More importantly, you should not + build on top of it -- other people may already want to + change things related to the topic as patches against your + "master", so if you need further changes, it is better to + fork the topic (perhaps with the same name) afresh from the + tip of "master". + +Let's look at this example: + + o---o---o---o---o---o---o---o---o---o "next" + / / / / + / a---a---b A / / + / / / / + / / c---c---c---c B / + / / / \ / + / / / b---b C \ / + / / / / \ / + ---o---o---o---o---o---o---o---o---o---o---o "master" + + +A, B and C are topic branches. + + * A has one fix since it was merged up to "next". + + * B has finished. It has been fully merged up to "master" and "next", + and is ready to be deleted. + + * C has not merged to "next" at all. + +We would want to allow C to be rebased, refuse A, and encourage +B to be deleted. + +To compute (1): + + git-rev-list ^master ^topic next + git-rev-list ^master next + + if these match, topic has not merged in next at all. + +To compute (2): + + git-rev-list master..topic + + if this is empty, it is fully merged to "master". |