All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
Date: Tue, 20 Jun 2006 01:58:56 -0700	[thread overview]
Message-ID: <7vr71kcien.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <4497AED4.5060505@lsrfire.ath.cx> (Rene Scharfe's message of "Tue, 20 Jun 2006 10:16:20 +0200")

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Junio C Hamano schrieb:
>> BTW, I think we would probably want to have this patch on top of
>> Rene's patch.  In all instances, the variable "buf" is of type
>> "const char *" and the existing casts do not make sense to me.
>> 
>> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
>> index 5c8a5f0..39a61b6 100644
>
> Your patch reverts builtin-tar-tree.c to the version which is
> currently both in master and next, which I think is a good
> change.  However, could it be avoided at merge time?

Sorry for attributing those "casts [that] do not make sense to
me" to you -- it is not your code but part of Florian's patch.

I think applying the patch in question on top of Florian's 11172e
would be the most sensible, since that is currently the tip of ff/c99
topic branch whose early parts have been merged to "next" and
the tip to "pu".  When Linus feels as sympathetic as I do, we
can pull the rest of ff/c99 branch to "next" and then eventually
to "master" and the patch will be merged together without
introducing the nonsense casts.

Another possibility is to amend the tip of ff/c99 topic branch,
since it is not merged to "next" yet.  I promised not to rewind
"master" nor "next", but never made promises not to rewind "pu",
so it is a fair game.  I think it is simpler and cleaner, so
that will be what I will do.

> OT: I found the blobs 5c8a5f0 and 39a61b6 by guessing (they are
> builtin-tar-tree.c in pu and master, respectively).  OK, that
> was easy.  But is there a way to reversely look up an object
> without guessing, i.e. find out which commit(s) introduced a
> certain blob?

You could do something like this (totally untested).

Going from the above "diff --git" index line you have object
name abbreviations and pathnames as clues.  To take advantage of
it, you could use "git rev-list pu -- builtin-tar-tree.c"
instead of unlimited list.

$ git rev-list pu |
  git diff-tree -r --stdin --pretty |
  perl -e '
	my @lines = ();
        sub flush_em {
        	my @found = ();
                my @comment = ();
		for my $l (@lines) {
                	if ($l !~ /^:/) {
				push @comment, $l;
				next;
			}
                        for (@ARGV) {
                        	if ($l =~ / $_/) {
                                	push @found, $l;
					last;
				}
                        }
                }
		if (@found) {
			print join("", @comment, @found);
                }
                @lines = ();
	}
        while (<STDIN>) {
        	if (/^commit [0-9a-f]{40}$/) { flush_em(); }
                push @lines, $_;
	}
        flush_em();
  ' 39a61b6 5c8a5f0

  reply	other threads:[~2006-06-20  8:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-18  5:50 [PATCH] Fix git to be (more) ANSI C99 compliant Florian Forster
2006-06-18  8:07 ` Timo Hirvonen
2006-06-18  8:14   ` Thomas Glanzmann
2006-06-18  8:21   ` Florian Forster
2006-06-18  8:43     ` Timo Hirvonen
2006-06-18  8:26 ` Rene Scharfe
2006-06-18  8:35   ` Florian Forster
2006-06-18 15:18     ` [PATCH 0/7] Improve ANSI C99 compliance Florian Forster
2006-06-18 15:18       ` [PATCH 1/7] Remove ranges from switch statements Florian Forster
2006-06-18 15:18         ` [PATCH 2/7] Initialize FAMs using `FLEX_ARRAY' Florian Forster
2006-06-18 15:18           ` [PATCH 3/7] Don't instantiate structures with FAMs Florian Forster
2006-06-18 15:18             ` [PATCH 4/7] Cast pointers to `void *' when used in a format Florian Forster
2006-06-18 15:18               ` [PATCH 5/7] Don't use empty structure initializers Florian Forster
2006-06-18 15:18                 ` [PATCH 6/7] Change types used in bitfields to be `int's Florian Forster
2006-06-18 15:18                   ` [PATCH 7/7] Remove all void-pointer arithmetic Florian Forster
2006-06-18 21:07         ` [PATCH 1/7] Remove ranges from switch statements Junio C Hamano
2006-06-18 21:24           ` Timo Hirvonen
2006-06-18  8:29 ` [PATCH] Fix git to be (more) ANSI C99 compliant Junio C Hamano
2006-06-18 16:50 ` Linus Torvalds
2006-06-19 21:21   ` Florian Forster
2006-06-20  1:59     ` Junio C Hamano
2006-06-20  8:16       ` Rene Scharfe
2006-06-20  8:58         ` Junio C Hamano [this message]
2006-06-21 11:15           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr71kcien.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.