* 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
* [PATCH] Ensure return value from xread() is always stored into an ssize_t
From: Johan Herland @ 2007-05-15 12:49 UTC (permalink / raw)
To: git; +Cc: Paolo Teti
In-Reply-To: <200705151439.25871.johan@herland.net>
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
^ permalink raw reply related
* Re: [PATCH] Fix signedness on return value from xread()
From: Paolo Teti @ 2007-05-15 12:48 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705151439.25871.johan@herland.net>
2007/5/15, Johan Herland <johan@herland.net>:
> Using this as an opportunity to get used to sending patches... :)
>
> Is this what you were looking for, Paolo?
>
Yes Johan your patch fixes the bug.
Thanks
^ permalink raw reply
* [PATCH] Fix signedness on return value from xread()
From: Johan Herland @ 2007-05-15 12:39 UTC (permalink / raw)
To: git; +Cc: Paolo Teti
In-Reply-To: <34a7ae040705150447k2e770b5ag3629632f61b813a0@mail.gmail.com>
The return value from xread() is ssize_t.
Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the
signed return value was assigned to an unsigned type (size_t). This patch
fixes that.
Signed-off-by: Johan Herland <johan@herland.net>
---
Using this as an opportunity to get used to sending patches... :)
Is this what you were looking for, Paolo?
pack-write.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/pack-write.c b/pack-write.c
index de72f44..ae2e481 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -25,7 +25,7 @@ void fixup_pack_header_footer(int pack_fd,
buf = xmalloc(buf_sz);
for (;;) {
- size_t n = xread(pack_fd, buf, buf_sz);
+ ssize_t n = xread(pack_fd, buf, buf_sz);
if (!n)
break;
if (n < 0)
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] git-am: Clean up the asciidoc documentation
From: Frank Lichtenheld @ 2007-05-15 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd513lztp.fsf@assigned-by-dhcp.cox.net>
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.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* BUG in fixup_pack_header_footer(...) / pack-write.c checksum error never raised
From: Paolo Teti @ 2007-05-15 11:47 UTC (permalink / raw)
To: git
In fixup_pack_header_footer(...) file pack-write.c
We have to change the size_t value returned by
xread() in ssize_t, otherwise the next check on negative
values has no sense.
size_t is an unsigned type!
I can't write now a patch because I'm on a customer site
and I can't install GIT...
I'm just looking at the souce code using gitweb during a coffebreak.
Someone can fix it?..
Pao
^ permalink raw reply
* Re: newby question about merge.
From: picca @ 2007-05-15 11:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f2c23k$dm0$1@sea.gmane.org>
On Tue, 15 May 2007 12:34:55 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: picca <picca@synchrotron-soleil.Fr>, git@vger.kernel.org]
>
> picca wrote:
>
> > My question is how can I keep the upstream version of the configure
> > file instread of the one in the working directory.
> >
> > I read about the stage(1:2:3) but I do not know how if it is
> > related to my problem.
>
> You can just do "git cat-file -p :2:filename > filename", then
> "git add filename" (or "git update-index filename") to resolve
> conflict.
>
> Check first if :2: is correct file (and not for example :3:).
In fact the right file was the :3: one.
Thank you very much.
Is it possible to add this git cat-file -p :2:filename > filename in
the man page of git-merge in the resolve conflict part ?
Or a link to the documentation speaking of this stage part.
Thanks
Frédéric
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-15 10:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v8xbqlb68.fsf@assigned-by-dhcp.cox.net>
On Tuesday 2007 May 15, Junio C Hamano wrote:
> Actually, Documentation is the least offence. I wanted to have
> somebody sanity-check the change to count_ident().
Blimey. It's a good job you're awake. I'm ashamed of myself for missing
that. Apologies again. You should have just prodded me - I'm always happy
to fix my mistakes; I certainly don't expect you to have to apply patches and
fix them as well.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: newby question about merge.
From: Jakub Narebski @ 2007-05-15 10:34 UTC (permalink / raw)
To: git
In-Reply-To: <20070515113820.2621c8d5@localhost.localdomain>
[Cc: picca <picca@synchrotron-soleil.Fr>, git@vger.kernel.org]
picca wrote:
> My question is how can I keep the upstream version of the configure
> file instread of the one in the working directory.
>
> I read about the stage(1:2:3) but I do not know how if it is related to
> my problem.
You can just do "git cat-file -p :2:filename > filename", then
"git add filename" (or "git update-index filename") to resolve conflict.
Check first if :2: is correct file (and not for example :3:).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: newby question about merge.
From: Alex Riesen @ 2007-05-15 10:25 UTC (permalink / raw)
To: picca; +Cc: git
In-Reply-To: <20070515113820.2621c8d5@localhost.localdomain>
picca, Tue, May 15, 2007 11:38:20 +0200:
> So I do a merge like this
> "git merge upstream ." when I am on the master branch to work on the new
> package.
loose the dot. git-merge syntax is "git merge branch1 [branch2...]"
^ permalink raw reply
* [PATCH] Add an option to git-ls-tree to display also the size of object
From: Jakub Narebski @ 2007-05-15 10:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
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).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is to be used in 'tree' view in gitweb, controlled by the
%feature hash.
Documentation/git-ls-tree.txt | 14 +++++++++++++-
builtin-ls-tree.c | 34 ++++++++++++++++++++++++++--------
2 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 7899394..367f9bb 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object
SYNOPSIS
--------
[verse]
-'git-ls-tree' [-d] [-r] [-t] [-z]
+'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
[--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
<tree-ish> [paths...]
@@ -36,6 +36,11 @@ OPTIONS
Show tree entries even when going to recurse them. Has no effect
if '-r' was not passed. '-d' implies '-t'.
+-l::
+--long::
+--size::
+ Show object size of entries.
+
-z::
\0 line termination on output.
@@ -65,6 +70,13 @@ Output Format
When the `-z` option is not used, TAB, LF, and backslash characters
in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
+When the `-l` option is used, format changes to
+
+ <mode> SP <type> SP <object> SP <object size> TAB <file>
+
+Object size identified by <objest> is given in bytes, and left-justified
+with minimum width of 7 characters.
+
Author
------
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 1cb4dca..0c2eef7 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -15,6 +15,7 @@ static int line_termination = '\n';
#define LS_TREE_ONLY 2
#define LS_SHOW_TREES 4
#define LS_NAME_ONLY 8
+#define LS_SHOW_SIZE 16
static int abbrev;
static int ls_options;
static const char **pathspec;
@@ -22,7 +23,7 @@ static int chomp_prefix;
static const char *ls_tree_prefix;
static const char ls_tree_usage[] =
- "git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
+ "git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -55,10 +56,11 @@ static int show_recursive(const char *base, int baselen, const char *pathname)
}
static int show_tree(const unsigned char *sha1, const char *base, int baselen,
- const char *pathname, unsigned mode, int stage)
+ const char *pathname, unsigned mode, int stage)
{
int retval = 0;
const char *type = blob_type;
+ unsigned long size;
if (S_ISDIRLNK(mode)) {
/*
@@ -92,13 +94,21 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
(baselen < chomp_prefix || memcmp(ls_tree_prefix, base, chomp_prefix)))
return 0;
- if (!(ls_options & LS_NAME_ONLY))
- printf("%06o %s %s\t", mode, type,
- abbrev ? find_unique_abbrev(sha1,abbrev)
- : sha1_to_hex(sha1));
+ if (!(ls_options & LS_NAME_ONLY)) {
+ if (ls_options & LS_SHOW_SIZE) {
+ sha1_object_info(sha1, &size);
+ printf("%06o %s %s %7lu\t", mode, type,
+ abbrev ? find_unique_abbrev(sha1, abbrev)
+ : sha1_to_hex(sha1),
+ size);
+ } else
+ printf("%06o %s %s\t", mode, type,
+ abbrev ? find_unique_abbrev(sha1, abbrev)
+ : sha1_to_hex(sha1));
+ }
write_name_quoted(base + chomp_prefix, baselen - chomp_prefix,
- pathname,
- line_termination, stdout);
+ pathname,
+ line_termination, stdout);
putchar(line_termination);
return retval;
}
@@ -126,12 +136,20 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
case 't':
ls_options |= LS_SHOW_TREES;
break;
+ case 'l':
+ ls_options |= LS_SHOW_SIZE;
+ break;
case '-':
if (!strcmp(argv[1]+2, "name-only") ||
!strcmp(argv[1]+2, "name-status")) {
ls_options |= LS_NAME_ONLY;
break;
}
+ if (!strcmp(argv[1]+2, "long") ||
+ !strcmp(argv[1]+2, "size")) {
+ ls_options |= LS_SHOW_SIZE;
+ break;
+ }
if (!strcmp(argv[1]+2, "full-name")) {
chomp_prefix = 0;
break;
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH 05/10] Documentation: remove howto's now incorporated into manual
From: Santi Béjar @ 2007-05-15 10:05 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <-7504805328344940638@unknownmsgid>
On 5/14/07, J. Bruce Fields <bfields@citi.umich.edu> wrote:
> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> These two howto's have both been copied into the manual. I'd rather not
> maintain both versions if possible, and I think the user-manual will be
> more visible than the howto directory. (Though I wouldn't mind some
> duplication if people really like having them here.)
+1
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.
Santi
^ permalink raw reply
* newby question about merge.
From: picca @ 2007-05-15 9:38 UTC (permalink / raw)
To: git
Hello I am using git to deal with debian packages.
So i have two Branches the "upstream" one with the different version of
the programm I am packaging.
exemple with two tags
scigraphica/2.1.0
scigraphica/0.8.0
I have another branch the master one which is the upstream + the debian
directory.
So I do a merge like this
"git merge upstream ." when I am on the master branch to work on the new
package.
Everything is fine until git merge the configure scripts. (autotools)
there is conflict with the configure file of the 0.8.0 version during
the last merge.
My question is how can I keep the upstream version of the configure
file instread of the one in the working directory.
I read about the stage(1:2:3) but I do not know how if it is related to
my problem.
Thanks in advance.
Frédéric
^ 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 9:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, J. Bruce Fields, git
In-Reply-To: <7v3b1ylb48.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 01:55:19AM -0700, Junio C Hamano wrote:
> >> Arguably, git should be generating the full MIME header-set, since
> >> it knows what actual encoding the message is in.
> > I very much agree.
> If the above statement meand git-send-email by "git" I would
> very much agree.
OK, the lack of a MIME-Version is clearly the problem, based on Karl's
view of the messages I sent. I agree that git-send-email is the right
place to implement this (though the weird partial mime headers are
actually an artifact of Bruce's MTA).
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
If that is OK, I will work up a patch.
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?
-Peff
^ 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 8:55 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jeff King, J. Bruce Fields, git
In-Reply-To: <20070515082407.GA9096@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-05-15 01:08:08 -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).
>
> You know, this rings a bell. I've discovered that a "MIME-Version:
> 1.0" is needed before. :-)
>
> "stg mail" used to have the same problem, until it was changed to use
> the Python e-mail libraries for all that stuff. And since then I
> haven't had problems with it.
>
>> 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, 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.
>
> I very much agree.
If the above statement meand git-send-email by "git" I would
very much agree.
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Junio C Hamano @ 2007-05-15 8:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705150914.44641.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Tuesday 2007 May 15, Junio C Hamano wrote:
>
>> I think this on top of your patch would be the minimum necessary
>> for v1.5.2.
>
> Oops. I think I'm going to mail you a big bat with
> "Documentation" carved into it that you can use for smacking
> us (me), for submitting patches without documentation.
Actually, Documentation is the least offence. I wanted to have
somebody sanity-check the change to count_ident().
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: Karl Hasselström @ 2007-05-15 8:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, bfields
In-Reply-To: <20070515test.1@coredump.intra.peff.net>
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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: Karl Hasselström @ 2007-05-15 8:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, bfields
In-Reply-To: <20070515test.2@coredump.intra.peff.net>
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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Karl Hasselström @ 2007-05-15 8:29 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87wszagayt.fsf@morpheus.local>
On 2007-05-14 17:57:30 -0700, David Kågedal wrote:
> And it's broken as well. If you "update" in the emacs mode you
> cannot do a "git commit" in a terminal without manually running "git
> update-index" first.
>
> I think an emacs-mode that is closer to git-gui would be better, and
> closer to the git philosophy
I agree. (But for the record, I find the existing Emacs mode
tremendously useful too. It's just that in some circumstances, you can
get confused if you don't know what you're doing.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: Karl Hasselström @ 2007-05-15 8:25 UTC (permalink / raw)
To: Jeff King; +Cc: bfields, git
In-Reply-To: <200705150630.l4F6UHkN014772@mail1.space2u.com>
On 2007-05-15 02:30:15 -0400, Jeff King wrote:
> The offending test data is: Hasselström
:-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-15 8:24 UTC (permalink / raw)
To: Jeff King; +Cc: J. Bruce Fields, git
In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net>
On 2007-05-15 01:08:08 -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).
You know, this rings a bell. I've discovered that a "MIME-Version:
1.0" is needed before. :-)
"stg mail" used to have the same problem, until it was changed to use
the Python e-mail libraries for all that stuff. And since then I
haven't had problems with it.
> 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, 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.
I very much agree.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-15 8:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vmz06lu7d.fsf@assigned-by-dhcp.cox.net>
On Tuesday 2007 May 15, Junio C Hamano wrote:
> I think this on top of your patch would be the minimum necessary
> for v1.5.2.
Oops. I think I'm going to mail you a big bat with "Documentation" carved
into it that you can use for smacking us (me), for submitting patches without
documentation.
Sorry.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* testing vger handling of charsets (part 2)
From: Jeff King @ 2007-05-15 7:13 UTC (permalink / raw)
To: git; +Cc: kha, peff, bfields
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.
If your mail server doesn't advertise the 8BITMIME extensions, I expect
this message to come through OK, since vger will (hopefully) respect the
existing content-type header. Karl and Bruce, can you please report?
^ permalink raw reply
* testing vger handling of charsets (part 1)
From: Jeff King @ 2007-05-15 7:12 UTC (permalink / raw)
To: git; +Cc: kha, peff, bfields
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.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: David Kågedal @ 2007-05-15 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705081256410.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 8 May 2007, Martin Langhoff wrote:
>
>> Heh. Making the index very visible makes sense when you are merging,
>
> You're saying that the main use of the index is to help merging. I have to
> disagree strongly.
>
> When I have been chasing a bug all over the place, and finally found it,
> my working tree is a mess. Lots of assertions, lots of debugging
> statements, some of them commented out. So, now it is cleanup time, right?
>
> The problem is that more often than not, I broke my fix while cleaning up.
>
> Therefore, I now put all changed files into the index (git add -u), and
> clean up the files one by one, always checking with "git diff" and "git
> diff HEAD" what I still have to do.
Why not simply use a temporary branch for this? They're free, and you
can diff just as easily, if not more. And you don't risk losing it if
you slip with a command.
--
David Kågedal
^ 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