* Re: [PATCH] git name-rev writes beyond the end of malloc() with large generations
From: Junio C Hamano @ 2007-05-15 19:09 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <2be2ad34be511217dc735a15490f4536@pinky>
Andy Whitcroft <apw@shadowen.org> writes:
> When using git name-rev on my kernel tree I triggered a malloc()
> corruption warning from glibc.
>
> apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
> *** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
> Aborted
>
> This comes from name_rev() which is building the name of the revision
> in a malloc'd string, which it sprintf's into:
>
> char *new_name = xmalloc(len + 8);
> [...]
> sprintf(new_name, "%.*s~%d^%d", len, tip_name,
> generation, parent_number);
>
> This allocation is only sufficient if the generation number is
> less than 5 digits, in my case generation was 13432. In reality
> parent_number can be up to 16 so that also can require two digits,
> reducing us to 3 digits before we are at risk of blowing this
> allocation.
>
> This patch introduces a decimal_length() which approximates the
> number of digits a type may hold, it produces the following:
> ...
Does this attempt to cramp down to what's only necessary really
matter in practice in the light of malloc overhead?
It does futureproof against an insanely long "long long" on
future architectures, but I am not sure if we care either. Why
not just raise 8 to 25 or something and be done with it?
> diff --git a/git-compat-util.h b/git-compat-util.h
> index c08688c..25b8274 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -19,6 +19,9 @@
> #define TYPEOF(x)
> #endif
>
> +/* Approximation of the length of the decimal representation of this type. */
> +#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
> +
> #define MSB(x, bits) ((x) & TYPEOF(x)(~0ULL << (sizeof(x) * 8 - (bits))))
>
> #if !defined(__APPLE__) && !defined(__FreeBSD__)
Having said that, clever and clean math and use of compiler's
ability always attracts me, so maybe I would end up applying
this as is.
^ permalink raw reply
* Re: [PATCH] git-am: Clean up the asciidoc documentation
From: Junio C Hamano @ 2007-05-15 19:00 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070515122357.GF5272@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Mon, May 14, 2007 at 05:01:38PM -0700, Junio C Hamano wrote:
>> Frank Lichtenheld <frank@lichtenheld.de> writes:
>>
>> > -i, --interactive::
>> > - Run interactively, just like git-applymbox.
>> > + Run interactively, just like `git-applymbox` (see gitlink:git-applymbox[1]).
>>
>> This is an unclear description from the original, but I think we
>> should say just like `git-applybox -i`, or drop this altogether.
>
> Hmm, your comment doesn't make any sense to me, because applymbox has
> no -i option.
Ah, my braino. Thanks.
We are not encouraging applymbox to new users anyway, so I'd
just drop the whole ", just like" business.
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Junio C Hamano @ 2007-05-15 18:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11792246701367-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Add -l/--long/--size option to git-ls-tree command, which displays
> object size of an entry after object id (left-justified with minimum
> width of 7 characters).
Not a NAK at all (but not an ACK either yet), but just asking
questions on some design considerations.
* Do these options do different things? If not, why have more
than one (or two, --long and its shorthand -l)?
* Why pad to 7 places? Do we have a similar padding elsewhere?
Will this ever used by non-scripts? How does this padding
affect parsers other than Perl that read this information?
* Does it make sense to show size information when giving a tree
entry? I realize not having it in the output would make the
job of the script reading the output a bit harder, but if this
output is meant also for human consumption I think it would
not be so interesting and raise a confusion factor.
Also I suspect that having to show the size of a tree object,
expressed in terms of the canonical representation, might
force packv4 aware ls-tree to convert its traversal efficient
representation to the canonical one only to get its size.
^ permalink raw reply
* Re: [StGIT RFC PATCH] Activate rename detection by default.
From: Karl Hasselström @ 2007-05-15 18:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, git
In-Reply-To: <b0943d9e0705150841l6fe05baajab67a16eb78e411d@mail.gmail.com>
On 2007-05-15 16:41:47 +0100, Catalin Marinas wrote:
> On 05/05/07, Yann Dirson <ydirson@altern.org> wrote:
>
> > This patch uses -M when generating diffs, which then looks fine,
> > just like any other git-generated diff.
>
> I think we should only use -M for "files", "status", "show", "diff"
> but not for "export" and "mail", maybe by adding an extra parameter
> to git.diff() (or we could have this configurable or with an cmd
> line option). The reason is that I send patches that might not be
> applied with GIT.
Seems like a good idea to me: default to -M whenever the consumer is
guaranteed to understand it, and have it as an option defaulting to
off when we export data.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: Alex Riesen @ 2007-05-15 18:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, kha, bfields
In-Reply-To: <20070515test.1@coredump.intra.peff.net>
Jeff King, Tue, May 15, 2007 09:12:05 +0200:
> This is a test message to check how vger reacts to seeing 8bit
> characters (like Hasselström) in a message without the right mime
> header. Previous attempts were eaten by the list because of a lack of a
> message id.
ok here. Headers:
Received: from googlemail-pop.l.google.com [66.249.93.16]
by steel.home with POP3 (fetchmail-6.3.6 polling pop.googlemail.com account raa.lkml)
for <raa@localhost> (single-drop); Tue, 15 May 2007 09:21:24 +0200 (CEST)
Received: by 10.100.225.3 with SMTP id x3cs2418606ang;
Tue, 15 May 2007 00:13:44 -0700 (PDT)
Received: by 10.82.177.3 with SMTP id z3mr3288934bue.1179213217602;
Tue, 15 May 2007 00:13:37 -0700 (PDT)
Return-Path: <git-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
by mx.google.com with ESMTP id j2si425607mue.2007.05.15.00.13.05;
Tue, 15 May 2007 00:13:37 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of git-owner@vger.kernel.org designates 209.132.176.167 as permitted sender)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1754566AbXEOHMI (ORCPT <rfc822;peter.baumann@gmail.com>
+ 56 others); Tue, 15 May 2007 03:12:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754600AbXEOHMI
(ORCPT <rfc822;git-outgoing>); Tue, 15 May 2007 03:12:08 -0400
Received: from 66-23-211-5.clients.speedfactory.net ([66.23.211.5]:3083 "EHLO
peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1754566AbXEOHMH (ORCPT <rfc822;git@vger.kernel.org>);
Tue, 15 May 2007 03:12:07 -0400
Received: (qmail 26461 invoked from network); 15 May 2007 07:12:07 -0000
Received: from coredump.intra.peff.net (10.0.0.2)
by peff.net with (DHE-RSA-AES128-SHA encrypted) SMTP; 15 May 2007 07:12:07 -0000
Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Tue, 15 May 2007 03:12:05 -0400
Date: Tue, 15 May 2007 03:12:05 -0400
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
cc: kha@treskal.com, peff@peff.net, bfields@fieldses.org
Subject: testing vger handling of charsets (part 1)
Message-ID: <20070515test.1@coredump.intra.peff.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Status: RO
Content-Length: 614
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Junio C Hamano @ 2007-05-15 18:42 UTC (permalink / raw)
To: Jeff King; +Cc: J. Bruce Fields, Karl Hasselström, git
In-Reply-To: <20070515153513.GA26944@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:
>
>> ... Yes. But actually, the Content-Type header is from
>> git-format-patch:
>>
>> $ git format-patch --stdout 12806b^..12806b |head
>> From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
>> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> Date: Thu, 10 May 2007 12:36:15 +0200
>> Subject: [PATCH] Add a birdview-on-the-source-code section to the user
>> manual
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: 8bit
>
> Ah, interesting. I had checked that, but my test didn't produce those
> headers. It seems we only produce them if there are non-ascii characters
> in the commit message (and I just checked with an arbitrary commit).
>
> So really, this (totally untested) one-liner should fix it:
>
> diff --git a/commit.c b/commit.c
> index 922437f..5669c2f 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
> int sz;
> char header[512];
> const char *header_fmt =
> + "MIME-Version: 1.0\n"
> "Content-Type: text/plain; charset=%s\n"
> "Content-Transfer-Encoding: 8bit\n";
> sz = snprintf(header, sizeof(header), header_fmt,
>
>
> Providing that nobody objects to sticking that extra header in
> format-patch's output (but of course only when we actually have
> non-ascii data). It's technically required if we want the output to be a
> valid MIME message, but most things are unlikely to care (except vger's
> apparently picky MTA).
Thanks; I think this is a sane thing to do.
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Junio C Hamano @ 2007-05-15 18:41 UTC (permalink / raw)
To: Jeff King; +Cc: Karl Hasselström, J. Bruce Fields, git
In-Reply-To: <20070515095756.GB18942@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Unfortunately, I don't think we have the encoding information any more
> at that point. We can infer how the patch was generated by looking at
> the git-config, and that should be right 99% of the time (unless the
> patches were generated with a different config, either from another repo
> or before some settings were changed).
>
> Junio, can you confirm my understanding that:
> - if i18n.logOutputEncoding is set, then we are definitely in that
> encoding
> - otherwise, if i18n.commitEncoding is set, we should assume commits are
> in that encoding (which is just a guess, since they may have been
> generated on another config, but it's our best guess)
> - otherwise, assume utf-8
I do not want to break projects whose members consistently use a
single non UTF-8 encoding, and I've been hoping that in such a
use case they should not have to set any of these encoding
configuration. So in that sense I would be somewhat reluctant
to agree with the last one. But I am getting a feeling that it
is a losing battle.
On the patch acceptance side, when we do _not_ have encoding
information and the input does not look like a valid UTF-8, we
assume that the input is latin-1 and convert it to UTF-8, if I
recall correctly. If somebody sent you a patch without encoding
header, and then you are forwarding that patch, not adding
anything ourselves (because we do not know) and let the
receiving end to do that conversion is certainly the best; but
if we _were_ to add anything I would suspect it would be a
better idea to use the same logic to default to latin-1 or
UTF-8. East Asian users may want to raise objections here.
I think it is a reasonable compromise to do it the way you
outlined. Doing it at patch generation time would fix the
ambiguity issues during the step 2, so it might turn out to be
necessary to add the encoding header to format-patch output
after all, but send-email needs to be able to handle messages
that do not have the header anyway, so probably the first step
is to do so in send-email.
When we update format-patch, the ambiguity at step 2 would
disappear. My gut feeling is that adding an extra header to
format-patch output would not break people's workflow nor
scripts (I do not think it would break mine, as I either suck in
only the body of the message to my MUA or use send-email), but I
am not sure.
> Also Junio, it looks like commit 7cbcf4d5 moved parsing of the
> --encoding parameter into setup_revisions, but it's still being checked
> for in cmd_log_init. Can you confirm that the latter is now superfluous
> and can be removed?
Thanks for noticing, and I think you are right. The code parses
the same input and sets the same global variable the same way.
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-15 18:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0705150856n771cb696h6e8225a0bbd5d43d@mail.gmail.com>
On 2007-05-15 16:56:33 +0100, Catalin Marinas wrote:
> On 06/05/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > The name of the current patch, if any, is always the last line of
> > patches/<branch>/applied (and there is no current patch if and
> > only if the "applied" file is empty). So use that instead, and
> > stop having to worry about keeping the redundant "current" file
> > up-to-date.
>
> I applied this patch. Could you also send me a patch for the
> bash-completion script as it uses this file?
I realized this myself yesterday or so, and patched it to not need the
current, applied, and unapplied files. Are you OK with that patch, or
would you like one that keeps using {,un}applied?
> I think the self.__current_file (same for the base file removed in a
> different patch) should still be available in the Series object and
> removed when deleting a branch, otherwise you get a "Series
> directory ... is not empty" exception.
Ah, very true. I'll whip up a fix.
Same question there: are you OK with a single fix for base, current,
applied, and unapplied, or do you want them separate?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: Jan Hudec @ 2007-05-15 18:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, kha, bfields
In-Reply-To: <20070515test.1@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Tue, May 15, 2007 at 03:12:05 -0400, Jeff King wrote:
> This is a test message to check how vger reacts to seeing 8bit
> characters (like Hasselström) in a message without the right mime
> header. Previous attempts were eaten by the list because of a lack of a
> message id.
>
> If your mail server doesn't advertise the 8BITMIME extensions, I expect
> this message to be corrupted to iso8859-1 during the smtp conversation
> between vger and your server, because it lacks a mime version header.
To me it arrived via vger only, including the ö, with
Content-Type: text/plain; charset=utf-8
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ANNOUNCE] Guilt v0.25
From: Josef Sipek @ 2007-05-15 17:58 UTC (permalink / raw)
To: guilt; +Cc: git, linux-kernel, brandon
Guilt v0.25 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
Really the only major changes are the new commands: import and rebase.
guilt-import allows one to import a patch into the Guilt series easily
guilt-rebase is very similar to git-rebase - it detects patches that were
pushed upstream. NOTE: This command is still not perfect, so use it with
caution.
As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.
------------
Changes since v0.24:
Josef 'Jeff' Sipek (13):
Docs: Fixed two small typos
import: import a patch command
import: Added -P to specify a name of the patch file within guilt
new: Add an empty line after the message/signed-off-by
guilt: be more careful when parsing hash ranges
patchbomb: Added --in-reply-to argument
rebase: Rebase pushed patches against an upstream branch
docs: Skeleton of the rebase docs
rebase: removed some leftover bits from git-cherry
rebase: comment out patch instead of removing it
rebase: created a helper function to pop all patches
Fixed $PAGER detection logic
Guilt v0.25
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-15 16:50 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Karl Hasselström, git
In-Reply-To: <200705151821.08568.kumbayo84@arcor.de>
On 15/05/07, Peter Oberndorfer <kumbayo84@arcor.de> wrote:
> this is a bit OT,
> but when i wanted to try out this changes i found that 2 unrelated patches in you repo[1] are empty.
> * Store branch description in the config file
> * Make the "name" argument to "stg new" optional
Thanks for pointing out. They failed to apply cleanly last night and
forgot to delete the empty patches created. I fixed the conflicts and
added them today (I'll push them tonight).
--
Catalin
^ permalink raw reply
* [PATCH] git name-rev writes beyond the end of malloc() with large generations
From: Andy Whitcroft @ 2007-05-15 16:33 UTC (permalink / raw)
To: git
When using git name-rev on my kernel tree I triggered a malloc()
corruption warning from glibc.
apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
*** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
Aborted
This comes from name_rev() which is building the name of the revision
in a malloc'd string, which it sprintf's into:
char *new_name = xmalloc(len + 8);
[...]
sprintf(new_name, "%.*s~%d^%d", len, tip_name,
generation, parent_number);
This allocation is only sufficient if the generation number is
less than 5 digits, in my case generation was 13432. In reality
parent_number can be up to 16 so that also can require two digits,
reducing us to 3 digits before we are at risk of blowing this
allocation.
This patch introduces a decimal_length() which approximates the
number of digits a type may hold, it produces the following:
Type Longest Value Len Est
---- ------------- --- ---
unsigned char 256 3 4
unsigned short 65536 5 6
unsigned long 4294967296 10 11
unsigned long long 18446744073709551616 20 21
char -128 4 4
short -32768 6 6
long -2147483648 11 11
long long -9223372036854775808 20 21
This is then used to size the new_name.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
This patch is against current next. I have confirmed that
at least GCC can optimise this away to a constant.
---
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index c022224..ef16385 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -58,7 +58,10 @@ copy_data:
parents = parents->next, parent_number++) {
if (parent_number > 1) {
int len = strlen(tip_name);
- char *new_name = xmalloc(len + 8);
+ char *new_name = xmalloc(len +
+ 1 + decimal_length(generation) + /* ~<n> */
+ 1 + 2 + /* ^NN */
+ 1);
if (len > 2 && !strcmp(tip_name + len - 2, "^0"))
len -= 2;
diff --git a/git-compat-util.h b/git-compat-util.h
index c08688c..25b8274 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -19,6 +19,9 @@
#define TYPEOF(x)
#endif
+/* Approximation of the length of the decimal representation of this type. */
+#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
+
#define MSB(x, bits) ((x) & TYPEOF(x)(~0ULL << (sizeof(x) * 8 - (bits))))
#if !defined(__APPLE__) && !defined(__FreeBSD__)
^ permalink raw reply related
* Re: [PATCH] Ensure return value from xread() is always stored into an ssize_t
From: Johan Herland @ 2007-05-15 16:21 UTC (permalink / raw)
To: Dana How; +Cc: git, Paolo Teti
In-Reply-To: <56b7f5510705150912x7ab3ac0clcd494d5f4367c314@mail.gmail.com>
On Tuesday 15 May 2007, Dana How wrote:
> Twice you change an int to a size_t (one s).
> [builtin-fetch-tool.c and pkt-line.c .]
> Did you want to do that?
Yes. AFAICS it was appropriate in the given context.
I.e. in both cases the int was used as an positive offset/size, and
although its value was altered by the ssize_t returned from xread(),
the ssize_t was always verified to be >= 0 before being added to the int.
Have fun!
...Johan
> On 5/15/07, Johan Herland <johan@herland.net> wrote:
> > This patch fixes all calls to xread() where the return value is not
> > stored into an ssize_t. The patch should not have any effect whatsoever,
> > other than putting better/more appropriate type names on variables.
> >
> > Signed-off-by: Johan Herland <johan@herland.net>
> > ---
> >
> > Feel free to ignore this patch as it may be argued that it needlessly
> > touches a lot of code, without having much (if any) positive effect
> > at all.
> >
> > builtin-apply.c | 4 ++--
> > builtin-bundle.c | 2 +-
> > builtin-fetch--tool.c | 4 ++--
> > builtin-unpack-objects.c | 2 +-
> > combine-diff.c | 2 +-
> > copy.c | 3 +--
> > diff.c | 2 +-
> > imap-send.c | 2 +-
> > index-pack.c | 2 +-
> > pkt-line.c | 4 ++--
> > sha1_file.c | 2 +-
> > ssh-upload.c | 2 +-
> > 12 files changed, 15 insertions(+), 16 deletions(-)
> >
> > diff --git a/builtin-apply.c b/builtin-apply.c
> > index 8b8705a..0399743 100644
> > --- a/builtin-apply.c
> > +++ b/builtin-apply.c
> > @@ -185,7 +185,7 @@ static void *read_patch_file(int fd, unsigned long *sizep)
> > void *buffer = xmalloc(alloc);
> >
> > for (;;) {
> > - int nr = alloc - size;
> > + ssize_t nr = alloc - size;
> > if (nr < 1024) {
> > alloc += CHUNKSIZE;
> > buffer = xrealloc(buffer, alloc);
> > @@ -1468,7 +1468,7 @@ static int read_old_data(struct stat *st, const char *path, char **buf_p, unsign
> > return error("unable to open %s", path);
> > got = 0;
> > for (;;) {
> > - int ret = xread(fd, buf + got, size - got);
> > + ssize_t ret = xread(fd, buf + got, size - got);
> > if (ret <= 0)
> > break;
> > got += ret;
> > diff --git a/builtin-bundle.c b/builtin-bundle.c
> > index d1635a0..306ad29 100644
> > --- a/builtin-bundle.c
> > +++ b/builtin-bundle.c
> > @@ -48,7 +48,7 @@ static int read_string(int fd, char *buffer, int size)
> > {
> > int i;
> > for (i = 0; i < size - 1; i++) {
> > - int count = xread(fd, buffer + i, 1);
> > + ssize_t count = xread(fd, buffer + i, 1);
> > if (count < 0)
> > return error("Read error: %s", strerror(errno));
> > if (count == 0) {
> > diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
> > index 2065466..12adb38 100644
> > --- a/builtin-fetch--tool.c
> > +++ b/builtin-fetch--tool.c
> > @@ -6,11 +6,11 @@
> >
> > static char *get_stdin(void)
> > {
> > - int offset = 0;
> > + size_t offset = 0;
> > char *data = xmalloc(CHUNK_SIZE);
> >
> > while (1) {
> > - int cnt = xread(0, data + offset, CHUNK_SIZE);
> > + ssize_t cnt = xread(0, data + offset, CHUNK_SIZE);
> > if (cnt < 0)
> > die("error reading standard input: %s",
> > strerror(errno));
> > diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
> > index 2bbda67..a6ff62f 100644
> > --- a/builtin-unpack-objects.c
> > +++ b/builtin-unpack-objects.c
> > @@ -34,7 +34,7 @@ static void *fill(int min)
> > offset = 0;
> > }
> > do {
> > - int ret = xread(0, buffer + len, sizeof(buffer) - len);
> > + ssize_t ret = xread(0, buffer + len, sizeof(buffer) - len);
> > if (ret <= 0) {
> > if (!ret)
> > die("early EOF");
> > diff --git a/combine-diff.c b/combine-diff.c
> > index cff9c5d..ea3ca5f 100644
> > --- a/combine-diff.c
> > +++ b/combine-diff.c
> > @@ -714,7 +714,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
> > result_size = len;
> > result = xmalloc(len + 1);
> > while (sz < len) {
> > - int done = xread(fd, result+sz, len-sz);
> > + ssize_t done = xread(fd, result+sz, len-sz);
> > if (done == 0)
> > break;
> > if (done < 0)
> > diff --git a/copy.c b/copy.c
> > index 08a3d38..d340bb2 100644
> > --- a/copy.c
> > +++ b/copy.c
> > @@ -3,10 +3,9 @@
> > int copy_fd(int ifd, int ofd)
> > {
> > while (1) {
> > - int len;
> > char buffer[8192];
> > char *buf = buffer;
> > - len = xread(ifd, buffer, sizeof(buffer));
> > + ssize_t len = xread(ifd, buffer, sizeof(buffer));
> > if (!len)
> > break;
> > if (len < 0) {
> > diff --git a/diff.c b/diff.c
> > index 8354e71..33297aa 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -1411,7 +1411,7 @@ static int populate_from_stdin(struct diff_filespec *s)
> > #define INCREMENT 1024
> > char *buf;
> > unsigned long size;
> > - int got;
> > + ssize_t got;
> >
> > size = 0;
> > buf = NULL;
> > diff --git a/imap-send.c b/imap-send.c
> > index 84df2fa..4283a4a 100644
> > --- a/imap-send.c
> > +++ b/imap-send.c
> > @@ -224,7 +224,7 @@ socket_perror( const char *func, Socket_t *sock, int ret )
> > static int
> > socket_read( Socket_t *sock, char *buf, int len )
> > {
> > - int n = xread( sock->fd, buf, len );
> > + ssize_t n = xread( sock->fd, buf, len );
> > if (n <= 0) {
> > socket_perror( "read", sock, n );
> > close( sock->fd );
> > diff --git a/index-pack.c b/index-pack.c
> > index b9da19f..58c4a9c 100644
> > --- a/index-pack.c
> > +++ b/index-pack.c
> > @@ -82,7 +82,7 @@ static void *fill(int min)
> > die("cannot fill %d bytes", min);
> > flush();
> > do {
> > - int ret = xread(input_fd, input_buffer + input_len,
> > + ssize_t ret = xread(input_fd, input_buffer + input_len,
> > sizeof(input_buffer) - input_len);
> > if (ret <= 0) {
> > if (!ret)
> > diff --git a/pkt-line.c b/pkt-line.c
> > index b4cb7e2..b605268 100644
> > --- a/pkt-line.c
> > +++ b/pkt-line.c
> > @@ -65,10 +65,10 @@ void packet_write(int fd, const char *fmt, ...)
> >
> > static void safe_read(int fd, void *buffer, unsigned size)
> > {
> > - int n = 0;
> > + size_t n = 0;
> >
> > while (n < size) {
> > - int ret = xread(fd, (char *) buffer + n, size - n);
> > + ssize_t ret = xread(fd, (char *) buffer + n, size - n);
> > if (ret < 0)
> > die("read error (%s)", strerror(errno));
> > if (!ret)
> > diff --git a/sha1_file.c b/sha1_file.c
> > index 32244d7..be991ed 100644
> > --- a/sha1_file.c
> > +++ b/sha1_file.c
> > @@ -2276,7 +2276,7 @@ int read_pipe(int fd, char** return_buf, unsigned long* return_size)
> > {
> > char* buf = *return_buf;
> > unsigned long size = *return_size;
> > - int iret;
> > + ssize_t iret;
> > unsigned long off = 0;
> >
> > do {
> > diff --git a/ssh-upload.c b/ssh-upload.c
> > index 2f04572..498d41e 100644
> > --- a/ssh-upload.c
> > +++ b/ssh-upload.c
> > @@ -86,7 +86,7 @@ static int serve_ref(int fd_in, int fd_out)
> >
> > static void service(int fd_in, int fd_out) {
> > char type;
> > - int retval;
> > + ssize_t retval;
> > do {
> > retval = xread(fd_in, &type, 1);
> > if (retval < 1) {
> > --
> > 1.5.1.4
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Peter Oberndorfer @ 2007-05-15 16:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0705150856n771cb696h6e8225a0bbd5d43d@mail.gmail.com>
On Tuesday 15 May 2007 17:56, Catalin Marinas wrote:
> On 06/05/07, Karl Hasselström <kha@treskal.com> wrote:
> > The name of the current patch, if any, is always the last line of
> > patches/<branch>/applied (and there is no current patch if and only if
> > the "applied" file is empty). So use that instead, and stop having to
> > worry about keeping the redundant "current" file up-to-date.
>
> I applied this patch. Could you also send me a patch for the
> bash-completion script as it uses this file?
>
> I think the self.__current_file (same for the base file removed in a
> different patch) should still be available in the Series object and
> removed when deleting a branch, otherwise you get a "Series directory
> ... is not empty" exception.
>
> Thanks.
>
Hi,
this is a bit OT,
but when i wanted to try out this changes i found that 2 unrelated patches in you repo[1] are empty.
* Store branch description in the config file
* Make the "name" argument to "stg new" optional
Is that a problem on my side, or are they really empty?
Greetings Peter
[1] http://homepage.ntlworld.com/cmarinas/stgit.git
which is mirrored at
http://repo.or.cz/w/stgit.git
^ permalink raw reply
* Re: [PATCH] Ensure return value from xread() is always stored into an ssize_t
From: Dana How @ 2007-05-15 16:12 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Paolo Teti, danahow
In-Reply-To: <200705151449.22744.johan@herland.net>
Twice you change an int to a size_t (one s).
[builtin-fetch-tool.c and pkt-line.c .]
Did you want to do that?
On 5/15/07, Johan Herland <johan@herland.net> wrote:
> This patch fixes all calls to xread() where the return value is not
> stored into an ssize_t. The patch should not have any effect whatsoever,
> other than putting better/more appropriate type names on variables.
>
> Signed-off-by: Johan Herland <johan@herland.net>
> ---
>
> Feel free to ignore this patch as it may be argued that it needlessly
> touches a lot of code, without having much (if any) positive effect
> at all.
>
> builtin-apply.c | 4 ++--
> builtin-bundle.c | 2 +-
> builtin-fetch--tool.c | 4 ++--
> builtin-unpack-objects.c | 2 +-
> combine-diff.c | 2 +-
> copy.c | 3 +--
> diff.c | 2 +-
> imap-send.c | 2 +-
> index-pack.c | 2 +-
> pkt-line.c | 4 ++--
> sha1_file.c | 2 +-
> ssh-upload.c | 2 +-
> 12 files changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 8b8705a..0399743 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -185,7 +185,7 @@ static void *read_patch_file(int fd, unsigned long *sizep)
> void *buffer = xmalloc(alloc);
>
> for (;;) {
> - int nr = alloc - size;
> + ssize_t nr = alloc - size;
> if (nr < 1024) {
> alloc += CHUNKSIZE;
> buffer = xrealloc(buffer, alloc);
> @@ -1468,7 +1468,7 @@ static int read_old_data(struct stat *st, const char *path, char **buf_p, unsign
> return error("unable to open %s", path);
> got = 0;
> for (;;) {
> - int ret = xread(fd, buf + got, size - got);
> + ssize_t ret = xread(fd, buf + got, size - got);
> if (ret <= 0)
> break;
> got += ret;
> diff --git a/builtin-bundle.c b/builtin-bundle.c
> index d1635a0..306ad29 100644
> --- a/builtin-bundle.c
> +++ b/builtin-bundle.c
> @@ -48,7 +48,7 @@ static int read_string(int fd, char *buffer, int size)
> {
> int i;
> for (i = 0; i < size - 1; i++) {
> - int count = xread(fd, buffer + i, 1);
> + ssize_t count = xread(fd, buffer + i, 1);
> if (count < 0)
> return error("Read error: %s", strerror(errno));
> if (count == 0) {
> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
> index 2065466..12adb38 100644
> --- a/builtin-fetch--tool.c
> +++ b/builtin-fetch--tool.c
> @@ -6,11 +6,11 @@
>
> static char *get_stdin(void)
> {
> - int offset = 0;
> + size_t offset = 0;
> char *data = xmalloc(CHUNK_SIZE);
>
> while (1) {
> - int cnt = xread(0, data + offset, CHUNK_SIZE);
> + ssize_t cnt = xread(0, data + offset, CHUNK_SIZE);
> if (cnt < 0)
> die("error reading standard input: %s",
> strerror(errno));
> diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
> index 2bbda67..a6ff62f 100644
> --- a/builtin-unpack-objects.c
> +++ b/builtin-unpack-objects.c
> @@ -34,7 +34,7 @@ static void *fill(int min)
> offset = 0;
> }
> do {
> - int ret = xread(0, buffer + len, sizeof(buffer) - len);
> + ssize_t ret = xread(0, buffer + len, sizeof(buffer) - len);
> if (ret <= 0) {
> if (!ret)
> die("early EOF");
> diff --git a/combine-diff.c b/combine-diff.c
> index cff9c5d..ea3ca5f 100644
> --- a/combine-diff.c
> +++ b/combine-diff.c
> @@ -714,7 +714,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
> result_size = len;
> result = xmalloc(len + 1);
> while (sz < len) {
> - int done = xread(fd, result+sz, len-sz);
> + ssize_t done = xread(fd, result+sz, len-sz);
> if (done == 0)
> break;
> if (done < 0)
> diff --git a/copy.c b/copy.c
> index 08a3d38..d340bb2 100644
> --- a/copy.c
> +++ b/copy.c
> @@ -3,10 +3,9 @@
> int copy_fd(int ifd, int ofd)
> {
> while (1) {
> - int len;
> char buffer[8192];
> char *buf = buffer;
> - len = xread(ifd, buffer, sizeof(buffer));
> + ssize_t len = xread(ifd, buffer, sizeof(buffer));
> if (!len)
> break;
> if (len < 0) {
> diff --git a/diff.c b/diff.c
> index 8354e71..33297aa 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1411,7 +1411,7 @@ static int populate_from_stdin(struct diff_filespec *s)
> #define INCREMENT 1024
> char *buf;
> unsigned long size;
> - int got;
> + ssize_t got;
>
> size = 0;
> buf = NULL;
> diff --git a/imap-send.c b/imap-send.c
> index 84df2fa..4283a4a 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -224,7 +224,7 @@ socket_perror( const char *func, Socket_t *sock, int ret )
> static int
> socket_read( Socket_t *sock, char *buf, int len )
> {
> - int n = xread( sock->fd, buf, len );
> + ssize_t n = xread( sock->fd, buf, len );
> if (n <= 0) {
> socket_perror( "read", sock, n );
> close( sock->fd );
> diff --git a/index-pack.c b/index-pack.c
> index b9da19f..58c4a9c 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -82,7 +82,7 @@ static void *fill(int min)
> die("cannot fill %d bytes", min);
> flush();
> do {
> - int ret = xread(input_fd, input_buffer + input_len,
> + ssize_t ret = xread(input_fd, input_buffer + input_len,
> sizeof(input_buffer) - input_len);
> if (ret <= 0) {
> if (!ret)
> diff --git a/pkt-line.c b/pkt-line.c
> index b4cb7e2..b605268 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -65,10 +65,10 @@ void packet_write(int fd, const char *fmt, ...)
>
> static void safe_read(int fd, void *buffer, unsigned size)
> {
> - int n = 0;
> + size_t n = 0;
>
> while (n < size) {
> - int ret = xread(fd, (char *) buffer + n, size - n);
> + ssize_t ret = xread(fd, (char *) buffer + n, size - n);
> if (ret < 0)
> die("read error (%s)", strerror(errno));
> if (!ret)
> diff --git a/sha1_file.c b/sha1_file.c
> index 32244d7..be991ed 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2276,7 +2276,7 @@ int read_pipe(int fd, char** return_buf, unsigned long* return_size)
> {
> char* buf = *return_buf;
> unsigned long size = *return_size;
> - int iret;
> + ssize_t iret;
> unsigned long off = 0;
>
> do {
> diff --git a/ssh-upload.c b/ssh-upload.c
> index 2f04572..498d41e 100644
> --- a/ssh-upload.c
> +++ b/ssh-upload.c
> @@ -86,7 +86,7 @@ static int serve_ref(int fd_in, int fd_out)
>
> static void service(int fd_in, int fd_out) {
> char type;
> - int retval;
> + ssize_t retval;
> do {
> retval = xread(fd_in, &type, 1);
> if (retval < 1) {
> --
> 1.5.1.4
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-15 15:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070506150852.8985.98091.stgit@yoghurt>
On 06/05/07, Karl Hasselström <kha@treskal.com> wrote:
> The name of the current patch, if any, is always the last line of
> patches/<branch>/applied (and there is no current patch if and only if
> the "applied" file is empty). So use that instead, and stop having to
> worry about keeping the redundant "current" file up-to-date.
I applied this patch. Could you also send me a patch for the
bash-completion script as it uses this file?
I think the self.__current_file (same for the base file removed in a
different patch) should still be available in the Series object and
removed when deleting a branch, otherwise you get a "Series directory
... is not empty" exception.
Thanks.
--
Catalin
^ permalink raw reply
* Re: suggestions for gitweb
From: Jan Hudec @ 2007-05-15 15:46 UTC (permalink / raw)
To: Michael Niedermayer; +Cc: Petr Baudis, Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20070514020001.GX14859@MichaelsNB>
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
Hello,
On Mon, May 14, 2007 at 04:00:02 +0200, Michael Niedermayer wrote:
> On Mon, May 14, 2007 at 03:08:31AM +0200, Petr Baudis wrote:
> > But, even if that's the case, when a new user meets gitweb and looks
> > at the 'history' link, what do you think she will do? Start hunting the
> > page for some link to a glossary? I yet have to see a user like that :-)
> > - I will bet that she just clicks at the link and figures out what it is
> > about based on what happenned.
>
> i agree with you that she will click on 'history' and figure out what it is
> but if she wants to see the contents of one of the files then i think
Well, before clicking it, she will move the mouse pointer over it. And either
look for tooltip -- which sadly won't come up -- or read the url -- with
sadly isn't much help.
> she will be confused and not know where to click, and a 'help' link which
> would lead to a page which explains what 'blob' is at the top of the page
> would solve that with less frustration than random clicking around
IMHO providing tooltips would probably solve it with even less frustration.
If the user comes to the page, she will probably quickly notice, that the
links have tooltips. And than going over all the links with the pointer and
reading the tooltips is a lot easier and faster than switching to a help
page. Besides people don't want to admit, even to themselves, they don't
understand something to a point they should read the docs, so they won't read
it. But anybody will read the tooltips -- they don't look like docs.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [StGIT RFC PATCH] Activate rename detection by default.
From: Catalin Marinas @ 2007-05-15 15:41 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070504235413.29479.13640.stgit@gandelf.nowhere.earth>
On 05/05/07, Yann Dirson <ydirson@altern.org> wrote:
> This patch uses -M when generating diffs, which then looks fine, just
> like any other git-generated diff.
I think we should only use -M for "files", "status", "show", "diff"
but not for "export" and "mail", maybe by adding an extra parameter to
git.diff() (or we could have this configurable or with an cmd line
option). The reason is that I send patches that might not be applied
with GIT.
--
Catalin
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeff King @ 2007-05-15 15:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Karl Hasselström, Junio C Hamano, git
In-Reply-To: <20070515152457.GC6794@fieldses.org>
On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:
> ... Yes. But actually, the Content-Type header is from
> git-format-patch:
>
> $ git format-patch --stdout 12806b^..12806b |head
> From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Thu, 10 May 2007 12:36:15 +0200
> Subject: [PATCH] Add a birdview-on-the-source-code section to the user
> manual
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
Ah, interesting. I had checked that, but my test didn't produce those
headers. It seems we only produce them if there are non-ascii characters
in the commit message (and I just checked with an arbitrary commit).
So really, this (totally untested) one-liner should fix it:
diff --git a/commit.c b/commit.c
index 922437f..5669c2f 100644
--- a/commit.c
+++ b/commit.c
@@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
int sz;
char header[512];
const char *header_fmt =
+ "MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=%s\n"
"Content-Transfer-Encoding: 8bit\n";
sz = snprintf(header, sizeof(header), header_fmt,
Providing that nobody objects to sticking that extra header in
format-patch's output (but of course only when we actually have
non-ascii data). It's technically required if we want the output to be a
valid MIME message, but most things are unlikely to care (except vger's
apparently picky MTA).
-Peff
^ permalink raw reply related
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Jan Hudec @ 2007-05-15 15:09 UTC (permalink / raw)
To: David Kågedal; +Cc: git, Jakub Narebski
In-Reply-To: <87odkmgaj5.fsf@morpheus.local>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On Mon, May 14, 2007 at 18:06:54 -0700, David Kågedal wrote:
> Unfortunately, the problem is that too many web sites explicitly
> select extra small font sizes, which means that you have to select a
> "standard" font size in your browser that is a bit larger than you'd
> actually like.
IMHO gitweb should explicitely request being somewhat smaller than normal,
because it has good use for long lines. Normally I want to set font so large,
that more than ~120 characters won't fit on the screen, since otherwise pages
that don't use margins are simply unreadable. However gitweb presents a table
with several columns, so having wider line is OK for it. Therefore explicit
'font-size: small' would make sense.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-15 15:24 UTC (permalink / raw)
To: Jeff King; +Cc: Karl Hasselström, git
In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net>
On Tue, May 15, 2007 at 01:08:08AM -0400, Jeff King wrote:
> However, the content-type is already specified, so it shouldn't need to
> rewrite. However, I notice that your original message is missing a
> MIME-Version: 1.0 header. My guess is that vger's logic is that without
> that header, it can't trust the Content-Type you have provided (and
> indeed, not including MIME-Version violates the MIME RFCs, I believe).
>
> I assumed this was a bug in git-send-email, but looking closer, it
> doesn't put in any mime information at all! So your sending smtp server
> is adding in the content-type header,
Nope...
> but it's failing to add the
> MIME-Version header, which I think is a bug (I can dig up the RFC
> reference if you want).
>
> Arguably, git should be generating the full MIME header-set, since it
> knows what actual encoding the message is in.
... Yes. But actually, the Content-Type header is from
git-format-patch:
$ git format-patch --stdout 12806b^..12806b |head
From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Thu, 10 May 2007 12:36:15 +0200
Subject: [PATCH] Add a birdview-on-the-source-code section to the user
manual
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
So it's a git-format-patch bug?
--b.
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: J. Bruce Fields @ 2007-05-15 14:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jeff King, git
In-Reply-To: <20070515083148.GD9096@diana.vm.bytemark.co.uk>
On Tue, May 15, 2007 at 10:31:48AM +0200, Karl Hasselström wrote:
> On 2007-05-15 03:13:40 -0400, Jeff King wrote:
>
> > This is a test message to check how vger reacts to seeing 8bit
> > characters (like Hasselström) in a message _with_ the right mime
> > header.
>
> Looks OK both in the copy I got directly, and in the copy I got via
> the list.
Yup, same here.
--b.
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: J. Bruce Fields @ 2007-05-15 14:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jeff King, git
In-Reply-To: <20070515083235.GE9096@diana.vm.bytemark.co.uk>
On Tue, May 15, 2007 at 10:32:35AM +0200, Karl Hasselström wrote:
> On 2007-05-15 03:12:05 -0400, Jeff King wrote:
>
> > This is a test message to check how vger reacts to seeing 8bit
> > characters (like Hasselström) in a message without the right mime
> > header. Previous attempts were eaten by the list because of a lack
> > of a message id.
>
> This was broken when I got it via the list, but looked good when I got
> it directly.
Ditto here. And the copy from the list had the same big warning as
before in the headers.
--b.
^ permalink raw reply
* Re: [PATCH 05/10] Documentation: remove howto's now incorporated into manual
From: J. Bruce Fields @ 2007-05-15 14:48 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, git
In-Reply-To: <8aa486160705150305w5265a5d5w82cfaee49ff4e8b1@mail.gmail.com>
On Tue, May 15, 2007 at 12:05:07PM +0200, Santi Béjar wrote:
> What about the core-tutorial.txt? It is also included in the Git User
> Manual. We could backport the changes and actually do an
> include::core-tutorial.txt[] in the user-manual.txt.
Sure.
Actually, there's at least three documents with some overlap:
- the core tutorial
- tutorial-2.txt
- the "DISCUSSION" section of git.7, also chapter 8 of the user
manual, also previously the README.
I'd eventually like to get those down to just one or two.
Updating the core-tutorial and figuring out how to work it into the
manual might be a good first step.
--b.
^ permalink raw reply
* Re: Suggestions for cgit (was: Re: suggestions for gitweb)
From: Lars Hjemli @ 2007-05-15 12:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8c5c35580705140150i85ef898h6ac0475ab12f8a03@mail.gmail.com>
On 5/14/07, Lars Hjemli <hjemli@gmail.com> wrote:
> On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:
> >
> > > I've implemented number of files/lines changed in cgit's log view and
> > > pushed it to http://hjemli.net/git/
> > >
> > > It does consume some cpu (especially on the linux-2.6 repo), but it's
> > > not terribly bad (and the caching helps out). But I felt like changing
> > > the number of commits per page to 50, so I added a knob for this in
> > > the config file while at it.
> > >
> > > I'll try to get a proper diffstat on the commit page + file history
> > > via tree view next (filesize has always been part of cgits tree view
> > > btw).
> >
> > What I lack in cgit is using git diff and showing extended diff headers
> > (and the ugly tight box around diff doesn't help either), and gitweb's
> > 'commitdiff' view / git's git-show / git's git-format-patch.
>
> Yes, this has been lacking. Last night I pushed initial support for
> 'commitdiff', but it doesn't show git's extended diff headers, nor is
> there any plain/patch view (but the ugly tiny box is still there, I'm
> lousy at web design :)
>
> That said, extended headers/patch view should be trivial to support so
> I'll look into it.
Ok, the ugly box is gone and 'commit-diff' now looks more like 'git
show'. Thanks for the suggestion.
--
larsh
^ 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