* 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
* 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] 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
* 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: [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: 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
* [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: 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
* 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: 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: 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
* 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: 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
* 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: 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: [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: [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: 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] 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: 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: 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: 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: 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: 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: [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
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