* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Arafangion @ 2008-11-21 10:34 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: git
In-Reply-To: <1227261564-13268-1-git-send-email-andy.shevchenko@gmail.com>
On Fri, 2008-11-21 at 11:59 +0200, Andy Shevchenko wrote:
> By default git-send-email does not accept patch which is contain lines longer
> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
> variable in shell script. So, define environment variable
> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
As a curiosity, why is such a check even neccessary?
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Michael J Gruber @ 2008-11-21 12:49 UTC (permalink / raw)
To: Jeff King; +Cc: Andy Shevchenko, git
In-Reply-To: <20081121115813.GB3747@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 21.11.2008 12:58:
> On Fri, Nov 21, 2008 at 11:59:24AM +0200, Andy Shevchenko wrote:
>
>> By default git-send-email does not accept patch which is contain lines longer
>> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
>> variable in shell script. So, define environment variable
>> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
>
> This already exists as "git send-email --no-validate", which
> unfortunately doesn't seem to be documented. Care to send in a
> documentation patch instead?
In fact it is documented in git-send-email.txt:
--[no-]validate::
Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than
998 characters; this
is due to SMTP limits as described by
http://www.ietf.org/rfc/rfc2821.txt.
--
+
Default is the value of 'sendemail.validate'; if this is not set,
default to '--validate'.
Cheers,
Michael
^ permalink raw reply
* Re: Bad git status performance
From: Jean-Luc Herren @ 2008-11-21 12:46 UTC (permalink / raw)
To: Glenn Griffin, Git Mailing List
In-Reply-To: <c9e534200811201711y887ddd2t33013ec4a7db3c9a@mail.gmail.com>
Glenn Griffin wrote:
> On Thu, Nov 20, 2008 at 4:28 PM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>> The first 'git status' shows the same difference as the second,
>> just the second time it's staged instead of unstaged. Why does it
>> take 16 seconds the second time when it's instant the first time?
>
> I believe the two runs of git status need to do very different things.
> When run the first time, git knows the files in your working
> directory are not in the index so it can easily say those files are
> 'Changed but not updated' just from their existence.
I might be mistaken about how the index works, but those paths
*are* in the index at that time. They just have the old content,
i.e. the same content as in HEAD. When HEAD == index, then
nothing is staged.
But the presence of those files alone doesn't tell you that they
have changed. You have to look at the content and compare it to
the index (== HEAD in this situation) to see whether they have
changed or not and for some reason git can do this very quickly.
> The second run
> those files do exist in both the index and the working directory, so
> git status first shows the files that are 'Changes to be committed'
> and that should be fast, but additionally git status will check to see
> if those files in your working directory have changed since you added
> them to the index.
Which is basically the same comparision as above, just it turns
out that they have not changed. But even then, we're talking
about comparing a 1 byte file in the index to a 1 byte file in the
work tree. That doesn't take 16 seconds, even for 100 files.
So this makes me believe it's the first step (comparing HEAD to
the index to show staged changes) that is slow. And when you
compare a 1MB file to a 1 byte file, you don't need to read all of
the big file, you can tell they're not the same right after the
first byte. (Even an doing stat() is enough, since the size is
not the same.)
Another thing that came to my mind is maybe rename detection kicks
in, even though no path vanished and none is new. I believe
rename detection doesn't happen for unstaged changes, which might
explain the difference in speed.
btw, I forgot to mention that I get this with branches maint,
master, next and pu.
(And I hope you don't mind I take this back to the list.)
jlh
^ permalink raw reply
* Re: [TopGit PATCH] put die() messages to stderr
From: martin f krafft @ 2008-11-21 12:36 UTC (permalink / raw)
To: Bert Wesarg, Petr Baudis, git
In-Reply-To: <1227261900-23420-1-git-send-email-bert.wesarg@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1105 +0100]:
> - info "fatal: $*"
> + info "fatal: $*" >&2
Shouldn't info also output to stderr?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"i have made good judgments in the past.
i have made good judgments in the future."
- george w. bush
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: martin f krafft @ 2008-11-21 12:31 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, petr baudis
In-Reply-To: <36ca99e90811210418i5ae14a42t882988aed289d534@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1318 +0100]:
> Oh, I send a patch only to petr, but forgot to cc the list ;-)
Maybe you can try to remember to CC me on topgit stuff in the future
too, since I am helping Petr out a bit as his release apprentice. :)
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
i stopped fighting my inner demons.. we're all on the same side now.
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: martin f krafft @ 2008-11-21 12:23 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, petr baudis, 501982
In-Reply-To: <36ca99e90811210415g7b50c5c1m3185bf19cab104aa@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1315 +0100]:
> I CC'ed Junio, because I think this git rev-parse --git-dir is
> a bug. For example you can try starting git gui inside a .git dir.
You might want to let him know of your intention. :)
> A patch would depent on your --help patch, Because help should
> work everywhere. So either I wait for you or do do it.
No, not depend, but the patch makes the --help situation slightly
worse, for now you cannot call --help inside .git anymore either.
This will force us to fix the --help situation quicker.
I've run out of time, for a while at least. If you want to pick up
the pieces and convert argument parsing to POSIX getopt, or maybe
even better, git-rev-parse --parseopt, then please go for it. You
can find my current TopGit branch at
http://git.debian.org/?p=collab-maint/topgit.git;a=shortlog;h=refs/heads/fixes/independent-help
git://git.debian.org/git/collab-maint/topgit.git, branch fixes/independent-help
If you use Debian: debcheckout topgit (requires devscripts 2.10.40)
Thanks,
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"heuristic is computer science jargon for 'doesn't actually work.'"
-- charlie reiman
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: Bert Wesarg @ 2008-11-21 12:18 UTC (permalink / raw)
To: martin f krafft; +Cc: git, petr baudis, 501982
In-Reply-To: <36ca99e90811210415g7b50c5c1m3185bf19cab104aa@mail.gmail.com>
On Fri, Nov 21, 2008 at 13:15, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> On Fri, Nov 21, 2008 at 13:06, martin f krafft <madduck@debian.org> wrote:
>> I think you wanted to CC Petr, not Junio. It's also useful to CC
>> Debian bugs if you know of them. :)
> I CC'ed Junio, because I think this git rev-parse --git-dir is a bug.
> For example you can try starting git gui inside a .git dir.
Oh, I send a patch only to petr, but forgot to cc the list ;-)
But your patch should be fine, thanks.
Bert
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: Bert Wesarg @ 2008-11-21 12:15 UTC (permalink / raw)
To: martin f krafft; +Cc: git, petr baudis, 501982
In-Reply-To: <20081121120609.GA10326@piper.oerlikon.madduck.net>
On Fri, Nov 21, 2008 at 13:06, martin f krafft <madduck@debian.org> wrote:
> I think you wanted to CC Petr, not Junio. It's also useful to CC
> Debian bugs if you know of them. :)
I CC'ed Junio, because I think this git rev-parse --git-dir is a bug.
For example you can try starting git gui inside a .git dir.
>
> also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1019 +0100]:
>> I really second this. Plus, I think its crucial to check that we are
>> not inside the .git directory before setting up topgit. Because git
>> rev-parse --git-dir only works in the top .git dir, not deeper (i.e.
>> inside .git/refs) and will always return ".".
>>
>> $(git rev-parse --is-inside-work-tree) ||
>> die "Not in a git working directory"
>
> Thanks, noted. I am still working on this patch, since
> evaluating $argv/checking for --help at this early stage basically
> requires a rewrite of the CLI parsing, ideally using POSIX getopt or
> something similar, which takes much of the load away.
>
> Anyway, Patch for your proposal forthcoming.
A patch would depent on your --help patch, Because help should work everywhere.
So either I wait for you or do do it.
Bert
>
> --
> .''`. martin f. krafft <madduck@debian.org>
> : :' : proud Debian developer, author, administrator, and user
> `. `'` http://people.debian.org/~madduck - http://debiansystem.info
> `- Debian - when you have better things to do than fixing systems
>
> (a)bort, (r)etry, (p)retend this never happened
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkkmpDAACgkQIgvIgzMMSnUSKgCghXE+J9KegZ03tetnM3TIcyeM
> zn0AoJmYVzh/Kjxk7NFEpQw7USR0daXy
> =xl31
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply
* [TopGit PATCH] Ensure we are inside a Git worktree
From: martin f. krafft @ 2008-11-21 12:09 UTC (permalink / raw)
To: git, pasky; +Cc: martin f. krafft
In-Reply-To: <20081121120609.GA10326@piper.oerlikon.madduck.net>
Bert Wesarg suggests to check that we are not inside the .git directory before
setting up topgit. Because git rev-parse --git-dir only works in the top .git
dir, not deeper (i.e. inside .git/refs) and will always return "."
This patch thus causes topgit to die early on when it's called from outside of
a Git repository, or from underneath .git and outputs error messages
accordingly.
This temporarily makes it even more impossible to call tg --help, but I expect
to have that fixed soon too.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/tg.sh b/tg.sh
index 8c23d26..f8c8de4 100644
--- a/tg.sh
+++ b/tg.sh
@@ -17,6 +17,20 @@ die()
exit 1
}
+# Make sure we are in the worktree, not under .git; die otherwise
+ensure_git_repo_or_die()
+{
+ local is_inside_repo is_inside_git_dir
+ is_inside_repo=1
+ is_inside_git_dir=$(git rev-parse --is-inside-git-dir 2>/dev/null) ||
+ is_inside_repo=0
+
+ case "$is_inside_repo/$is_inside_git_dir" in
+ 0*) die "Cannot run outside of a Git repository.";;
+ 1/true) die "Cannot run from inside \`.git\` hierarchy, please switch to work-tree.";;
+ esac
+}
+
# setup_hook NAME
setup_hook()
{
@@ -249,6 +263,8 @@ do_help()
[ -d "@cmddir@" ] ||
die "No command directory: '@cmddir@'"
+ensure_git_repo_or_die
+
## Initial setup
set -e
--
tg: (2ea19b6..) fixes/ensure-worktree (depends on: upstream)
^ permalink raw reply related
* TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: martin f krafft @ 2008-11-21 12:06 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, petr baudis, 501982
In-Reply-To: <36ca99e90811210119s215513a8m7c12c8d55fd54d70@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
I think you wanted to CC Petr, not Junio. It's also useful to CC
Debian bugs if you know of them. :)
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1019 +0100]:
> I really second this. Plus, I think its crucial to check that we are
> not inside the .git directory before setting up topgit. Because git
> rev-parse --git-dir only works in the top .git dir, not deeper (i.e.
> inside .git/refs) and will always return ".".
>
> $(git rev-parse --is-inside-work-tree) ||
> die "Not in a git working directory"
Thanks, noted. I am still working on this patch, since
evaluating $argv/checking for --help at this early stage basically
requires a rewrite of the CLI parsing, ideally using POSIX getopt or
something similar, which takes much of the load away.
Anyway, Patch for your proposal forthcoming.
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
(a)bort, (r)etry, (p)retend this never happened
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Jeff King @ 2008-11-21 12:04 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Arafangion, git
In-Reply-To: <5ec8ebd50811210237kd6f9341q23bc69b6ffcc2a87@mail.gmail.com>
On Fri, Nov 21, 2008 at 12:37:08PM +0200, Andy Shevchenko wrote:
> > As a curiosity, why is such a check even neccessary?
> I'm not an author of that strange check (possible it's somehow related
> to b8ebe08b9a643f432866eb7150c3b20d59b755f2)
I am the author, and it was a direct response to a user who had
something in his mail path munging overly long lines (which are, in
fact, disallowed by rfc 2822).
Read this thread:
http://thread.gmane.org/gmane.comp.version-control.git/70847
which contains the problem report and the patches. We could take this
one step further (but didn't at the time) by QP-encoding the body part
with long lines, which is what a normal MUA would do. Since the
receiving tools for git handle this situation, it should work fine. I
think such a patch would be welcome.
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Jeff King @ 2008-11-21 11:58 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: git
In-Reply-To: <1227261564-13268-1-git-send-email-andy.shevchenko@gmail.com>
On Fri, Nov 21, 2008 at 11:59:24AM +0200, Andy Shevchenko wrote:
> By default git-send-email does not accept patch which is contain lines longer
> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
> variable in shell script. So, define environment variable
> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
This already exists as "git send-email --no-validate", which
unfortunately doesn't seem to be documented. Care to send in a
documentation patch instead?
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Andreas Ericsson @ 2008-11-21 11:46 UTC (permalink / raw)
To: Arafangion; +Cc: Andy Shevchenko, git
In-Reply-To: <1227265742.3311.8.camel@therock.nsw.bigpond.net.au>
Arafangion wrote:
> On Fri, 2008-11-21 at 12:37 +0200, Andy Shevchenko wrote:
>> On Fri, Nov 21, 2008 at 12:34 PM, Arafangion <thestar@fussycoder.id.au> wrote:
>>>> By default git-send-email does not accept patch which is contain lines longer
>>>> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
> <snip>
>>> As a curiosity, why is such a check even neccessary?
>> I'm not an author of that strange check (possible it's somehow related
>> to b8ebe08b9a643f432866eb7150c3b20d59b755f2)
>
> I can't seem to find that changeset, however the reason why I asked is
> because I thought I remembered that some mail clients could crash if
> they got lines longer than that, and we should cater for that even if
> those clients should handle mails better than that! Apparently it's
> specified in the relevant RFC2822, and this particular solution has
> already been contributed as:
> https://kerneltrap.org/mailarchive/git/2008/1/18/579779
>
Well, there's quite a lot of arguing following that mail, and it
doesn't seem to end with a final decision.
> I would be inclined to suggest that such patches should be sent as an
> attachment instead?
No, that would be bad. Many communities (git included) discard
patches that aren't sent inline unless that's for a very good reason
(translation patches are almost always inline, as they tend to break
stuff for people who lack the proper encoding).
> While patches should be sent inline to encourage discussion of the
> patch, if the patch has such insanely long lines, the probability that
> the bulk of your audience in having a good email client that doesn't
> mangle your patch may become rather low.
>
Reviewable source-code doesn't contain lines longer than 100 or so lines
anyway, so we might as well break on some arbitrary (say, 200) width
and ask the user to resubmit with the "--attach" option if they really
want to send their patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Arafangion @ 2008-11-21 11:09 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: git
In-Reply-To: <5ec8ebd50811210237kd6f9341q23bc69b6ffcc2a87@mail.gmail.com>
On Fri, 2008-11-21 at 12:37 +0200, Andy Shevchenko wrote:
> On Fri, Nov 21, 2008 at 12:34 PM, Arafangion <thestar@fussycoder.id.au> wrote:
> >> By default git-send-email does not accept patch which is contain lines longer
> >> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
<snip>
> > As a curiosity, why is such a check even neccessary?
> I'm not an author of that strange check (possible it's somehow related
> to b8ebe08b9a643f432866eb7150c3b20d59b755f2)
I can't seem to find that changeset, however the reason why I asked is
because I thought I remembered that some mail clients could crash if
they got lines longer than that, and we should cater for that even if
those clients should handle mails better than that! Apparently it's
specified in the relevant RFC2822, and this particular solution has
already been contributed as:
https://kerneltrap.org/mailarchive/git/2008/1/18/579779
I would be inclined to suggest that such patches should be sent as an
attachment instead? (Though this may become bikeshed painting on my
part, see
http://www.freebsd.org/doc/en/articles/mailing-list-faq/bikeshed.html
for what I mean by the term).
While patches should be sent inline to encourage discussion of the
patch, if the patch has such insanely long lines, the probability that
the bulk of your audience in having a good email client that doesn't
mangle your patch may become rather low.
(I really should get some sleep, not good to be argumentative when
people are contributing very useful patches, like yourself!)
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Andy Shevchenko @ 2008-11-21 10:55 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Arafangion, git
In-Reply-To: <87wsex4aha.fsf@iki.fi>
On Fri, Nov 21, 2008 at 12:52 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
Actually, the --no-validate is the true option for that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Teemu Likonen @ 2008-11-21 10:52 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Arafangion, git
In-Reply-To: <5ec8ebd50811210237kd6f9341q23bc69b6ffcc2a87@mail.gmail.com>
Andy Shevchenko (2008-11-21 12:37 +0200) wrote:
> On Fri, Nov 21, 2008 at 12:34 PM, Arafangion <thestar@fussycoder.id.au> wrote:
>>> By default git-send-email does not accept patch which is contain
>>> lines longer than 998 symbols. Sometime it's inconvenient, i.e. you
>>> have a long list in one variable in shell script. So, define
>>> environment variable GIT_SEND_EMAIL_LONGLINE to something to avoid
>>> that restriction.
>>
>> As a curiosity, why is such a check even neccessary?
> I'm not an author of that strange check (possible it's somehow related
> to b8ebe08b9a643f432866eb7150c3b20d59b755f2)
The author (so to say) of that strange check is RFC 2822 - Internet
Message Format.
2.1.1. Line Length Limits
There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more
than 998 characters, and SHOULD be no more than 78 characters,
excluding the CRLF.
The 998 character limit is due to limitations in many
implementations which send, receive, or store Internet Message
Format messages that simply cannot handle more than 998
characters on a line. [...]
http://www.faqs.org/rfcs/rfc2822.html
Perhaps longer lines will work in many cases but atleast warning should
be printed to user, or something.
^ permalink raw reply
* Re: [PATCH] mmap implementation for mingw.
From: Johannes Schindelin @ 2008-11-21 10:48 UTC (permalink / raw)
To: Vasyl' Vavrychuk; +Cc: git, Johannes Sixt
In-Reply-To: <gg5t5s$qc8$1@ger.gmane.org>
Hi,
[re-Cc:ed j6t]
On Fri, 21 Nov 2008, Vasyl' Vavrychuk wrote:
> [Dscho knows that j6t wrote this:]
>
> > It doesn't pass the test suite, for example t5301-sliding-window.sh
> > fails.
>
> I will investigate.
Note that I quickly discarded the idea of mmap() on MinGW because at least
in the past, we used to rename files that were mmap()ed. That is a no-go
with CreateFile().
And I'd really like to see speed comparisons; AFAIR we had major issues
with mmap() performance on MacOSX, and use lseek() && pread() for
that particular code instead now.
Note that I find your work valuable, even if it should turn out that
CreateFile() is slower, because at least we will know.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Andy Shevchenko @ 2008-11-21 10:37 UTC (permalink / raw)
To: Arafangion; +Cc: git
In-Reply-To: <1227263693.3311.0.camel@therock.nsw.bigpond.net.au>
On Fri, Nov 21, 2008 at 12:34 PM, Arafangion <thestar@fussycoder.id.au> wrote:
>> By default git-send-email does not accept patch which is contain lines longer
>> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
>> variable in shell script. So, define environment variable
>> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
>
> As a curiosity, why is such a check even neccessary?
I'm not an author of that strange check (possible it's somehow related
to b8ebe08b9a643f432866eb7150c3b20d59b755f2)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Andy Shevchenko @ 2008-11-21 9:59 UTC (permalink / raw)
To: git; +Cc: Andy Shevchenko
By default git-send-email does not accept patch which is contain lines longer
than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..29f700d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -981,7 +981,7 @@ sub validate_patch {
open(my $fh, '<', $fn)
or die "unable to open $fn: $!\n";
while (my $line = <$fh>) {
- if (length($line) > 998) {
+ if (length($line) > 998 and not $ENV{GIT_SEND_EMAIL_LONGLINE}) {
return "$.: patch contains a line longer than 998 characters";
}
}
--
1.6.0.2.GIT
^ permalink raw reply related
* [TopGit PATCH] put die() messages to stderr
From: Bert Wesarg @ 2008-11-21 10:05 UTC (permalink / raw)
To: Petr Baudis, Petr Baudis; +Cc: Bert Wesarg, git
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index 4dcc15e..21294f9 100644
--- a/tg.sh
+++ b/tg.sh
@@ -13,7 +13,7 @@ info()
die()
{
- info "fatal: $*"
+ info "fatal: $*" >&2
exit 1
}
--
tg: (f17218e..) bw/die-to-stderr (depends on: master)
^ permalink raw reply related
* Re: Cannot git pull using http from my git.mycompany.com
From: Andreas Ericsson @ 2008-11-21 9:54 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <562019.27220.qm@web37908.mail.mud.yahoo.com>
Gary Yang wrote:
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> Below are related gitweb configs. What did I do wrong?
>
>
> httpd.confg
>
> <VirtualHost 10.66.4.168>
> ServerName svdcgit01
> DocumentRoot /pub/git
> <Directory /var/www/cgi-bin>
> Allow from all
> AllowOverride all
> Order allow,deny
> Options ExecCGI
> <Files gitweb.cgi>
> SetHandler cgi-script
> </Files>
> </Directory>
> DirectoryIndex /cgi-bin/gitweb.cgi
> SetEnv GITWEB_CONFIG /etc/gitweb.conf
> # RewriteEngine on
> # RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
>
>
> cat /etc/gitweb.conf
You seem slightly confused. gitweb is not used for cloning over http.
The following documents would almost certainly be beneficial for you
to read. Please don't ask any questions that are already answered in
those documents. If, by following the steps outlined in those docs,
you still cannot get things to work, please let us know what you fail
to understand so the texts can be amended.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#setting-up-a-public-repository
http://dtcsupport.gplhost.com/Git/Public-Repo-Howto
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] mmap implementation for mingw.
From: Johannes Sixt @ 2008-11-21 9:44 UTC (permalink / raw)
To: Vasyl' Vavrychuk; +Cc: git
In-Reply-To: <gg5t5s$qc8$1@ger.gmane.org>
Please "reply to all" to keep the Cc list.
Vasyl' Vavrychuk schrieb:
>> Did you notice any differences with this? Or is this change just
>> because-we-can?
> Not yet.
This patch makes sense only if there is a noticable speed improvement. I
doubt that the gain is measurable in the warm-cache case, but in the
cold-cache case we can perhaps indeed save a number of disk accesses if
whole pack files need not be slurped in (which the current mmap
replacements do).
> Maybe write own getpagesize() based on GetSystemInfo()?
It's probably worth it (but only if mmap() makes sense at all).
getpagesize() is used in the "sliding window" code to access pack files,
and then the offset is non-zero and must be aligned properly. Make this a
separate commit.
-- Hannes
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: Bert Wesarg @ 2008-11-21 9:19 UTC (permalink / raw)
To: martin f. krafft, Junio C Hamano; +Cc: git
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
Hi,
On Wed, Nov 19, 2008 at 17:03, martin f. krafft <madduck@debian.org> wrote:
> The user ought to be able to call `tg help` from anywhere in the
> filesystem, not just Git repositories, so the help parsing has to happen
> before the calls to git git binary.
>
> Debian bug: #501982
I really second this. Plus, I think its crucial to check that we are
not inside the .git directory before setting up topgit. Because git
rev-parse --git-dir only works in the top .git dir, not deeper (i.e.
inside .git/refs) and will always return ".".
$(git rev-parse --is-inside-work-tree) ||
die "Not in a git working directory"
Bert
^ permalink raw reply
* Re: [PATCH] mmap implementation for mingw.
From: Vasyl' Vavrychuk @ 2008-11-21 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <49266A59.4010404@viscovery.net>
Hello Johannes,
Thank you for your comments. It's my first patch on git so please be kind:)
At the weekend I hope I will find time to work on this.
> Vasyl Vavrychuk schrieb:
>
>> Here is simple and restricted implementation of mmap using
>> CreateFileMapping, MapViewOfFile.
>>
> Thanks. Sign-off?
Will be.
> Did you notice any differences with this? Or is this change just
> because-we-can?
Not yet.
> It doesn't pass the test suite, for example t5301-sliding-window.sh
> fails.
I will investigate.
>
>> --- a/compat/mingw.c
>> +++ b/compat/mingw.c
>> @@ -994,3 +994,30 @@ void mingw_open_html(const char *unixpath)
>> printf("Launching default browser to display HTML ...\n");
>> ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> }
>> +
>> +void *mingw_mmap(void *start, size_t length, int prot, int flags,
>> int fd,
>> off_t offset)
>> +{
>> + HANDLE handle;
>> +
>> + if (start != NULL || !(flags & MAP_PRIVATE))
>> + die("Invalid usage of mingw_mmap");
> I tend to use this idiom:
>
> return errno = EINVAL,
> error("Invalid usage of mingw_mmap");
Interesting.
>> + if (offset % getpagesize() != 0)
>> + die("Offset does not match the memory allocation granularity");
> This is dangerous. Because on MinGW getpagesize() is hard-coded to
> 0x1000. getpagesize() does not consult GetSystemInfo(). Just skip the
> check; MapViewOfFile() will report the error later anyway. Or better
> carefully compute a suitable offset and adjust the length accordingly.
I haven't known about hardcoded getpagesize(). Ajusting will be good but
it will not solve problem with hardcoded
getpagesize(). Maybe write own getpagesize() based on GetSystemInfo()?
>
>> +
>> + handle = CreateFileMapping((HANDLE)_get_osfhandle(fd), NULL,
>> PAGE_WRITECOPY,
>> + 0, 0, NULL);
>> +
>> + if (handle != NULL) {
>> + start = MapViewOfFile(handle, FILE_MAP_COPY, 0, offset,
>> length);
>> + CloseHandle(handle);
>> + }
>> +
>> + return start;
> Upon failure you should return MAP_FAILED, not NULL.
OK
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -175,10 +175,12 @@ static inline const char *skip_prefix(const
>> char *str,
>> const char *prefix)
>> #define MAP_FAILED ((void*)-1)
>> #endif
>> +#ifndef __MINGW32__
>> #define mmap git_mmap
>> #define munmap git_munmap
>> extern void *git_mmap(void *start, size_t length, int prot, int
>> flags, int fd,
>> off_t offset);
>> extern int git_munmap(void *start, size_t length);
>> +#endif
>> /* This value must be multiple of (pagesize * 2) */ #define
>> DEFAULT_PACKED_GIT_WINDOW_SIZE (1 * 1024 * 1024)
>>
> This is inside #ifdef NO_MMAP ... #else section. Isn't that a bit
> strange? I.e. we say NO_MMAP, but then we do have mmap() now?
>
Agree
^ permalink raw reply
* Re: Cannot git pull using http from my git.mycompany.com
From: David Symonds @ 2008-11-21 8:43 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <562019.27220.qm@web37908.mail.mud.yahoo.com>
On Fri, Nov 21, 2008 at 12:13 PM, Gary Yang <garyyang6@yahoo.com> wrote:
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> Below are related gitweb configs. What did I do wrong?
As the error message asks, did you run git update-server-info on the server?
Dave.
^ 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