* Re: t9001 fails because Net::SMTP is missing
From: Junio C Hamano @ 2006-05-31 0:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605302125310.11586@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> is it unexpected that there are setups which come without Net::SMTP?
>
> -- snip --
> * expecting success: git format-patch -n HEAD^1
> git send-email -from="Example <nobody@example.com>"
> --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt
> 0001-Second.txt
> Can't locate Net/SMTP.pm in @INC (@INC contains:
Hmm. Something like this?
-- >8 --
diff --git a/git-send-email.perl b/git-send-email.perl
index 0e368ff..f7af8eb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -21,7 +21,6 @@ use warnings;
use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
-use Net::SMTP;
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
@@ -394,6 +393,7 @@ X-Mailer: git-send-email $gitversion
print $sm "$header\n$message";
close $sm or die $?;
} else {
+ use Net::SMTP;
$smtp ||= Net::SMTP->new( $smtp_server );
$smtp->mail( $from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
^ permalink raw reply related
* Re: t9001 fails because Net::SMTP is missing
From: Junio C Hamano @ 2006-05-31 0:37 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <7v8xojyqu3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> is it unexpected that there are setups which come without Net::SMTP?
>>
>> -- snip --
>> * expecting success: git format-patch -n HEAD^1
>> git send-email -from="Example <nobody@example.com>"
>> --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt
>> 0001-Second.txt
>> Can't locate Net/SMTP.pm in @INC (@INC contains:
>
> Hmm. Something like this?
Nah, nevermind. I forgot my Perl that use has the magic BEGIN{}
block around it X-<.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-31 1:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605301604130.24646@g5.osdl.org>
On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 31 May 2006, Martin Langhoff wrote:
> >
> > gitview
> > http://git.catalyst.net.nz/gitweb?p=gentoo.git;a=summary
>
> Heh. I think you should enable caching in your apache config.
I know I should -- but I'm hoping to find the time to rework gitweb a
bit to actually work fast instead. It bothers me that it is so slow on
a basically idle machine, and where I can perform the corresponding
git operations in the commandline in a blink.
And caching is great for really busy sites (aka kernel.org) but
git.catalyst.net.nz only serves a handful of small repos for a small
group of people, and is 99% idle. Should blaze through this stuff.
> That gentoo repo has a lot of "duplicate" commits that cvsps will mark as
> two separate commits because there's one commit for the files, and one
> commit for whatever the "Manifest" file is. I wonder if those commits
> should generally be merged or something.
>
> That said, things like that are most easily fixed as a git->git update
> (along with adding name translation), which can avoid re-writing the
> trees.
Yep, large projects often have good reasons to run custom imports,
merging certain commits, rewriting log messages (like the X.org guys
were doing). It can be done at the cvsimport stage or later -- I think
Pasky has a rewritehistory tool hidden somewhere in Cogito, but I
haven't used it.
cheers,
martin
^ permalink raw reply
* Re: t9001 fails because Net::SMTP is missing
From: Morten Welinder @ 2006-05-31 2:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v4pz7yqpd.fsf@assigned-by-dhcp.cox.net>
You just need more perl magic... Try this.
#!/usr/local/perl -w
eval 'use strict';
print "Hmm [$@]\n";
eval 'use Oink';
print "Hmm [$@]\n";
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-05-31 2:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd373o15.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > OK. Ignore both patches then. Two negative votes in such a short
> > time suggests they are probably not generally accepted. ;-)
> >
> >> We probably should allow "commit -F -" to read from the standard
> >> input if we already don't, but that is about as far as I am
> >> willing to go at this moment.
> >
> > We do. So apparently the solution to my usage issue is:
> >
> > $ fmt -w 60 | git commit -F-
> > This is my message.
> >
> > This is the body. Etc....
> > EOF
> >
> > I'm thinking that's too much work for me.
>
> If we supported multiple -m (presumably each becomes a single line?)
> with internal fmt, I do not see how it would become less work.
>
> $ git commit -w60 -m "This is my message." \
> -m '' \
> -m 'This is the body. Etc....'
>
> looks more typing to me, even without the second line to force
> the empty line between the summary and the body.
Actually I was thinking each -m would be its own paragraph so blank
lines would split each -m and maybe the -w60 should be a config
option in .git/config or .gitrc so it doesn't always need to be
supplied on the command line.
Personally I want blank lines between each -m and to always run
the message through fmt. Others may want to run their commit
messages through other filters so maybe the filter itself is just
a config value which gets executed:
[user]
commitMessageFilter = fmt -w 60
or someone else might set:
[user]
commitMessageFilter = /home/user/bin/my-filter
where the filter accepts the message on STDIN and writes (the maybe
changed) message on STDOUT.
--
Shawn.
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-31 2:49 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin, Alec Warner
In-Reply-To: <46a038f90605301804u3beabf4ct97c8a0ea6ef7b995@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Martin Langhoff wrote:
> On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> That gentoo repo has a lot of "duplicate" commits that cvsps will mark as
>> two separate commits because there's one commit for the files, and one
>> commit for whatever the "Manifest" file is. I wonder if those commits
>> should generally be merged or something.
>>
>> That said, things like that are most easily fixed as a git->git update
>> (along with adding name translation), which can avoid re-writing the
>> trees.
>
> Yep, large projects often have good reasons to run custom imports,
> merging certain commits, rewriting log messages (like the X.org guys
> were doing). It can be done at the cvsimport stage or later -- I think
> Pasky has a rewritehistory tool hidden somewhere in Cogito, but I
> haven't used it.
We've got a guy who got a Summer of Code project to work on CVS
migration, so this could be something along his lines.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Junio C Hamano @ 2006-05-31 4:49 UTC (permalink / raw)
To: Zakirov, Salikh; +Cc: git
In-Reply-To: <E124AAE027DA384D8B919F93E4D8C70801EFFB52@mssmsx402nb>
"Zakirov, Salikh" <salikh.zakirov@intel.com> writes:
> However, I believe that the command sequence git-format-patch, git-am
> without any e-mail transfer in between and in the same repository
> should work perfectly regardless of the contents of the files,
> no matter if they are binary, text, or "CRLF text" or even
> "broken LF and CRLF text". This is a requirement from a nasty "real
> world".
OK, that's a very valid argument. Thanks for straighten me out.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Junio C Hamano @ 2006-05-31 5:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060531021808.GC21222@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> If we supported multiple -m (presumably each becomes a single line?)
>> with internal fmt, I do not see how it would become less work.
>>
>> $ git commit -w60 -m "This is my message." \
>> -m '' \
>> -m 'This is the body. Etc....'
>>
>> looks more typing to me, even without the second line to force
>> the empty line between the summary and the body.
>
> Actually I was thinking each -m would be its own paragraph so blank
> lines would split each -m and maybe the -w60 should be a config
> option in .git/config or .gitrc so it doesn't always need to be
> supplied on the command line.
Now that makes the distinction between the current:
$ git commit -m 'This is my message.
This is the body. Etc....'
vs. the proposed multi-em:
$ git commit -m 'This is my message.' \
-m 'This is the body. Etc....'
Presumably Etc.... will be an multiline argument to -m. The
distinction is even more blurry to me than before.
Emacs users would just do "ESC q" and vi users would know how to
filter the file contents through fmt, so this seems to come from
aversion against invoking your $EDITOR. I just do not see why.
Having said that, I do realize that the current behaviour of
accepting multiple -m without complaining and discarding all but
the last one silently is far worse than what is being proposed,
and I do not see downside to the multiple -m patch, so let's
apply that. You can have your "fmt -w60" provided if it is made
into an option.
^ permalink raw reply
* Re: t9001 fails because Net::SMTP is missing
From: Eric Wong @ 2006-05-31 6:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v4pz7yqpd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> is it unexpected that there are setups which come without Net::SMTP?
> >>
> >> -- snip --
> >> * expecting success: git format-patch -n HEAD^1
> >> git send-email -from="Example <nobody@example.com>"
> >> --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt
> >> 0001-Second.txt
> >> Can't locate Net/SMTP.pm in @INC (@INC contains:
> >
> > Hmm. Something like this?
>
> Nah, nevermind. I forgot my Perl that use has the magic BEGIN{}
> block around it X-<.
s/use/require/ and you should be fine. We don't need any thing imported
from Net::SMTP, either.
Odd that Net::SMTP isn't installed on Johannes' machine, though, as it's
part of the standard Perl 5.8 (maybe even before) installation.
--
Eric Wong
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-31 6:05 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin, Alec Warner
In-Reply-To: <447D043D.1020609@gentoo.org>
On 5/31/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> We've got a guy who got a Summer of Code project to work on CVS
> migration, so this could be something along his lines.
He'll want a fast box to wrangle with this repo ;-)
martin
^ permalink raw reply
* Re: t9001 fails because Net::SMTP is missing
From: Johannes Schindelin @ 2006-05-31 8:32 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060531060530.GA9333@hand.yhbt.net>
Hi,
On Tue, 30 May 2006, Eric Wong wrote:
> Odd that Net::SMTP isn't installed on Johannes' machine, though, as it's
> part of the standard Perl 5.8 (maybe even before) installation.
In terms of corporate setups, 5.8 really is pretty new, you know?
As for "s/use/require/", I can not access on that machine today, but I
will test it.
Ciao,
Dscho
^ permalink raw reply
* format-patch signoff argument no longer works
From: Geoff Russell @ 2006-05-31 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0605310332p19241861g466e1516a2aaf0df@mail.gmail.com>
Hi,
The --signoff argument no longer works in git-format-patch. Was this
intentional?
It still appears in the documentation for the command.
It appears to have got lost when the shell script got converted to C.
Cheers,
Geoff Russell
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Matthias Kestenholz @ 2006-05-31 11:28 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0605310411r712dab8au9b1c7d8ecb595a66@mail.gmail.com>
* Geoff Russell (geoffrey.russell@gmail.com) wrote:
> The --signoff argument no longer works in git-format-patch. Was this
> intentional?
> It still appears in the documentation for the command.
>
> It appears to have got lost when the shell script got converted to C.
>
Yes, this was intentional. You should sign off your changes while
committing (git commit -s|--signoff)
Thanks,
Matthias
^ permalink raw reply
* Re: irc usage..
From: Alec Warner @ 2006-05-31 13:54 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <46a038f90605302305g7a969a62r277af1724b912069@mail.gmail.com>
Martin Langhoff wrote:
> On 5/31/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
>> We've got a guy who got a Summer of Code project to work on CVS
>> migration, so this could be something along his lines.
>
> He'll want a fast box to wrangle with this repo ;-)
>
>
> martin
I have a dual opteron with 4gb of ram "on loan" from work :)
It still dies though, using git cvsimport or parsecvs.
I talked to Keith Packard about adding support to parsecvs for recording
the actual changed changesets, but I haven't yet started on implementing
that since he isn't using cvsps in parsecvs.
I also haven't had a chance to look at the git-cvsimport sources yet,
was hoping to get to that later this week.
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Seth Falcon @ 2006-05-31 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <20060531112803.GB3877@spinlock.ch>
Matthias Kestenholz <lists@spinlock.ch> writes:
> * Geoff Russell (geoffrey.russell@gmail.com) wrote:
>> It appears to have got lost when the shell script got converted to C.
>>
> Yes, this was intentional. You should sign off your changes while
> committing (git commit -s|--signoff)
When should one commit _without_ signoff?
The obvious answer is: when one doesn't approve of the changes in the
commit... But in my usual workflow, commit means
works-for-me-I-think-it-is-good. :-)
Also, here's a trivial patch to the git-format-patch doc. I recently
had the same confusion trying to get git-format-patch to add signoff
for me...
Remove reference to signoff option (-s) in git-format-patch
Signed-off-by: Seth Falcon <sethfalcon@gmail.com>
---
Documentation/git-format-patch.txt | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7cc7faf..d13f463 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-c]
[--diff-options] <his> [<mine>]
DESCRIPTION
@@ -44,10 +44,6 @@ OPTIONS
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--s|--signoff::
- Add `Signed-off-by:` line to the commit message, using
- the committer identity of yourself.
-
-c|--check::
Display suspicious lines in the patch. The definition
of 'suspicious lines' is currently the lines that has
--
1.3.3.gb931
^ permalink raw reply related
* Re: format-patch signoff argument no longer works
From: Johannes Schindelin @ 2006-05-31 14:09 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2mzcycn4f.fsf@ziti.fhcrc.org>
Hi,
On Wed, 31 May 2006, Seth Falcon wrote:
> Matthias Kestenholz <lists@spinlock.ch> writes:
>
> > * Geoff Russell (geoffrey.russell@gmail.com) wrote:
> >> It appears to have got lost when the shell script got converted to C.
> >>
> > Yes, this was intentional. You should sign off your changes while
> > committing (git commit -s|--signoff)
>
> When should one commit _without_ signoff?
>
> The obvious answer is: when one doesn't approve of the changes in the
> commit... But in my usual workflow, commit means
> works-for-me-I-think-it-is-good. :-)
Well, there are often times when I commit something to a throw-away
branch, where I do not want to sign it off.
That was my original incentive to add this option BTW: I usually clean up
a patch series in a cycle of tests and fixes, and only want to sign off on
the final version.
If people need this option, I'll implement it, so speak up!
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Update documentation for git-format-patch
From: Dennis Stosberg @ 2006-05-31 14:14 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: geoff, git
In-Reply-To: <20060531112803.GB3877@spinlock.ch>
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
This updates the documentation for git-format-patch to reflect the
changes that the built-in version brought.
In addition to the functional changes, I reworded a few expressions
which sounded suspicious or unclear to me. However, I'm not a
native English speaker, so corrections are welcome.
Is there any "patch" program at all that understands git's rename
patches?
Regards,
Dennis
Documentation/git-format-patch.txt | 82 +++++++++++++++---------------------
1 files changed, 35 insertions(+), 47 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7cc7faf..64d3f1e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,70 +9,58 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
- [--diff-options] <his> [<mine>]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach]
+ [--diff-options] [--start-number <n>]
+ <since>[..<until>]
DESCRIPTION
-----------
-Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch formatted to resemble UNIX mailbox
-format, for e-mail submission or use with gitlink:git-am[1].
+
+Prepare each commit between <since> and <until> with its patch in
+one file per commit, formatted to resemble UNIX mailbox format.
+If ..<until> is not specified, the head of the current working
+tree is implied.
+
+The output of this command is convenient for e-mail submission or
+for use with gitlink:git-am[1].
Each output file is numbered sequentially from 1, and uses the
-first line of the commit message (massaged for pathname safety)
-as the filename.
+first line of the commit message (checked for pathname safety) as
+the filename. The names of the output files are printed to standard
+output, unless the --stdout option is specified.
-When -o is specified, output files are created in <dir>; otherwise
-they are created in the current working directory. This option
-is ignored if --stdout is specified.
+If -o is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory.
-When -n is specified, instead of "[PATCH] Subject", the first
-line is formatted as "[PATCH N/M] Subject", unless you have only
-one patch.
+If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
OPTIONS
-------
-o|--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
- current working directory.
+ current working directory. This option is ignored if
+ --stdout is specified.
-n|--numbered::
Name output in '[PATCH n/m]' format.
+--start-number <n>::
+ Start numbering the patches with <n> instead of 1.
+
-k|--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--s|--signoff::
- Add `Signed-off-by:` line to the commit message, using
- the committer identity of yourself.
-
--c|--check::
- Display suspicious lines in the patch. The definition
- of 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character.
-
--stdout::
- This flag generates the mbox formatted output to the
- standard output, instead of saving them into a file per
- patch and implies --mbox.
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
--attach::
Create attachments instead of inlining patches.
-CONFIGURATION
--------------
-You can specify extra mail header lines to be added to each
-message in the repository configuration as follows:
-
-[format]
- headers = "Organization: git-foo\n"
-
-
EXAMPLES
--------
@@ -82,18 +70,18 @@ git-format-patch -k --stdout R1..R2 | gi
cherry-pick them.
git-format-patch origin::
- Extract commits the current branch accumulated since it
- pulled from origin the last time in a patch form for
- e-mail submission.
+ Extract all commits which are in the current branch but
+ not in the origin branch. For each commit a separate file
+ is created in the current directory.
git-format-patch -M -B origin::
- The same as the previous one, except detect and handle
- renames and complete rewrites intelligently to produce
- renaming patch. A renaming patch reduces the amount of
- text output, and generally makes it easier to review
- it. Note that the "patch" program does not understand
- renaming patch well, so use it only when you know the
- recipient uses git to apply your patch.
+ The same as the previous one. Additionally, it detects
+ and handles renames and complete rewrites intelligently to
+ produce a renaming patch. A renaming patch reduces the
+ amount of text output, and generally makes it easier to
+ review it. Note that the "patch" program does not
+ understand renaming patches, so use it only when you know
+ the recipient uses git to apply your patch.
See Also
--
1.3.3+git20060531-dest1
^ permalink raw reply related
* Re: [PATCH] Update documentation for git-format-patch
From: Johannes Schindelin @ 2006-05-31 15:00 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Matthias Kestenholz, geoff, git
In-Reply-To: <20060531141408.G366d89c7@leonov.stosberg.net>
Hi,
On Wed, 31 May 2006, Dennis Stosberg wrote:
> Is there any "patch" program at all that understands git's rename
> patches?
Why, yes: git-apply!
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-31 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
hoi :)
On Tue, May 30, 2006 at 03:52:21PM -0700, Junio C Hamano wrote:
> you can switch to another existing topic branch do with "git
> checkout", perhaps with the -m flag. While I was on the "master" to
> figure out why gitweb was not behaving for me, and figured out a mis-
> configuration that should be fixed in "newconf" topic, I switched to
> that topic and committed the fix there, after testing the change
> there. Then either merging it back to "master" or rebuilding "master"
> from scratch based on "origin" and merging my topics got me a working
> gitweb back.
So perhaps my real problem was that I did not know about checkout -m.
Your description of the workflow is of course much saver then
automatically committing to an other branch.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Update documentation for git-format-patch
From: Jakub Narebski @ 2006-05-31 15:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060531141408.G366d89c7@leonov.stosberg.net>
Dennis Stosberg wrote:
> --c|--check::
> - Display suspicious lines in the patch. The definition
> - of 'suspicious lines' is currently the lines that has
> - trailing whitespaces, and the lines whose indentation
> - has a SP character immediately followed by a TAB
> - character.
So is this option also lost in built-in git-format-patch?
> -CONFIGURATION
> --------------
> -You can specify extra mail header lines to be added to each
> -message in the repository configuration as follows:
> -
> -[format]
> - headers = "Organization: git-foo\n"
So is this configuration option also lost in built-in git-format-patch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Remove possible segfault in http-fetch.
From: Nick Hengeveld @ 2006-05-31 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, git
In-Reply-To: <7vverzzukg.fsf@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 12:49:19AM -0700, Junio C Hamano wrote:
> curl_easy_cleanup() which is called from http_cleanup() says it
> is safe to remove the strings _after_ you call that function, so
> I think the change makes sense -- it was apparently unsafe to
> free them before calling cleanup.
>
> Knowing nothing about quirks in curl libraries, one thing that
> is mystery to me is that we slist_append() to other two lists
> (pragma_header and range_header) but we do not seem to ever free
> them. Another slist dav_headers is allocated and then freed
> inside a function, so that call-pattern seems well-formed.
>
> Nick, care to help us out?
I just got back from a trip to the midwest and am still getting caught
up. I was only gone for 10 days, you've all been quite busy...
You're correct wrt the other slists, I'll get to work on a patch for
that after I've caught up.
I'm also doing additional testing to see whether this fixes the DAV/405
segfault as I think there may be something else going on there.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* No tags when cloing the Linux history tree
From: Marcel Holtmann @ 2006-05-31 17:23 UTC (permalink / raw)
To: git; +Cc: Thomas Gleixner
Hi guys,
when cloning the Linux history tree from Thomas Gleixner over HTTP or
GIT transports using cg-clone (instead of git-clone), I don't get the
tags. I checked on master.kernel.org and all tags are present there.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Update documentation for git-format-patch
From: Dennis Stosberg @ 2006-05-31 17:24 UTC (permalink / raw)
To: git
In-Reply-To: <e5kcfi$124$1@sea.gmane.org>
Jakub Narebski wrote:
> Dennis Stosberg wrote:
>
> > - Display suspicious lines in the patch. The definition
> > - of 'suspicious lines' is currently the lines that has
> > - trailing whitespaces, and the lines whose indentation
> > - has a SP character immediately followed by a TAB
> > - character.
>
> So is this option also lost in built-in git-format-patch?
Johannes Schindelin made that one a diff option, so it can be used in
other ways, too. I think it should be documented in diff-options.txt.
> > -CONFIGURATION
> > -You can specify extra mail header lines to be added to each
> > -message in the repository configuration as follows:
> > -
> > -[format]
> > - headers = "Organization: git-foo\n"
>
> So is this configuration option also lost in built-in git-format-patch?
Grep'ing the sources, I couldn't find any trace of it.
Regards,
Dennis
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu077ywmw.fsf@assigned-by-dhcp.cox.net>
On 5/31/06, Junio C Hamano <junkio@cox.net> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > I'm confused by the following:
> > paolo@Italia:~/git$ ./GIT-VERSION-GEN
> > GIT_VERSION = 1.3.3.g2186
> >
> > paolo@Italia:~/git$ git --version
> > git version 1.3.GIT
> >
> > Why git --version is not reporting the "full" version number?
>
> There is a bit of chicken and egg problem involved. The build
> procedure wants to have an already installed git to figure out
> the "full" version number. If you are bootstrapping, make clean
> and rebuild after you install git once would give you a git
> binary that knows what version it is.
Either I didn't understand your answer or something is wrong with my
git installation:
paolo@Italia:~$ cd git/
paolo@Italia:~/git$ git --version
git version 1.3.GIT
paolo@Italia:~/git$ make >/dev/null
paolo@Italia:~/git$ sudo make install >/dev/null
Password:
GIT_VERSION = 1.3.GIT
paolo@Italia:~/git$ git --version
git version 1.3.GIT
paolo@Italia:~/git$
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Junio C Hamano @ 2006-05-31 19:02 UTC (permalink / raw)
To: git; +Cc: Seth Falcon
In-Reply-To: <m2mzcycn4f.fsf@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> writes:
> Matthias Kestenholz <lists@spinlock.ch> writes:
>
>> * Geoff Russell (geoffrey.russell@gmail.com) wrote:
>>> It appears to have got lost when the shell script got converted to C.
>>>
>> Yes, this was intentional. You should sign off your changes while
>> committing (git commit -s|--signoff)
A bit on this later, but first to clear one thing up...
> When should one commit _without_ signoff?
>
> The obvious answer is: when one doesn't approve of the changes in the
> commit... But in my usual workflow, commit means
> works-for-me-I-think-it-is-good. :-)
Please, calm down and read Documentation/SubmittingPatches,
item (6), to understand what sign-off means. It does not have
anything to do with the result of the commit "working". I do
not use -s when making commits during my day-job, for example.
We do not want to make sign-off the default. It has to be a
concious act on the signer's part to add one. Otherwise it
would not carry much weight.
About the droppage of "format-patch -s", I have come to think of
it as a mistake (yes, I can change my mind). Consider:
* You are the leader of a group of people who hack on a part of
the kernel, internally in your company. You and other
developers make improvements and make commits, with "git
commit -s".
* As the in-company integrator, you maintain the canonical
"company tree" by pulling from others in your group.
* It's time to send good pieces to Linus and/or Andrew and as
the group lead you are responsible for sending them out. The
commits would have Sign-off's by the original committers, but
as the contact person (representative) of your group, your
name is better recognizable in the outside community, and as
the leader of your group, it is a good practice for _you_ to
vouch for what your group did.
In that scenario, in addition to what "commit -s" gives us, it
is handy for the person who is sending the patches out via
e-mail to add his own sign-off.
Now, we could do that by re-adding "format-patch -s" option, or
alternatively we could add that to "send-email". We might want
to do both ;-)
^ 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