* gitk on Windows: layout problem
From: Rutger Nijlunsing @ 2006-05-30 18:54 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Hi,
Is this a known problem? gitk-du-jour on Windows starts up with an
unusable layout. Screenshot attached.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
[-- Attachment #2: gitk.PNG --]
[-- Type: image/png, Size: 11482 bytes --]
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Stefan-W. Hahn @ 2006-05-30 19:20 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <20060530185441.GA10985@nospam.com>
Also sprach Rutger Nijlunsing am Tue, 30 May 2006 at 20:54:41 +0200:
> Is this a known problem? gitk-du-jour on Windows starts up with an
> unusable layout. Screenshot attached.
I have the same problem using gitk on Windows with Cygwin. Till now I avoid the
problem (because I know too little about TCL/TK) with commenting out the line
"catch {source ~/.gitk}". Then then window can be sized to correct layout.
Stefan
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Johannes Schindelin @ 2006-05-30 19:21 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <20060530185441.GA10985@nospam.com>
Hi,
On Tue, 30 May 2006, Rutger Nijlunsing wrote:
> Is this a known problem? gitk-du-jour on Windows starts up with an
> unusable layout. Screenshot attached.
This is a known problem. See
http://article.gmane.org/gmane.comp.version-control.git/18209
Hth,
Dscho
^ permalink raw reply
* t9001 fails because Net::SMTP is missing
From: Johannes Schindelin @ 2006-05-30 19:26 UTC (permalink / raw)
To: git
Hi,
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:
/System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin
/Library/Perl /Library/Perl /Network/Library/Perl/darwin
/Network/Library/Perl /Network/Library/Perl .) at
/Users/gene099/my/git-current/t/../git-send-email line 24.
BEGIN failed--compilation aborted at
/Users/gene099/my/git-current/t/../git-send-email line 24.
* FAIL 3: Extract patches and send
-- snap --
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-30 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr72b27x9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
hoi :)
On Tue, May 30, 2006 at 02:12:02AM -0700, Junio C Hamano wrote:
> I think this was discussed in the past and I appreciate what you
> are trying to do. My understanding of the situation your patch
> is trying to improve is this:
>
> - you have done a few topics and you are ready to test;
>
> - you pulled the topics into your test branch and have found
> problems;
>
> - you made changes while still on the test branch (otherwise
> you wouldn't be able to test the "fix") and it seems to work
> OK;
>
> - what now?
>
> And your approach is to backport the fix to its original topic
> and then re-pull the topic onto the test branch.
yes. I was doing this after working on gitweb a bit.
In order to test gitweb, I need some local adaptations.
I commited these to one branch and put all improvements to
another branch. Then I merged both branches to one production
path which is then used by the webserver.
> While I think that is _one_ valid workflow, I am not convinced
> that is _the_ best workflow.
Me neigther.
That's why I labeled it RFC and published it before doing too much
testing and polishing ;-)
> What Johannes suggested would
> equally work fine, and honestly speaking probably is a better
> discipline.
He suggested to create a new branch (based on current HEAD) for the
new commit. Unfortunately that doesn't solve my problem.
> You carry the fix in your working tree back to its
> original topic and make a commit, without pulling the topic onto
> the test branch immediately. This has two advantages:
>
> - With your workflow, you will have a merge commit onto the
> testing branch immediately when you commit this fix to the
> original topic. But often when I encounter this situation,
> after moving to the topic to backport the fix to it, I find
> myself reviewing what is in the topic and making other
> changes to the topic.
Of course you can do this also while you are still on the test branch.
While looking at code I often see unrelated stuff which can be cleaned
up. With something like commit --branch it would be possible to stuff
these changes to a "trivial" branch without having to change branches
explicitly.
> Johannes's workflow feels more natural
> to me from this aspect -- I take the fix I discovered while
> on the testing branch to the relevant topic to fix it. I may
> or may not make the commit only with that fix (the first
> commit I make after switching the branches from testing to
> the topic may contain more than that fix), and after I make
> one commit, I may keep working on the topic a bit more before
> I decide it is a good time to test the whole thing again (to
> pull the topic into testing). I do not necessarily want that
> extra merge immediately in the test branch.
But if your commit to the topic is really different to previous
commit on the test branch then you may have merge problems later.
If you merge immediately, you even get the merged tree for free ;-).
The testing branch is more like a throwaway-branch for me.
I can recreate it anytime if I want and I don't care about extra
merge commits here.
> - A topic branch should be testable alone;
That would be best, yes.
Unfortunately it didn't work for me.
Well I guess I could have put more effort on changing gitweb to
be more general so that I don't need local adaptations.
But I guess there are situations where this is not possible, too.
Of course, now we have to answer the question whether GIT should
support these situations. I don't know.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git --version
From: Paolo Ciarrocchi @ 2006-05-30 22:16 UTC (permalink / raw)
To: Git Mailing List
Hi all,
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?
Thanks.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Junio C Hamano @ 2006-05-30 22:29 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30605301516l782ad81dk5b11074e88db90a4@mail.gmail.com>
"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.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-30 22:31 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B7669.8050805@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> Martin Langhoff wrote:
> > On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> >> Finally hit an OOM sometime in the past day (yep, a week later) =\. Not
> >> sure whether it was cvsimport or cvs. Anyone else had more luck?
With the latest cvsimport in Junio's repo, a lot of RAM and a bit of patience...
gitview
http://git.catalyst.net.nz/gitweb?p=gentoo.git;a=summary
fetchable
http://git.catalyst.net.nz/git/gentoo.git#cvshead
Still pushing it, will be there in a minute or so. The packed repo
weights about 660MB. Not too bad given the size of the project and the
number of commits.
martin
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Junio C Hamano @ 2006-05-30 22:52 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060530210551.GI14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> And your approach is to backport the fix to its original topic
>> and then re-pull the topic onto the test branch.
>
> yes. I was doing this after working on gitweb a bit.
> In order to test gitweb, I need some local adaptations.
Funny you mention this. I had exactly the same arrangement for
hacking on gitweb. One "localconf" branch to tell it where the
repositories are, "origin" to track upstream, "master" to use
for deployment, and other topic branches. I used git-fetch to
keep updating "origin" (not git-pull), grew and rebased topics
based on "origin". "master" was rebuilt from "origin" by
merging "localconf" and topics. Some of the stuff I did in my
topics involved changing the way local configuration is done, so
I had an extra topic "newconf" which branched from "localconf"
but merged from the topic branch.
>> What Johannes suggested would
>> equally work fine, and honestly speaking probably is a better
>> discipline.
>
> He suggested to create a new branch (based on current HEAD) for the
> new commit. Unfortunately that doesn't solve my problem.
When I re-read his suggestion, literally he talks about creating
a new topic, but I assumed he just meant "you could _even_
create a new branch if you wanted to" -- 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.
>> You carry the fix in your working tree back to its
>> original topic and make a commit, without pulling the topic onto
>> the test branch immediately. This has two advantages:
>>
>> - With your workflow, you will have a merge commit onto the
>> testing branch immediately when you commit this fix to the
>> original topic. But often when I encounter this situation,
>> after moving to the topic to backport the fix to it, I find
>> myself reviewing what is in the topic and making other
>> changes to the topic.
>
> Of course you can do this also while you are still on the test branch.
That is something you cannot. The merged test branch contains
other unrelated changes. As you describe, the test branch in
your (and mine) workflow is throw-away in nature, so a proper
fix should go to the relevant topic, and while working on a
single topic, I do not want to see what other topics introduced
to the file -- I may accidentally depend on them, creating
unnecessary interdependencies between topics.
> While looking at code I often see unrelated stuff which can be cleaned
> up. With something like commit --branch it would be possible to stuff
> these changes to a "trivial" branch without having to change branches
> explicitly.
I often find myself spending too much time fixing what I
committed without thinking and testing -- assuming something is
"trivial" which turns out to be not so -- so I try to stay away
from the idea of having a "trivial" branch. But if you want to
do things that way, you could trivially do so by having a
wrapper around git commit. By building something into
git-commit command, you are actively encouraging one workflow,
and commit without testing is one thing I do not particularly
want to encourage people to do. We have selective commit with
"git commit [-i] <paths>..." which is already bad enough.
>> Johannes's workflow feels more natural
>> to me from this aspect -- I take the fix I discovered while
>> on the testing branch to the relevant topic to fix it. I may
>> or may not make the commit only with that fix (the first
>> commit I make after switching the branches from testing to
>> the topic may contain more than that fix), and after I make
>> one commit, I may keep working on the topic a bit more before
>> I decide it is a good time to test the whole thing again (to
>> pull the topic into testing). I do not necessarily want that
>> extra merge immediately in the test branch.
>
> But if your commit to the topic is really different to previous
> commit on the test branch then you may have merge problems later.
I am not sure what you want to say here. You realize some
breakage, do initial/preliminary fix while on the test branch,
take the change to the relevant topic branch to do the real
fix. You can merge the result back to the test branch when your
changes on the topic is ready. I do not see where conflicting
change makes a difference.
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-30 23:07 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605301531g4f8b37c7qab9a717833c64ebc@mail.gmail.com>
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.
And maybe we should make that part of the gitweb docs. Without a caching
web-server, gitweb is pretty slow, but it caches _beautifully_.
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.
Linus
^ permalink raw reply
* 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
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