* interactive rebase not rebasing
From: Stephen Haberman @ 2008-09-29 4:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
Hello,
Per the emails from me last week, I'm working in an environment with
shared topic branches and am trying to find a bullet-proof way for devs
to rebase their local commits after the topic branch has moved.
The easy approach would be to just let `git pull` create merge commits,
and I would have been done with this long ago, but I'm striving to get
rebasing to "just work" and avoid the ugliness of same-branch merge
commits. Cross-branch merge commits are cool, but not same-branch.
So, here's a crazy scenario we've ran into--a new release has hit
stable, with two devs working on the same topic branch, and both of them
merge. One wins, and the other has to rebase. Previously, this was
replaying commits, but with great tips from the list last week, `rebase
-i -p` is handling most scenarios.
However, not this one:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
topic2 is a dev that has locally merged stable in g, moved on in h, is
ready to push, but another dev already merged stable in E, and also
committed F.
If we do a `git pull --no-rebase`, the result is:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
But i is a same-branch merge, and we'd rather rebase to something like:
# A --C------ <-- origin/stable
# \ \
# B -- D -- E -- F <-- origin/topic2
# \
# h' <-- topic2
(...maybe g' in there if g resolved stable conflicts differently
E did them. I'm not sure, I haven't gotten there yet.)
However, currently, `git rebase -i -p origin/topic2` results in:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
Nothing has changed. g & h haven't moved...I can keep executing this
operation and the commits never make it on top of origin/topic2's F.
Frustratingly, if I run non-interactive rebase, it works perfectly. But
I've got other cases (see earlier posts) that do need the interactive
rebase. Personally, I could probably make do with trying each and
seeing what happened, but I'm really trying to find a bullet proof
command/alias/script for devs to run and have it "just work".
I've attached a test that sets up the DAG as above and currently passes
by asserting the not-desired/unchanged-DAG result. The assert for the
desired result is commented out at the end.
Am I correct in asserting this is some sort of bug in the interactive
rebase such that g & h are not ending up on top of F?
Thanks,
Stephen
[-- Attachment #2: t3404b.sh --]
[-- Type: text/x-sh, Size: 2680 bytes --]
#!/bin/sh
test_description='rebase interactive does not rebase'
. ./test-lib.sh
test_expect_success 'setup' '
echo "setup" >a &&
git add a &&
git commit -m "setup" &&
git clone ./. server &&
rm -fr server/.git/hooks &&
git remote add origin ./server &&
git config --add branch.master.remote origin &&
git config --add branch.master.merge refs/heads/master &&
git fetch &&
git checkout -b stable master &&
echo "setup.stable" >a &&
git commit -a -m "stable" &&
git push origin stable
'
#
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
#
# Trying to push F..i
#
# merge-base(F, h) has two options: B and C
#
test_expect_success 'merging in stable with tricky double baserev does not fool the script' '
# B: start our topic2 branch, and share it
git checkout -b topic2 origin/stable &&
git config --add branch.topic2.merge refs/heads/topic2 &&
echo "commit B" >a.topic2 &&
git add a.topic2 &&
git commit -m "commit B created topic2" &&
git push origin topic2 &&
# C: now, separately, move ahead stable, and share it
git checkout stable
echo "commit C" >a &&
git commit -a -m "commit C moved stable" &&
git push origin stable &&
# D: have another client commit (in this case, it is the server, but close enough) moves topic2
cd server &&
git checkout topic2 &&
echo "commit D continuing topic2" >a.client2 &&
git add a.client2 &&
git commit -m "commit D by client2" &&
# E: the same other client merges the moved stable
git merge stable &&
# F: the same other client moves topic2 again
echo "commit F" >a.client2 &&
git commit -a -m "commit F by client2" &&
F_hash=$(git rev-parse HEAD) &&
cd .. &&
# g: now locally merge in the moved stable (even though our topic2 is out of date)
git checkout topic2 &&
git merge stable &&
g_hash=$(git rev-parse HEAD) &&
# h: advance local topic2
echo "commit H" >a.topic2 &&
git commit -a -m "commit H continues local fork" &&
h_hash=$(git rev-parse HEAD) &&
# i: make a new merge commit
git pull --no-rebase &&
i_hash=$(git rev-parse HEAD) &&
# Watch merge rejected as something that should get rebased
# ! git push origin topic2
test "$i_hash $h_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Now fix it the merge by rebasing it
git reset --hard ORIG_HEAD &&
GIT_EDITOR=: git rebase -i -p origin/topic2 &&
h2_hash=$(git rev-parse HEAD) &&
# Should be:
# test "$h2_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# But is just:
test "$h_hash $g_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Where did $F_hash go?
'
test_done
^ permalink raw reply
* [RFC 6/9] Docs: send-email: Remove unnecessary config variable description
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <20080929003636.GA18552@coredump.intra.peff.net>
The config variables are mentioned within the descriptions of the
command line options with which they are associated.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 91 +++++++-------------------------------
1 files changed, 16 insertions(+), 75 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 6b62032..0d6ac4a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,7 +24,8 @@ OPTIONS
The options available are:
--bcc::
- Specify a "Bcc:" value for each email.
+ Specify a "Bcc:" value for each email. Default is the value of
+ 'sendemail.bcc'.
+
The --bcc option must be repeated for each user you want on the bcc list.
@@ -85,9 +86,9 @@ The --cc option must be repeated for each user you want on the cc list.
all that is output.
--[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -97,22 +98,13 @@ The --cc option must be repeated for each user you want on the cc list.
--smtp-pass::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password.
-+
-In place of this option, the following configuration variables
-can be specified:
-+
---
- * sendemail.smtppass
- * sendemail.<identity>.smtppass (see sendemail.identity).
---
-+
-However, --smtp-pass always overrides these variables.
+ the password. Default is the value of 'sendemail.smtppass',
+ however '--smtp-pass' always overrides this value.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
---smtp-user or a configuration variable), but no password has been
-specified (with --smtp-pass or a configuration variable), then the
+'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
+specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
user is prompted for a password while the input is masked for privacy.
--smtp-server::
@@ -128,24 +120,15 @@ user is prompted for a password while the input is masked for privacy.
--smtp-server-port::
Specifies a port different from the default port (SMTP
servers typically listen to smtp port 25 and ssmtp port
- 465).
+ 465). This can be set with 'sendemail.smtpserverport'.
--smtp-ssl::
- Legacy alias for '--smtp-encryption=ssl'.
+ Legacy alias for '--smtp-encryption ssl'.
--smtp-user::
- Username for SMTP-AUTH. In place of this option, the following
- configuration variables can be specified:
-+
---
- * sendemail.smtpuser
- * sendemail.<identity>.smtpuser (see sendemail.identity).
---
-+
-However, --smtp-user always overrides these variables.
-+
-If a username is not specified (with --smtp-user or a
-configuration variable), then authentication is not attempted.
+ Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser';
+ if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
+ then authentication is not attempted.
--subject::
Specify the initial subject of the email thread.
@@ -191,18 +174,12 @@ The --to option must be repeated for each user you want on the to list.
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
+
-This option can be set with sendemail[.<identity>].validate; default to --validate
+Default is the value of 'sendemail.validate'; if this is not set,
+default to '--validate'.
CONFIGURATION
-------------
-sendemail.identity::
- The default configuration identity. When specified,
- 'sendemail.<identity>.<item>' will have higher precedence than
- 'sendemail.<item>'. This is useful to declare multiple SMTP
- identities and to hoist sensitive authentication information
- out of the repository and into the global configuration file.
-
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -211,42 +188,6 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
-sendemail.to::
- Email address (or alias) to always send to.
-
-sendemail.cccmd::
- Command to execute to generate per patch file specific "Cc:"s.
-
-sendemail.bcc::
- Email address (or alias) to always bcc.
-
-sendemail.chainreplyto::
- Boolean value specifying the default to the '--[no-]chain-reply-to'
- parameter.
-
-sendemail.smtpserver::
- Default SMTP server to use.
-
-sendemail.smtpserverport::
- Default SMTP server port to use.
-
-sendemail.smtpuser::
- Default SMTP-AUTH username.
-
-sendemail.smtppass::
- Default SMTP-AUTH password.
-
-sendemail.smtpencryption::
- Default encryption method. Use 'ssl' for SSL (and specify an
- appropriate port), or 'tls' for TLS. Takes precedence over
- 'smtpssl' if both are specified.
-
-sendemail.smtpssl::
- Legacy boolean that sets 'smtpencryption=ssl' if enabled.
-
-sendemail.validate::
- Boolean override for --[no-]validate.
-
Author
------
Written by Ryan Anderson <ryan@michonline.com>
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 7/9] send-email: Completely replace --signed-off-cc with --signed-off-by-cc
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-1-git-send-email-mfwitten@mit.edu>
This breaks backwards compatibility, but so what---get off your
lazy arses and remove the cruft.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0d6ac4a..8ffe525 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -87,7 +87,7 @@ The --cc option must be repeated for each user you want on the cc list.
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
--smtp-encryption::
diff --git a/git-send-email.perl b/git-send-email.perl
index 3467cf1..4662d28 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -144,7 +144,7 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate);
@@ -154,7 +154,7 @@ my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
- "signedoffcc" => [\$signed_off_cc, undef],
+ "signedoffbycc" => [\$signed_off_by_cc, undef],
"validate" => [\$validate, 1],
);
@@ -218,7 +218,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
- "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+ "signed-off-by-cc!" => \$signed_off_by_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -294,7 +294,7 @@ if ($suppress_cc{'all'}) {
# If explicit old-style ones are specified, they trump --suppress-cc.
$suppress_cc{'self'} = $suppress_from if defined $suppress_from;
-$suppress_cc{'sob'} = !$signed_off_cc if defined $signed_off_cc;
+$suppress_cc{'sob'} = !$signed_off_by_cc if defined $signed_off_by_cc;
# Debugging, print out the suppressions.
if (0) {
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 9/9] Docs: send-email: Create logical groupings for man text
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-3-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Within these groups, the options are sorted alphabetically.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 119 ++++++++++++++++++++++----------------
1 files changed, 69 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 8ffe525..82f5056 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -19,9 +19,12 @@ 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.
+
OPTIONS
-------
-The options available are:
+
+Composing
+~~~~~~~~~
--bcc::
Specify a "Bcc:" value for each email. Default is the value of
@@ -34,46 +37,15 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
---cc-cmd::
- Specify a command to execute once per patch file which
- should generate patch file specific "Cc:" entries.
- Output of this command must be single email address per line.
- Default is the value of 'sendemail.cccmd' configuration value.
-
---[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
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series. Default is the value of the 'sendemail.chainreplyto'
- configuration value; if that is unspecified, default to --chain-reply-to.
-
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---dry-run::
- Do everything except actually send the emails.
-
---envelope-sender::
- Specify the envelope sender used to send the emails.
- This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter. Default is the value of
- the 'sendemail.envelopesender' configuration variable; if that is
- unspecified, choosing the envelope sender is left to your MTA.
-
--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.
---identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of 'sendemail.identity'.
-
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -81,14 +53,30 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
---[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffbycc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+--to::
+ Specify the primary recipient of the emails generated. Generally, this
+ will be the upstream maintainer of the project involved. Default is the
+ value of the 'sendemail.to' configuration value; if that is unspecified,
+ this will be prompted for.
++
+The --to option must be repeated for each user you want on the to list.
+
+
+Sending
+~~~~~~~
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of
+ the 'sendemail.envelopesender' configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -130,10 +118,34 @@ user is prompted for a password while the input is masked for privacy.
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+
+Automating
+~~~~~~~~~~
+
+--cc-cmd::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.cccmd' configuration value.
+
+--[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
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series. Default is the value of the 'sendemail.chainreplyto'
+ configuration value; if that is unspecified, default to --chain-reply-to.
+
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
+--[no-]signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffbycc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
Specify an additional category of recipients to suppress the
@@ -157,13 +169,16 @@ user is prompted for a password while the input is masked for privacy.
header set. Default is the value of the 'sendemail.thread' configuration
value; if that is unspecified, default to --thread.
---to::
- Specify the primary recipient of the emails generated. Generally, this
- will be the upstream maintainer of the project involved. Default is the
- value of the 'sendemail.to' configuration value; if that is unspecified,
- this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
+
+Administering
+~~~~~~~~~~~~~
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
--[no-]validate::
Perform sanity checks on patches.
@@ -180,6 +195,7 @@ default to '--validate'.
CONFIGURATION
-------------
+
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -188,6 +204,7 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
@@ -195,10 +212,12 @@ Written by Ryan Anderson <ryan@michonline.com>
git-send-email is originally based upon
send_lots_of_email.pl by Greg Kroah-Hartman.
+
Documentation
--------------
Documentation by Ryan Anderson
+
GIT
---
Part of the linkgit:git[1] suite
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 8/9] Docs: send-email: Create logical groupings for --help text
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-2-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 61 ++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4662d28..127acb7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -39,33 +39,40 @@ package main;
sub usage {
print <<EOT;
git send-email [options] <file | directory>...
-Options:
- --identity <str> * Use the sendemail.<id> options.
- --from <str> * Email From:
- --envelope-sender <str> * Email envelope sender.
- --to <str> * Email To:
- --cc <str> * Email Cc:
- --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
- --bcc <str> * Email Bcc:
- --subject <str> * Email "Subject:" (only if --compose).
- --compose * Open an editor for introduction.
- --in-reply-to <str> * First "In-Reply-To:" (only if --compose).
- --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
- --[no-]thread * Use In-Reply-To: field. Default on.
- --[no-]signed-off-by-cc * Actually send to Cc: and Signed-off-by:
- addresses. Default on.
- --suppress-cc <str> * author, self, sob, cccmd, all.
- --[no-]suppress-from * Don't send email to self. Default off.
- --smtp-server <str:int> * Outgoing SMTP server to use. The port
- is optional. Default 'localhost'.
- --smtp-server-port <int> * Outgoing SMTP server port.
- --smtp-user <str> * The username for SMTP-AUTH.
- --smtp-pass <str> * The password for SMTP-AUTH; not necessary.
- --smtp-encryption <str> * tls or ssl; anything else disables.
- --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
- --quiet * Output one line of info per email.
- --dry-run * Don't actually send the emails.
- --[no-]validate * Perform patch sanity checks. Default on.
+
+ Composing:
+ --from <str> * Email From:
+ --to <str> * Email To:
+ --cc <str> * Email Cc:
+ --bcc <str> * Email Bcc:
+ --subject <str> * Email "Subject:"
+ --in-reply-to <str> * Email "In-Reply-To:"
+ --compose * Open an editor for introduction.
+
+ Sending:
+ --envelope-sender <str> * Email envelope sender.
+ --smtp-server <str:int> * Outgoing SMTP server to use. The port
+ is optional. Default 'localhost'.
+ --smtp-server-port <int> * Outgoing SMTP server port.
+ --smtp-user <str> * Username for SMTP-AUTH.
+ --smtp-pass <str> * Password for SMTP-AUTH; not necessary.
+ --smtp-encryption <str> * tls or ssl; anything else disables.
+ --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
+
+ Automating:
+ --identity <str> * Use the sendemail.<id> options.
+ --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
+ --suppress-cc <str> * author, self, sob, cccmd, all.
+ --[no-]signed-off-by-cc * Send to Cc: and Signed-off-by:
+ addresses. Default on.
+ --[no-]suppress-from * Send to self. Default off.
+ --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
+ --[no-]thread * Use In-Reply-To: field. Default on.
+
+ Administering:
+ --quiet * Output one line of info per email.
+ --dry-run * Don't actually send the emails.
+ --[no-]validate * Perform patch sanity checks. Default on.
EOT
exit(1);
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* Re: [PATCH] usage.c: remove unused functions
From: Lars Hjemli @ 2008-09-29 6:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jonas Fonseca, Thomas Rast, Nanako Shiraishi,
Junio C Hamano, git
In-Reply-To: <20080925145134.GL3669@spearce.org>
On Thu, Sep 25, 2008 at 4:51 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> On Thu, Sep 25, 2008 at 01:48:37PM +0200, Thomas Rast wrote:
>> > Nanako Shiraishi wrote:
>> > > This removes three functions that are not used anywhere.
>> > [...]
>> > > -void set_usage_routine(void (*routine)(const char *err) NORETURN)
>> > > -void set_error_routine(void (*routine)(const char *err, va_list params))
>> > > -void set_warn_routine(void (*routine)(const char *warn, va_list params))
>> >
>> > These blame to the following commit:
>> >
>> > commit 39a3f5ea7c0352a530338d30d4e618f6b4db84e4
>> > Author: Petr Baudis <pasky@suse.cz>
>> >
>> > Customizable error handlers
> ...
>> > So apparently the intent was that they would only be used from outside
>> > Git. I don't know whether anyone still plans to do that, but they're
>> > certainly not "just" unused.
>>
>> I don't think it will be a big deal to remove these functions, though it
>> does feel like a little bit of a step backwards in the libgit efforts.
>> There are some programs that already link to Git, like CGit - I wonder
>> if some of them don't use them (CGit itself doesn't).
>
> IMHO these are useless for a "libgit". However both tig and
> cgit link to the non-existant libgit.a, so they may be using
> these routines. I've CC'd their authors and am not applying this
> particular change without an ACK from them.
Sorry for the late reply. And no, cgit doesn't use these functions and
I don't think that's going to change, so
Acked-by: Lars Hjemli <hjemli@gmail.com>
--
larsh
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-09-29 6:42 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20080928235013.5c749c6e.stephen@exigencecorp.com>
Stephen Haberman wrote:
> Hello,
>
> Per the emails from me last week, I'm working in an environment with
> shared topic branches and am trying to find a bullet-proof way for devs
> to rebase their local commits after the topic branch has moved.
>
> The easy approach would be to just let `git pull` create merge commits,
> and I would have been done with this long ago, but I'm striving to get
> rebasing to "just work" and avoid the ugliness of same-branch merge
> commits. Cross-branch merge commits are cool, but not same-branch.
>
> So, here's a crazy scenario we've ran into--a new release has hit
> stable, with two devs working on the same topic branch, and both of them
> merge. One wins, and the other has to rebase. Previously, this was
> replaying commits, but with great tips from the list last week, `rebase
> -i -p` is handling most scenarios.
>
> However, not this one:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> topic2 is a dev that has locally merged stable in g, moved on in h, is
> ready to push, but another dev already merged stable in E, and also
> committed F.
>
> If we do a `git pull --no-rebase`, the result is:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \| \
> # g -- h ------- i <-- topic2
>
> But i is a same-branch merge, and we'd rather rebase to something like:
>
> # A --C------ <-- origin/stable
> # \ \
> # B -- D -- E -- F <-- origin/topic2
> # \
> # h' <-- topic2
>
> (...maybe g' in there if g resolved stable conflicts differently
> E did them. I'm not sure, I haven't gotten there yet.)
>
> However, currently, `git rebase -i -p origin/topic2` results in:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> Nothing has changed. g & h haven't moved...I can keep executing this
> operation and the commits never make it on top of origin/topic2's F.
>
> Frustratingly, if I run non-interactive rebase, it works perfectly.
I can imagine. Since you don't want to preserve the merges in this
case, you shouldn't be using the -p flag.
In fact, for this particular scenario (assuming "h" is really the only
commit on topic2), you probably want to just cherry-pick that commit
into origin/topic2:
git checkout topic2
git reset --hard origin/topic2
git cherry-pick ORIG_HEAD
would work nicely for that. If topic2 and topic1 resolved merge
conflicts differently, cherry-picking topic2 will give conflicts again,
so they'll have to be resolved. rebase (without -p) will have the same
effect, ofcourse.
I don't think you can have a single command that does all the things
you want, because the possible differences in input makes it very nearly
impossible to always do "the right thing". For this case, you don't
want to preserve merges, so "git rebase" without -p does the right
thing. For that other case earlier this week, you wanted to preserve
merges, so "git rebase -p" does the right thing there. It's complex
to try to dwim things like that, and complexity will cause very weird
and surprising errors when it *does* fail.
Instead, I think you should give your developers some training in the
more advanced parts of git's integration tools and also look over
your workflow. Frequently merging 'master' into a topic is very rarely
the right thing to do. It's usually better to rebase the topic onto
master or cherry-pick relevant bugfixes from 'master' into the topic.
If two devs need to work on one topic, then that topic probably needs
breaking up into a sub-topic. However, sub-topics should never merge
'master' into them themselves; only 'topic'. Otherwise you'll get
more merges than work done.
> But
> I've got other cases (see earlier posts) that do need the interactive
> rebase. Personally, I could probably make do with trying each and
> seeing what happened, but I'm really trying to find a bullet proof
> command/alias/script for devs to run and have it "just work".
>
Or you could sit down and think about what you want to happen and then
run the appropriate command. ;-)
> I've attached a test that sets up the DAG as above and currently passes
> by asserting the not-desired/unchanged-DAG result. The assert for the
> desired result is commented out at the end.
>
Thanks for this. If all bug-reports had this, bugfixing would be a lot
easier. However, for this particular case, I'm not so sure it's a bug.
> Am I correct in asserting this is some sort of bug in the interactive
> rebase such that g & h are not ending up on top of F?
>
Assuming you're passing a correct input file to rebase -i; yes. At the
very least, "h" should be moved to the tip of origin/topic2.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Mike Ralphson @ 2008-09-29 7:51 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080926225423.GA25502@coredump.intra.peff.net>
2008/9/26 Jeff King <peff@peff.net>
>
> On Fri, Sep 26, 2008 at 02:24:31PM +0100, Mike Ralphson wrote:
>
> > Jeff, if you want to switch your BSD builds to Shawn's tree too, I
> > made and pushed a tiny change to the gitbuild.sh script to allow for
> > the spearce/{branch} format becoming spearce_{branch} in the tag
> > names.
>
> Thanks, that's a good idea. I'm building Shawn's master (on my todo is
> adding the other branches, too, but I need to tweak my script or tweak
> gitbuild.sh and switch to it).
Feel free to push changes to gitbuild.sh, including getting rid of
anything which looks environment-specific.
Mike
^ permalink raw reply
* Re: [PATCH 5/6] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Jakub Narebski @ 2008-09-29 8:33 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: git, Petr Baudis, Lea Wiemann,
Shawn O. Pearce (interim Git maintainer)
In-Reply-To: <1222030663-22540-6-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> This patch (combined with appropriate server configuration) allows usage
> of the gitweb CGI script as DirectoryIndex for the server root even when
> the pathinfo feature is enabled.
>
This is IMHO a bugfix for a path_info handling bug, for which there
was an ugly workaround of specifying base URL ($my_url and $my_uri)
explicitly in gitweb configuration (GITWEB_CONFIG).
Therefore I think that this patch should have been sent outside of
the rest of "new path_info features" series, as a separate single
patch, and now that it is there it really should be applied, perhaps
even to the 'maint' branch.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
(for what is worth)
> ---
> gitweb/gitweb.perl | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 0dd2526..4a91d07 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -26,6 +26,10 @@ our $cgi = new CGI;
> our $version = "++GIT_VERSION++";
> our $my_url = $cgi->url();
> our $my_uri = $cgi->url(-absolute => 1);
Perhaps some comment here?
> +if (my $path_info = $ENV{"PATH_INFO"}) {
> + $my_url =~ s,$path_info$,,;
> + $my_uri =~ s,$path_info$,,;
+ $my_url =~ s,\Q$path_info\E$,,;
+ $my_uri =~ s,\Q$path_info\E$,,;
Just in case.
> +}
>
> # core git executable to use
> # this can just be "git" if your webserver has a sensible PATH
I was wondering if $path_info should be global variable, but then
I checked that $path_info is local to evaluate_path_info() subroutine.
So it is good as it is now, but with quoting regular expression
metacharacters.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Clarify how the user can satisfy stash's 'dirty state' check.
From: Stephen Haberman @ 2008-09-29 9:12 UTC (permalink / raw)
To: git; +Cc: spearce
Clarify how the user can satisfy stash's 'dirty state' check.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
Feel free to tweak the wording, but we had a false assumption that you
could not apply multiple stashes in a row due to this confusing error
message. I.e. "dirty state" was taken as "dirty working tree and/or
index" instead of just "dirty working tree".
I don't have any tests, but t3903-stash.sh runs the same ("10: stash
branch" is failing both before and after my change change).
Looking into it more, I dislike that t3903's "3: apply needs clean
working directory" uses test_must_fail because without actively
asserting that the expected error message comes back, we can't be sure
the boundary condition that was originally tested for is still being met
(e.g. `git stash` could be returning non-zero for some entirely
different reason now--not likely, yes, but possible). test_must_fail
mentions a "segv" reason, which I'll somewhat blindly accept as good,
but it would be nice if I could pass in/grep against/something the error
message. Perhaps on another line/invocation?
Anyway...the patch:
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index e15c12a..a932ca7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -151,7 +151,7 @@ show_stash () {
apply_stash () {
git diff-files --quiet --ignore-submodules ||
- die 'Cannot restore on top of a dirty state'
+ die 'Cannot apply to a dirty working tree, please stage your changes'
unstash_index=
case "$1" in
--
1.6.0.2
^ permalink raw reply related
* git can't find none
From: Hinko Kocevar @ 2008-09-29 11:16 UTC (permalink / raw)
To: git
Hi,
I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
$ git blame Makefile
sh: none: command not found
'none' ?
$ git clone ...
Works fine.
This is on gentoo using gentoo provided ebuild for git (I even tied reemerging git package with no avail).
$ git --version
git version 1.5.6.4
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply
* Re: git can't find none
From: Johannes Sixt @ 2008-09-29 11:34 UTC (permalink / raw)
To: Hinko Kocevar; +Cc: git
In-Reply-To: <48E0B8FE.6060203@cetrtapot.si>
Hinko Kocevar schrieb:
> Hi,
>
> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
> $ git blame Makefile
> sh: none: command not found
>
> 'none' ?
Try
$ git --no-pager blame Makefile
and if that works, correct your setting of PAGER or GIT_PAGER, e.g.
$ export GIT_PAGER=cat
-- Hannes
^ permalink raw reply
* Re: git can't find none
From: Hinko Kocevar @ 2008-09-29 11:33 UTC (permalink / raw)
To: git
In-Reply-To: <48E0B8FE.6060203@cetrtapot.si>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Hinko Kocevar wrote:
> Hi,
>
> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
> $ git blame Makefile
> sh: none: command not found
>
> 'none' ?
>
> $ git clone ...
> Works fine.
>
>
> This is on gentoo using gentoo provided ebuild for git (I even tied reemerging git package with no avail).
> $ git --version
> git version 1.5.6.4
>
ou,
forgot to attach strace output if anyone can see what is going on.
Thank you,
Hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
[-- Attachment #2: log --]
[-- Type: text/plain, Size: 15770 bytes --]
execve("/usr/bin/git", ["git", "status"], [/* 42 vars */]) = 0
brk(0) = 0x814e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78249, ...}) = 0
mmap2(NULL, 78249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f1d000
close(3) = 0
open("/usr/lib/libcurl.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\221\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=244612, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f1c000
mmap2(NULL, 243932, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ee0000
mmap2(0xb7f1a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3a) = 0xb7f1a000
close(3) = 0
open("/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\25\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=71064, ...}) = 0
mmap2(NULL, 73976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ecd000
mmap2(0xb7ede000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10) = 0xb7ede000
close(3) = 0
open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\317\3\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1294876, ...}) = 0
mmap2(NULL, 1307384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d8d000
mmap2(0xb7eb4000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7eb4000
mmap2(0xb7ec9000, 13048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ec9000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1237276, ...}) = 0
mmap2(NULL, 1242576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c5d000
mmap2(0xb7d87000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb7d87000
mmap2(0xb7d8a000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7d8a000
close(3) = 0
open("/lib/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=30552, ...}) = 0
mmap2(NULL, 33356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c54000
mmap2(0xb7c5b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb7c5b000
close(3) = 0
open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\305\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=266084, ...}) = 0
mmap2(NULL, 265016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c13000
mmap2(0xb7c50000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3d) = 0xb7c50000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9612, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c12000
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c0e000
mmap2(0xb7c10000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7c10000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20H\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=118357, ...}) = 0
mmap2(NULL, 90592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7bf7000
mmap2(0xb7c0a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xb7c0a000
mmap2(0xb7c0c000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c0c000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7bf6000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7bf68d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7c0a000, 4096, PROT_READ) = 0
mprotect(0xb7c10000, 4096, PROT_READ) = 0
mprotect(0xb7c50000, 4096, PROT_READ) = 0
mprotect(0xb7c5b000, 4096, PROT_READ) = 0
mprotect(0xb7d87000, 8192, PROT_READ) = 0
mprotect(0xb7eb4000, 32768, PROT_READ) = 0
mprotect(0xb7ede000, 4096, PROT_READ) = 0
mprotect(0xb7f1a000, 4096, PROT_READ) = 0
mprotect(0x8106000, 4096, PROT_READ) = 0
mprotect(0xb7f4b000, 4096, PROT_READ) = 0
munmap(0xb7f1d000, 78249) = 0
set_tid_address(0xb7bf6918) = 30293
set_robust_list(0xb7bf6920, 0xc) = 0
rt_sigaction(SIGRTMIN, {0xb7bfb310, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7bfb390, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="alala", ...}) = 0
brk(0) = 0x814e000
brk(0x816f000) = 0x816f000
getcwd("/tmp/sdk", 4096) = 9
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(".git/objects", X_OK) = 0
access(".git/refs", X_OK) = 0
lstat64(".git/HEAD", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
open(".git/HEAD", O_RDONLY|O_LARGEFILE) = 3
read(3, "ref: refs/heads/master\n", 255) = 23
read(3, "", 232) = 0
close(3) = 0
access("/etc/gitconfig", R_OK) = -1 ENOENT (No such file or directory)
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/home/hinkok/.gitconfig", R_OK) = 0
open("/home/hinkok/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[user]\n\temail = hinkocevar@gmail"..., 4096) = 155
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=244, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 244
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
access("/etc/gitconfig", R_OK) = -1 ENOENT (No such file or directory)
access("/home/hinkok/.gitconfig", R_OK) = 0
open("/home/hinkok/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[user]\n\temail = hinkocevar@gmail"..., 4096) = 155
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=244, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f30000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 244
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f30000, 4096) = 0
pipe([3, 4]) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7bf6918) = 30294
dup2(3, 0) = 0
close(3) = 0
close(4) = 0
select(1, [0], NULL, [0], NULL) = 1 ()
--- SIGCHLD (Child exited) @ 0 (0) ---
execve("/usr/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/home/hinkok/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/work/tools/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/opt/bin/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/i486-pc-linux-gnu/gcc-bin/4.1.2/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/i686-pc-linux-gnu/gcc-bin/4.1.2/none", ["none"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/sh", ["sh"..., "-c"..., "none"...], [/* 42 vars */]) = 0
brk(0) = 0x80ed000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=78249, ...}) = 0
mmap2(NULL, 78249, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f14000
close(3) = 0
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\364\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=266136, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f13000
mmap2(NULL, 267076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ed1000
mmap2(0xb7f09000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x38) = 0xb7f09000
mmap2(0xb7f12000, 836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f12000
close(3) = 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9612, ...}) = 0
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ecd000
mmap2(0xb7ecf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7ecf000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1237276, ...}) = 0
mmap2(NULL, 1242576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d9d000
mmap2(0xb7ec7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb7ec7000
mmap2(0xb7eca000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eca000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d9c000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d9c6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7ec7000, 8192, PROT_READ) = 0
mprotect(0xb7ecf000, 4096, PROT_READ) = 0
mprotect(0xb7f09000, 32768, PROT_READ) = 0
mprotect(0x80e2000, 4096, PROT_READ) = 0
mprotect(0xb7f42000, 4096, PROT_READ) = 0
munmap(0xb7f14000, 78249) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
close(3) = 0
brk(0) = 0x80ed000
brk(0x810e000) = 0x810e000
getuid32() = 1000
getgid32() = 1000
geteuid32() = 1000
getegid32() = 1000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
time(NULL) = 1222687397
open("/proc/meminfo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f27000
read(3, "MemTotal: 4079432 kB\nMemFre"..., 1024) = 754
close(3) = 0
munmap(0xb7f27000, 4096) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_IGN}, 8) = 0
uname({sys="Linux", node="alala", ...}) = 0
stat64("/tmp/sdk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getpid() = 30293
getppid() = 30292
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/home/hinkok/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/work/tools/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/sh", 0xbfb429e8) = -1 ENOENT (No such file or directory)
stat64("/bin/sh", {st_mode=S_IFREG|0755, st_size=651148, ...}) = 0
open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3
read(3, "65536\n", 31) = 6
close(3) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d5b000
getgroups32(65536, [7, 10, 14, 18, 19, 27, 80, 85, 100, 411, 1000, 1003]) = 12
stat64("/bin/sh", {st_mode=S_IFREG|0755, st_size=651148, ...}) = 0
getpgrp() = 30292
rt_sigaction(SIGCHLD, {0x807b8d5, [], 0}, {SIG_DFL}, 8) = 0
getrlimit(RLIMIT_NPROC, {rlim_cur=38400, rlim_max=38400}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/home/hinkok/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/work/tools/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/opt/bin/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/i486-pc-linux-gnu/gcc-bin/4.1.2/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
stat64("/usr/i686-pc-linux-gnu/gcc-bin/4.1.2/none", 0xbfb428c8) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {0x807b8d5, [], 0}, 8) = 0
fstat64(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f27000
write(2, "sh: none: command not found\n", 28) = 28
exit_group(127) = ?
^ permalink raw reply
* Re: git can't find none
From: Hinko Kocevar @ 2008-09-29 12:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48E0BD38.6070602@viscovery.net>
Johannes Sixt wrote:
> Hinko Kocevar schrieb:
>> Hi,
>>
>> I've recently discovered that some git command stopped working. I'm not sure if this is related to my git tree or not, it happens on other trees too:
>> $ git blame Makefile
>> sh: none: command not found
>>
>> 'none' ?
>
> Try
>
> $ git --no-pager blame Makefile
It works! yes.
>
> and if that works, correct your setting of PAGER or GIT_PAGER, e.g.
>
> $ export GIT_PAGER=cat
I don't want any pager. I've set the config property to 'none' instead to "":
$ git-config core.pager ""
Thank you,
Hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply
* Re: [PATCH] Add contrib/rerere-train script
From: Johannes Schindelin @ 2008-09-29 12:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080927204415.6117@nanako3.lavabit.com>
Hi,
On Sat, 27 Sep 2008, Nanako Shiraishi wrote:
> This script takes a range of commits (e.g. maint..next) as its
> arguments, recreates merge commits in the range to prime rr-cache
> database.
Cute idea. However, I would _love_ to have this as an option to
git-rerere, which would work in memory only.
This is how I would do it (if I had enough time to play with Git):
- teach merge_recursive_options not to write anything to the working
directory (should be relatively easy, as many parts of merge-recursive.c
already have no_wd/update_wd/!o->call_depth checks for that),
- refactor handle_file() in rerere.c to provide an in-memory-only version,
- teach rerere to call merge_recursive() with the in-memory-only option,
and then call the in-memory version of the handle_file() function for
all unmerged paths, using the resolutions from the given merge commit.
- then teach this new function to take an arbitrary commit range (but only
handling the two-parent merges within it).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/6] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-09-29 13:05 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Petr Baudis, Lea Wiemann,
Shawn O. Pearce (interim Git maintainer)
In-Reply-To: <200809291033.34588.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 10:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> This patch (combined with appropriate server configuration) allows usage
>> of the gitweb CGI script as DirectoryIndex for the server root even when
>> the pathinfo feature is enabled.
>>
>
> This is IMHO a bugfix for a path_info handling bug, for which there
> was an ugly workaround of specifying base URL ($my_url and $my_uri)
> explicitly in gitweb configuration (GITWEB_CONFIG).
>
> Therefore I think that this patch should have been sent outside of
> the rest of "new path_info features" series, as a separate single
> patch, and now that it is there it really should be applied, perhaps
> even to the 'maint' branch.
Ok, I'll resend it separately, with the suggested fix.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-09-29 13:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
This patch fixes PATH_INFO handling by removing the relevant part from
$my_url and $my_uri, thus making it unnecessary to specify them by hand
in the gitweb configuration.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index da474d0..ffe3dbf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -27,6 +27,13 @@ our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
+# if we're called with PATH_INFO, we have to strip that
+# from the URL to find our real URL
+if (my $path_info = $ENV{"PATH_INFO"}) {
+ $my_url =~ s,\Q$path_info\E$,,;
+ $my_uri =~ s,\Q$path_info\E$,,;
+}
+
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
our $GIT = "++GIT_BINDIR++/git";
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Jakub Narebski @ 2008-09-29 13:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <1222693662-27426-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> This patch fixes PATH_INFO handling by removing the relevant part from
> $my_url and $my_uri, thus making it unnecessary to specify them by hand
> in the gitweb configuration.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-09-29 14:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <200809290308.09312.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 3:08 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> When using path info, make filenames start with a / (right after the :
>> that separates them from the hash base). This minimal change allows
>> relative navigation to work properly when viewing HTML files.
>
> Good idea. Nitpick: instead of "using path info", perhaps "generating
> path info URL"; this change is about gitweb link generation...
Right.
> Did you check if gitweb strips leading '/' from filename?
Yes.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index e783d12..18da484 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -664,7 +664,7 @@ sub href (%) {
>> if (defined $params{'hash_base'}) {
>> $href .= "/".esc_url($params{'hash_base'});
>> if (defined $params{'file_name'}) {
>> - $href .= ":".esc_url($params{'file_name'});
>> + $href .= ":/".esc_url($params{'file_name'});
>> delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>> delete $params{'file_name'};
>> } else {
>> --
>> 1.5.6.5
>
> Is there reason why this change is separate (not squashed) from
> previous commit?
Historical reason (i.e. I came up with the idea later on). I'll squash it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] git-svn: call 'fatal' correctly in set-tree
From: Luc Heinrich @ 2008-09-29 13:58 UTC (permalink / raw)
To: git; +Cc: gitster, Luc Heinrich
When doing a set-tree and there is no revision to commit to, the following unrelated error message is displayed: "Undefined subroutine &Git::SVN::fatal called at /opt/local/libexec/git-core/git-svn line 2575." The following patch fixes the problem and allows the real error message to be shown.
Signed-off-by: Luc Heinrich <luc@honk-honk.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 80a5728..7609a83 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2591,7 +2591,7 @@ sub set_tree {
my ($self, $tree) = (shift, shift);
my $log_entry = ::get_commit_entry($tree);
unless ($self->{last_rev}) {
- fatal("Must have an existing revision to commit");
+ ::fatal("Must have an existing revision to commit");
}
my %ed_opts = ( r => $self->{last_rev},
log => $log_entry->{log},
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-09-29 14:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <200809290303.21290.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 3:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> I'm sorry for the delay reviewing those patches.
>
> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>
>> When using path info, reduce the number of CGI parameters by embedding
>> the action in the path. The typicial cgiweb path is thus
>> $project/$action/$hash_base:$file_name or $project/$action/$hash
>
> cgiweb?
Good question. I have no idea why I wrote that instad of gitweb.
>> This is mostly backwards compatible with the old-style gitweb paths,
>> except when $project/$branch was used to access a branch whose name
>> matches a gitweb action.
>
> I would also state that gitweb _generates_ such pathinfo links if
> configured (or if coming from pahinfo URL), and that this change
> allow to represent wider number of gitweb links (gitweb URLs) in
> pathinfo form.
Can do.
> Also, from what I understand, generated pathinfo links now always
> use action, so they are a tiny little bit longer.
Is that a problem, by the way? I've had half-thoughts about making the
action implicit when possible, but I'm afraid that's prone to make the
code way more complex and the path info handling much less robust.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
>> 1 files changed, 72 insertions(+), 37 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index da474d0..e783d12 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -488,6 +488,37 @@ if (defined $searchtext) {
>> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
>> }
>>
>> +# dispatch
>> +my %actions = (
>> + "blame" => \&git_blame,
>> + "blobdiff" => \&git_blobdiff,
>> + "blobdiff_plain" => \&git_blobdiff_plain,
>> + "blob" => \&git_blob,
>> + "blob_plain" => \&git_blob_plain,
>> + "commitdiff" => \&git_commitdiff,
>> + "commitdiff_plain" => \&git_commitdiff_plain,
>> + "commit" => \&git_commit,
>> + "forks" => \&git_forks,
>> + "heads" => \&git_heads,
>> + "history" => \&git_history,
>> + "log" => \&git_log,
>> + "rss" => \&git_rss,
>> + "atom" => \&git_atom,
>> + "search" => \&git_search,
>> + "search_help" => \&git_search_help,
>> + "shortlog" => \&git_shortlog,
>> + "summary" => \&git_summary,
>> + "tag" => \&git_tag,
>> + "tags" => \&git_tags,
>> + "tree" => \&git_tree,
>> + "snapshot" => \&git_snapshot,
>> + "object" => \&git_object,
>> + # those below don't need $project
>> + "opml" => \&git_opml,
>> + "project_list" => \&git_project_list,
>> + "project_index" => \&git_project_index,
>> +);
>> +
>
> This is as I understand simply moving %actions hash around?
Yes.
> Well, you could instead split hash declaration from defining it,
> in the form of
>
> my %actions = ();
> ...
> %actions = (
> ...
> );
>
> but I guess moving declaration earlier is good solution.
Is there some coding style recommendation wrt this situations, or is
it just a matter of making the patch smaller?
>> # now read PATH_INFO and use it as alternative to parameters
>> sub evaluate_path_info {
>> return if defined $project;
>> @@ -512,6 +543,16 @@ sub evaluate_path_info {
>> # do not change any parameters if an action is given using the query string
>> return if $action;
>> $path_info =~ s,^\Q$project\E/*,,;
>> +
>> + # next comes the action
>> + $action = $path_info;
>> + $action =~ s,/.*$,,;
>
> I would use perhaps "$action = ($path_info =~ m!^([^/]+)/!;"
> But that is Perl, so TIMTOWDI.
Well, Perl is not my native language so I tend to stay away from
complex expressions if possible ;-)
>> + if (exists $actions{$action}) {
>> + $path_info =~ s,^\Q$action\E/*,,;
>> + } else {
>> + $action = undef;
>> + }
>> +
>
> I don't think you need quoting pattern metacharacters; valid actions
> should not contain regexp metacharacters. Defensive programming?
You're right, in this case it's probably excessive. I'll strip it out.
>> my ($refname, $pathname) = split(/:/, $path_info, 2);
>> if (defined $pathname) {
>> # we got "project.git/branch:filename" or "project.git/branch:dir/"
>> @@ -525,10 +566,12 @@ sub evaluate_path_info {
>> }
>> $hash_base ||= validate_refname($refname);
>> $file_name ||= validate_pathname($pathname);
>> + $hash ||= git_get_hash_by_path($hash_base, $file_name);
>
> I don't understand why you feel that you need to do this (this is
> additional git command fork, as git_get_hash_by_path calls Git, to
> be more exact it calls git-ls-tree (it could call git-rev-parse
> instead). Moreover, I don't understand why you need to do this _here_,
> instead of just before where you would have to have $hash variable set.
Hm. I must confess that I honestly don't remember. The same holds for
the other chunks you have perplexities on. When I started writing
these patches I came across a few situations where $hash wouldn't
carry over properly, but now I can't seem to recreate those issues
anymore, which leads me to suspect it was a problem with hand-crafted
links (i.e. before I coded the link generation part too). I'll resend
without these chunks.
> > @@ -624,8 +636,13 @@ sub href (%) {
> > if ($params{-replay}) {
> > while (my ($name, $symbol) = each %mapping) {
> > if (!exists $params{$name}) {
> > - # to allow for multivalued params we use arrayref form
> > - $params{$name} = [ $cgi->param($symbol) ];
> > + if ($cgi->param($symbol)) {
> > + # to allow for multivalued params we use arrayref form
> > + $params{$name} = [ $cgi->param($symbol) ];
> > + } else {
> > + no strict 'refs';
> > + $params{$name} = $$name if $$name;
> > + }
> > }
> > }
> > }
>
> What this change is about? And why this change is _here_, in this
> commit? It is I think unrelated, and wrong change.
This is about being able to recycle CGI parameters that came through
as part of path_info instead of the CGI parameter list. It might not
be the best way to recover it, though. I *did* have a few thoughts
about an alternative way that consisted of build a parameter list
merging CGI and path-info parameter, but since this approach seemed to
work, I went with it.
> href(..., -replay=>1) is all about reusing current URL, perhaps with
> a few parameters changed, like for example pagination links differ only
> in page number param change. For example if we had only hb= and f=
> parameters, -replay=>1 links should use only those, and not add h=
> parameter because somewhere we felt that we need $hash to be calculated.
Assume for example that you are to an url such as
http://git.oblomov.eu/git/tree/refs/remotes/origin/master:gitweb
Without this patch, the 'history' link on the second header line links
to ARRAY(0xblah)ARRAY(0xblah). With this patch, it shows the proper
link. So either replay is being abused somewhere in the link
generation code, or this CGI+path_info parameter retrieval is
necessary, one way or the other.
>> @@ -636,10 +653,28 @@ sub href (%) {
>
> This hunk is about generating pathinfo URL, isn't it?
Yes.
> You probably would want to change comment at the top of this part
> of href() subroutine, namely
>
> if ($use_pathinfo) {
> # use PATH_INFO for project name
>
> as you now try to use PATH_INFO for more than project name. Please do
> not leave comments to get out of sync with the code.
Right.
>> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
>> delete $params{'project'};
>>
>> - # Summary just uses the project path URL
>> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
>> + # Summary just uses the project path URL, any other action come next
>> + # in the URL
>> + if (defined $params{'action'}) {
>> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
>> delete $params{'action'};
>> }
>> +
>> + # next, we put either hash_base:file_name or hash
>> + if (defined $params{'hash_base'}) {
>> + $href .= "/".esc_url($params{'hash_base'});
>> + if (defined $params{'file_name'}) {
>> + $href .= ":".esc_url($params{'file_name'});
>> + delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>
> First, this page has around 140 characters. That is too long, much too long.
> Please try to wrap code around 80-characters.
>
> Second, following Petr 'Pasky' Baudis suggestion of reducing complexity
> and shortening gitweb URLs, we could unconditionally remove redundant
> 'hash' parameter if we have both 'hash_base' and 'file_name'
> parameters. This would also simplify and speed up (lack of extra fork)
> gitweb code.
If it's indeed guaranteed that hash is not needed in these cases, it's
surely the best course of action. I changed the code to that effect.
>> + delete $params{'file_name'};
>> + } else {
>> + delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
>> + }
>> + delete $params{'hash_base'};
>> + } elsif (defined $params{'hash'}) {
>> + $href .= "/".esc_url($params{'hash'});
>> + delete $params{'hash'};
>> + }
>
> O.K.... I think.
>
> Did you test this, preferably also using Mechanize test, with gitweb
> configuration turning path_info on by default.?
The whole patchset is running both on my machine on
http://git.oblomov.eu and on the rbot repository
http://ruby-rbot.org/gitweb (older version there, though). I have no
idea how to run automated Mechanize tests though.
>> }
>>
>> # now encode the parameters explicitly
>
> Hmmm... now I am not so sure if it wouldn't be better to split this
> patch in pathinfo parsing and pathinfo generation. The first part
> would be obvious, the second part would be smaller and easier to review.
Ok, I'll split parsing from generation. Since it's what I did for
subsequent extensions (such as the parent..current thing) it also fits
nicely with the patchflow.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC/PATCH] remove vim syntax highlighting in favor of upstream
From: Shawn O. Pearce @ 2008-09-29 14:55 UTC (permalink / raw)
To: SZEDER GGGbor; +Cc: Jeff King, vim, git
In-Reply-To: <20080924195658.GB6816@neumann>
SZEDER GGGbor <szeder@ira.uka.de> wrote:
> remove vim syntax highlighting in favor of upstream
>
> As of version 7.2, vim ships with its own syntax
> highlighting for git commit messages, which is:
>
> 1. more comprehensive in splitting up the various
> components of the file
>
> 2. in accordance with the usual vim behavior for syntax
> highlighting (e.g., respecting b:current_syntax)
>
> 3. presumably better maintained (I have not been using
> what's in git's contrib/ directory for some time in
> favor of the upstream version)
>
> Furthermore, vim 7.2 also provides syntax highlighting for
> other git filetypes (gitconfig, rebase, send-email).
>
> This patch gets rid of our local version and just points
> interested parties to the upstream version.
>
> The code for auto-detecting filetypes is taken from vim 7.2's
> runtime/filetype.vim.
>
> ---
> contrib/vim/README | 38 ++++++++++++++++++++++++++++++--------
> contrib/vim/syntax/gitcommit.vim | 18 ------------------
> 2 files changed, 30 insertions(+), 26 deletions(-)
> delete mode 100644 contrib/vim/syntax/gitcommit.vim
Missing SBO line?
--
Shawn.
^ permalink raw reply
* [PATCH] Fix typo in release notes for 1.6.0.3
From: Miklos Vajna @ 2008-09-29 14:58 UTC (permalink / raw)
To: spearce; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/RelNotes-1.6.0.3.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt
index 46e13a4..a374690 100644
--- a/Documentation/RelNotes-1.6.0.3.txt
+++ b/Documentation/RelNotes-1.6.0.3.txt
@@ -16,7 +16,7 @@ Fixes since v1.6.0.2
* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
with the output redirected to /dev/null.
-* "git stash apply sash@{1}" was fixed to error out. Prior versions
+* "git stash apply stash@{1}" was fixed to error out. Prior versions
would have applied stash@{0} incorrectly.
* "git for-each-ref --format=%(subject)" fixed for commits with no
--
1.6.0
^ permalink raw reply related
* Re: having to pull twice
From: Miklos Vajna @ 2008-09-29 15:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <200809281726.23062.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Sun, Sep 28, 2008 at 05:26:20PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> IIUC, this is not the same as "racy git". The racy case is if you
> manage to get a file changed immediately after its index entry was
> updated, so that it will look unchanged. In this case, it's simply
> the same file with a new mtime, which means it looks changed
> superficially but still has the same contents.
Right. I called it "racy" because it had something to do with
timestamps. I guess we have no proper term for this kind of problem yet.
;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] doc: enhance git describe --tags help
From: Shawn O. Pearce @ 2008-09-29 15:01 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Erez Zilber, git@vger.kernel.org, open-iscsi, Junio C Hamano
In-Reply-To: <20080928151259.GJ5302@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c4dbc2a..9cc8c2f 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -30,7 +30,8 @@ OPTIONS
>
> --tags::
> Instead of using only the annotated tags, use any tag
> - found in `.git/refs/tags`.
> + found in `.git/refs/tags`. Though if an annotated tag is found in the
> + ancestry, it will always be preferred to lightweight tags.
As technically correct as the statement is, I read this and go
"why do we even have --tags?".
If I read builtin-describe.c right we only honor --tags on an exact
match, or if there are no annotated tags at all in the history.
I wonder if docs like this aren't better for --tags:
--tags::
If a lightweight tag exactly matches, output it. If no
annotated tag is found in the ancestry but a lightweight
tag is found, output the lightweight tag.
?
--
Shawn.
^ 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