* Re: quilt/0.46-1 misbehaviour...
From: Johannes Schindelin @ 2007-11-20 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matti Aarnio, git
In-Reply-To: <7vve7xl97g.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Nov 2007, Junio C Hamano wrote:
> Va bgure jbeqf, junk qbrf guvf unir gb qb jvgu tvg???
Did you not mean "jung" instead of "junk"?
Ciao,
Dscho
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-20 11:34 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <3057F6F3-BEAA-447A-AB79-A0AFB7DB8826@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
On Mon, 2007-11-19 at 17:49 +0100, Benoit Sigoure wrote:
> You can create a repository on repo.or.cz then :)
I will :=)
>
> As it is often the case different people happen to work on similar
> things without knowing each other. I started http://repo.or.cz/w/
> tutorial.git which is meant to be a big Beamer presentation that
> presents Git thoroughly. I wrote some ideas but didn't start to
> write the slides. Just in case you want to have a look.
Thanks, there are certainly some things in that document that I ought to
consider incorporating in the guide. But for now I'll let it rest for a
little while, because I don't have time to mess with it. Patches are
always welcome ;)
> One of the things you said in your guide is that Git is easy to
> learn. I think this is wrong. Git is way more complicated than most
> other SCMs, especially compared to SVN. Its documentation is far
> behind, compared to what other SCMs have. There is no real user
> guide and the man pages are incomplete, at best. I know saying this
> is a bit harsh, especially to the people out there that are working
> and sending patches to improve the documentation, but I think we have
> to admit that it's true, even though Git is making progress on this
> aspect.
Well, you are right to some extent. But it's this gap I would like to
fill with the nutshell guide. The "for normal people" slogan is meant to
refer to non-technical developers (like scientists). I should probably
include a little section in the intro describing distributed vs.
centralised SCMs in general.
Thanks for the input,
.jonas.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Johannes Schindelin @ 2007-11-20 11:28 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Sergei Organov, git, gitster
In-Reply-To: <3FC9A391-AED0-4988-B1F7-EE5C06AD1137@wincent.com>
Hi,
On Tue, 20 Nov 2007, Wincent Colaiuta wrote:
> El 19/11/2007, a las 14:35, Johannes Schindelin escribi?:
>
> > - it makes writing the perl script to do a very tiny subset of
> > asciidoc formatting much harder. We encounter enough problems with
> > the different versions of asciidoc/docbook combinations that I think
> > this perl script would be actually useful.
> >
> > I know that the user manual uses some advanced features, too, but it
> > did not use ifdef in the main text, for example, let alone nested
> > ifdefs, which your patch would encourage much more than the source
> > before.
>
> Out of curiosity, have you done any more work on that WIP AsciiDoc
> replacement since you last wrote to the list about it back in October?
Yes. I rewrote it three times, and the third time is not finished, but
slowed down to a glacial pace. You can see the continental shift at my
repository on repo.or.cz (it's the "dscho" fork of git.git).
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] send-pack: print "maybe you need to pull" hint
From: Jeff King @ 2007-11-20 11:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20071120111317.GA4120@sigill.intra.peff.net>
If there were refs rejected for not being fastforwards, then
we used to print a "maybe you are not up-to-date" hint. This
was lost in the recent terse-output patches.
Signed-off-by: Jeff King <peff@peff.net>
---
I am slightly negative on this patch, just because I always found that
particular warning a bit ugly (and the new output is so nice and
compact). But for new users, perhaps the extra hint is helpful?
If we do want the warning, then other options include:
- listing each non-fast forward, as Alex's original patch did; this
seems kind of pointless given that they are clustered at the bottom
already
- possibly cluster non-fast forwards differently from other errors in
the output
- tweak the text
builtin-send-pack.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index f1cdb97..4bfa847 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -341,6 +341,7 @@ static void print_push_status(const char *dest, struct ref *refs)
{
struct ref *ref;
int n = 0;
+ int nonff = 0;
if (args.verbose) {
for (ref = refs; ref; ref = ref->next)
@@ -357,7 +358,15 @@ static void print_push_status(const char *dest, struct ref *refs)
ref->status != REF_STATUS_UPTODATE &&
ref->status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n);
+ if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD)
+ nonff++;
}
+
+ if (nonff)
+ error("%d remote refs were not ancestors of their "
+ "corresponding local ref\n"
+ "Maybe you are not up-to-date and need to pull first?",
+ nonff);
}
static int refs_pushed(struct ref *ref)
--
1.5.3.6.1784.gd1b1d-dirty
^ permalink raw reply related
* [PATCH 1/2] send-pack: cluster ref status reporting
From: Jeff King @ 2007-11-20 11:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20071120111317.GA4120@sigill.intra.peff.net>
Instead of intermingling success and failure, we now print:
1. all uptodate refs (if args.verbose is enabled)
2. successfully pushed refs
3. failed refs
with the assumption that the user is most likely to see the
ones at the end, and therefore we order them from "least
interesting" to "most interesting."
Signed-off-by: Jeff King <peff@peff.net>
---
I am somewhat ambivalent on this patch. In most cases, it won't make a
difference, since the output is small enough. For large pushes, it might
be better to have errors at the end. OTOH, you do still get "error:
failed to push to ..." at the end, and you can scroll up and see the
errors if you like. And it's not like preserving the original ref output
order was all that interesting.
builtin-send-pack.c | 93 +++++++++++++++++++++++++++++----------------------
1 files changed, 53 insertions(+), 40 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 3ce218f..f1cdb97 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -298,52 +298,65 @@ static void print_ok_ref_status(struct ref *ref)
}
}
+static int print_one_push_status(struct ref *ref, const char *dest, int count)
+{
+ if (!count)
+ fprintf(stderr, "To %s\n", dest);
+
+ switch(ref->status) {
+ case REF_STATUS_NONE:
+ print_ref_status('X', "[no match]", ref, NULL, NULL);
+ break;
+ case REF_STATUS_REJECT_NODELETE:
+ print_ref_status('!', "[rejected]", ref, NULL,
+ "remote does not support deleting refs");
+ break;
+ case REF_STATUS_UPTODATE:
+ print_ref_status('=', "[up to date]", ref,
+ ref->peer_ref, NULL);
+ break;
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ print_ref_status('!', "[rejected]", ref, ref->peer_ref,
+ "non-fast forward");
+ break;
+ case REF_STATUS_REMOTE_REJECT:
+ print_ref_status('!', "[remote rejected]", ref,
+ ref->deletion ? ref->peer_ref : NULL,
+ ref->remote_status);
+ break;
+ case REF_STATUS_EXPECTING_REPORT:
+ print_ref_status('!', "[remote failure]", ref,
+ ref->deletion ? ref->peer_ref : NULL,
+ "remote failed to report status");
+ break;
+ case REF_STATUS_OK:
+ print_ok_ref_status(ref);
+ break;
+ }
+
+ return 1;
+}
+
static void print_push_status(const char *dest, struct ref *refs)
{
struct ref *ref;
- int shown_dest = 0;
+ int n = 0;
- for (ref = refs; ref; ref = ref->next) {
- if (!ref->status)
- continue;
- if (ref->status == REF_STATUS_UPTODATE && !args.verbose)
- continue;
+ if (args.verbose) {
+ for (ref = refs; ref; ref = ref->next)
+ if (ref->status == REF_STATUS_UPTODATE)
+ n += print_one_push_status(ref, dest, n);
+ }
- if (!shown_dest) {
- fprintf(stderr, "To %s\n", dest);
- shown_dest = 1;
- }
+ for (ref = refs; ref; ref = ref->next)
+ if (ref->status == REF_STATUS_OK)
+ n += print_one_push_status(ref, dest, n);
- switch(ref->status) {
- case REF_STATUS_NONE:
- print_ref_status('X', "[no match]", ref, NULL, NULL);
- break;
- case REF_STATUS_REJECT_NODELETE:
- print_ref_status('!', "[rejected]", ref, NULL,
- "remote does not support deleting refs");
- break;
- case REF_STATUS_UPTODATE:
- print_ref_status('=', "[up to date]", ref,
- ref->peer_ref, NULL);
- break;
- case REF_STATUS_REJECT_NONFASTFORWARD:
- print_ref_status('!', "[rejected]", ref, ref->peer_ref,
- "non-fast forward");
- break;
- case REF_STATUS_REMOTE_REJECT:
- print_ref_status('!', "[remote rejected]", ref,
- ref->deletion ? ref->peer_ref : NULL,
- ref->remote_status);
- break;
- case REF_STATUS_EXPECTING_REPORT:
- print_ref_status('!', "[remote failure]", ref,
- ref->deletion ? ref->peer_ref : NULL,
- "remote failed to report status");
- break;
- case REF_STATUS_OK:
- print_ok_ref_status(ref);
- break;
- }
+ for (ref = refs; ref; ref = ref->next) {
+ if (ref->status != REF_STATUS_NONE &&
+ ref->status != REF_STATUS_UPTODATE &&
+ ref->status != REF_STATUS_OK)
+ n += print_one_push_status(ref, dest, n);
}
}
--
1.5.3.6.1784.gd1b1d-dirty
^ permalink raw reply related
* Re: ! [rejected] master -> master (non-fast forward)
From: Jeff King @ 2007-11-20 11:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071120065021.GA4172@steel.home>
On Tue, Nov 20, 2007 at 07:50:21AM +0100, Alex Riesen wrote:
> > Alex, are you going to rework your "consolidate nonff errors and print a
> > more extended message" patch on top of what's in next (I think it should
> > be much simpler now).
>
> Do you mean that "Beautify the output of send-pack a bit", Message-ID:
> <20071112221140.GD2918@steel.home>?
>
> If so, I'm confused. Didn't you already do that in your recent
> "send-pack:" patch series? It looked to me as if you did (except for
> the hint regarding non-ff branches to be updated everything is there).
That is what I meant. In the current code, the errors aren't
consolidated at the end, and as you mentioned, we don't print the extra
message. Two patch series follows (but see comments on each patch).
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view
From: Jakub Narebski @ 2007-11-20 10:58 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <4BAE81C8-EFF3-473D-B243-B7D0F66F131B@wincent.com>
Wincent Colaiuta wrote:
> So yes, this is discarding information -- in a sense it is actually
> removing *correct* configuration from the server side to work around
> undesired behaviour on the client side -- but it gave the behaviour I
> wanted. So I think this patch is actually a good idea, because the
> behaviour (the user experience) is more important than adhering to a
> standard just because its a standard.
Modifying gitweb to work around not configured web browser and
mime.types not written for gitweb like in this RFC patch is one way of
solving this. Is it good way? That is why it is an RFC... well that
and details of sanitization.
Another would be to use mime.types crafted specially for gitweb, and use
it for $mimetypes_file (gitweb falls back to /etc/mime.types if it is
not defined or not present). This might be better solution.
QUESTION: Currently gitweb checks if $mimetypes_file is relative path
(using nonportable m!^/! instead of File::Spec::file_name_is_absolute),
and if it is then it is used as relative to project. Does anyone use
this feature to provide per-project mimetypes? Would perhaps using
relative path as-is (i.e. relative to gitweb script) be better
solution, and checking for gitweb.mimetypes repo configuration variable
for per-repo relative to project if relative?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Wincent Colaiuta @ 2007-11-20 9:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergei Organov, git, gitster
In-Reply-To: <Pine.LNX.4.64.0711191430460.16728@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
El 19/11/2007, a las 14:35, Johannes Schindelin escribió:
> - it makes writing the perl script to do a very tiny subset of
> asciidoc
> formatting much harder. We encounter enough problems with the
> different
> versions of asciidoc/docbook combinations that I think this perl
> script
> would be actually useful.
>
> I know that the user manual uses some advanced features, too, but it
> did
> not use ifdef in the main text, for example, let alone nested ifdefs,
> which your patch would encourage much more than the source before.
Out of curiosity, have you done any more work on that WIP AsciiDoc
replacement since you last wrote to the list about it back in October?
I'm on a new OS install now, so just yesterday and today I had to set
up the AsciiDoc/DocBook/xmlto toolchain again, and was reminded of how
painful it was. At least on Mac OS X, it requires installing a bunch
of dependencies (and specific versions of them otherwise it won't
work), hacking Makefiles, installing a bunch of XSL and DTDs, and
setting up XML catalogs. Doable but annoying.
Cheers,
Wincent
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2413 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Ask Bjørn Hansen @ 2007-11-20 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6ill5f1.fsf@gitster.siamese.dyndns.org>
On Nov 19, 2007, at 23:52, Junio C Hamano wrote:
> How did you prepare and send this patch?
git format-patch + tweak in emacs.
> I see 7 preimage lines and 11 postimage lines, although the hunk
> header claims otherwise.
>
> Did you edit the patch in Emacs diff mode or something?
Indeed! I take it you've seen that particular way of botching it
before. :-)
When I was about to send the patch I realized I had added whitespace
at the end of one of the lines. Ironically then I ended up just
sending the messed up patch because I couldn't apply it to my working
copy after doing a reset. Being a new git user I convinced myself
that I had messed up the reset rather than the patch. Doh. My
apologies! A new patch should be on the list momentarily.
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* [PATCH] git-send-email: Don't add To: recipients to the Cc: header too
From: Ask Bjørn Hansen @ 2007-11-20 9:34 UTC (permalink / raw)
To: git; +Cc: Ask Bjørn Hansen
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
---
git-send-email.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fd0a4ad..b832d2d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -557,7 +557,11 @@ sub sanitize_address
sub send_message
{
my @recipients = unique_email_list(@to);
- @cc = (map { sanitize_address($_) } @cc);
+ @cc = (grep { my $cc = extract_valid_address($_);
+ not grep { $cc eq $_ } @recipients
+ }
+ map { sanitize_address($_) }
+ @cc);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
@recipients = (map { extract_valid_address($_) } @recipients);
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Junio C Hamano @ 2007-11-20 8:30 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Björn Steinbrink, raa.lkml, git
In-Reply-To: <Pine.LNX.4.64.0711191847550.7957@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
>> ...
>> How about doing it this way?
>
> it looks ok on Solaris. I assembled the following patch from your
> posting, could you please include it?
>
>
> Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
I knew it would work on Solaris with gcc and cc that do not
understand flexible array members, but I am a bit worried about
other environments, where flexible array members are properly
supported. They've been happily using member[] but with the
patch they suddenly start wasting a cell.
But we should do this sooner rather than later to find out any
breakage, and give people on platforms with a cc that supports
flexible array members and care about wasted memory enough time
to send patches to support their compiler in the way similar to
how gcc is supported.
But I cannot use your message with whitespace-broken patch (note
"format=flawed") and insufficient commit log message, which
means I have to do this myself. Not tonight...
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view
From: Junio C Hamano @ 2007-11-20 8:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1195484054-18164-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Use 'text/plain' for files which are text and can be viewed in a
> browser, and are not among a few 'text/*' mimetypes universally
> recognized by web browsers. This means files with 'text/*' which are
> not text/html, text/css, text/sgml or text/xml, and files with
> 'application/x-*' mimetype which are nevertheless text: javascript,
> shell, Perl, Tcl, (La)TeX,...
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Tired of my web browser (Mozilla) asking me what I want to do with
> shell script, Perl script or LaTeX document when using 'blob_plain'
> (raw) view,...
I admit that I share the irritation, but I've felt that solving
it this way by discarding information is going backwards, and
the kosher solution is to tell the browser what to do with these
unknown mimetypes. Unfortunately this needs to be done by the
user -- I do not think the server can.
On the other hand, maybe the people who are browsing the plain
view from the browser do not need to have the content marked as
written in what programming language. I dunno.
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Junio C Hamano @ 2007-11-20 7:52 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <1195470026-7389-1-git-send-email-ask@develooper.com>
Ask Bjørn Hansen <ask@develooper.com> writes:
> Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
> ---
> git-send-email.perl | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 65620ab..530b456 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -557,8 +557,11 @@ sub sanitize_address
> sub send_message
> {
> my @recipients = unique_email_list(@to);
> - @cc = (map { sanitize_address($_) } @cc);
> + @cc = (grep { my $cc = extract_valid_address($_);
> + not grep { $cc eq $_ } @recipients
> + }
> + map { sanitize_address($_) }
> + @cc);
> my $to = join (",\n\t", @recipients);
> @recipients = unique_email_list(@recipients,@cc,@bcclist);
> @recipients = (map { extract_valid_address($_) } @recipients);
> --
> 1.5.3.5.561.g140d
How did you prepare and send this patch?
I see 7 preimage lines and 11 postimage lines, although the hunk
header claims otherwise.
Did you edit the patch in Emacs diff mode or something?
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Alex Riesen @ 2007-11-20 6:50 UTC (permalink / raw)
To: Jeff King; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071120041620.GA23566@sigill.intra.peff.net>
Jeff King, Tue, Nov 20, 2007 05:16:20 +0100:
> On Sun, Nov 18, 2007 at 07:29:01PM +0100, Alex Riesen wrote:
>
> > > jonsmirl@terra:~/ds$ git push digispeaker
> > > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> > > ! [rejected] master -> master (non-fast forward)
> > > error: failed to push to
> >
> > the branch you are pushing does not fast-forward to the one on
> > digispeaker. IOW, the master on digispeaker has changed since you made
> > changes on your local master.
>
> Alex, are you going to rework your "consolidate nonff errors and print a
> more extended message" patch on top of what's in next (I think it should
> be much simpler now).
Do you mean that "Beautify the output of send-pack a bit", Message-ID:
<20071112221140.GD2918@steel.home>?
If so, I'm confused. Didn't you already do that in your recent
"send-pack:" patch series? It looked to me as if you did (except for
the hint regarding non-ff branches to be updated everything is there).
^ permalink raw reply
* Re: quilt/0.46-1 misbehaviour...
From: Junio C Hamano @ 2007-11-20 6:30 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071120055149.GQ6372@mea-ext.zmailer.org>
Matti Aarnio <matti.aarnio@zmailer.org> writes:
> .. or perhaps Exim, but odd result in arriving and thus outgoing headers anyway.
>
> From: The Post Office <postmaster@vger.kernel.org>
> Subject: Delivery reports about your email [FAILED(1)]
> ...
>
> Following is copy of the message headers. Original message content may
> be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure.
>
> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
> id S1757551AbXKTBQ5; Mon, 19 Nov 2007 20:16:57 -0500
> ...
> Message-Id: <20071120011333.850453474@sgi.com>
> References: <20071120011132.143632442@sgi.com>
> User-Agent: quilt/0.46-1
> Date: Mon, 19 Nov 2007 17:11:41 -0800
> ...
My condolences. Is there anything the people on the git mailing
list can help?
Va bgure jbeqf, junk qbrf guvf unir gb qb jvgu tvg???
^ permalink raw reply
* Re: t9106 failure, bisect weirdness
From: carbonated beverage @ 2007-11-20 6:13 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200711200552.27001.chriscool@tuxfamily.org>
> Could you try running the test twice when you bisect ?
> This way bisecting should give you the real first bad commit.
I re-ran it several times, and also manually -- there were times it'd
succeed 6 times in a row before failing. Weird.
Finally, the bisect came down to:
ramune/lycaeum:git: git bisect good
c74d9acf20ba0c69bbd67c5b0bb3bd3c2349cebe is first bad commit
commit c74d9acf20ba0c69bbd67c5b0bb3bd3c2349cebe
Author: Eric Wong <normalperson@yhbt.net>
Date: Mon Nov 5 03:21:47 2007 -0800
git-svn: fix dcommit clobbering when committing a series of diffs
Modifying the failing t9106-git-svn-dcommit-clobber-series.sh test to
add touch statements as so:
test x\"\`sed -n -e 4p < file\`\" = x4444 && touch '/tmp/eleven' &&
test x\"\`sed -n -e 7p < file\`\" = x7777 && touch '/tmp/twelve' &&
test x\"\`sed -n -e 58p < file\`\" = x5588 && touch '/tmp/thirteen' &&
test x\"\`sed -n -e 61p < file\`\" = x6611
Line 52 was the culprit:
test x\"\`sed -n -e 58p < file\`\" = x5588 &&
-- DN
Daniel
^ permalink raw reply
* quilt/0.46-1 misbehaviour...
From: Matti Aarnio @ 2007-11-20 5:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 82 bytes --]
.. or perhaps Exim, but odd result in arriving and thus outgoing headers anyway.
[-- Attachment #2: Type: message/rfc822, Size: 10943 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 3879 bytes --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
Generic VGER note: Joining/leaving VGER's lists thru server:
majordomo@vger.kernel.org
Reporting-MTA: dns; vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>
Arrival-Date: Mon, 19 Nov 2007 20:16:57 -0500
Local-Spool-ID: S1757551AbXKTBQ5
FAILED:
Original Recipient:
rfc822;afds@cs.tu-berlin.de
Final Recipient:
RFC822;afds@cs.tu-berlin.de
Status:
5.6.0
Remote MTA:
dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|39031)
Last Attempt Date:
Mon, 19 Nov 2007 20:17:31 -0500
X-ZTAID:
smtp[14954]
Diagnostic Code:
smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
Control data:
smtp cs.tu-berlin.de afds@cs.tu-berlin.de 99
Diagnostic texts:
<<- MAIL From:<linux-kernel-owner+afds=40cs.tu-berlin.de-S1757551AbXKTBQ5@vger.kernel.org> BODY=8BITMIME SIZE=5352
->> 250 2.1.0 Ok
<<- RCPT To:<afds@cs.tu-berlin.de>
->> 250 2.1.5 Ok
<<- DATA
->> 354 End data with <CR><LF>.<CR><LF>
<<- .
->> 554 5.6.0 Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From"
Following is a copy of MESSAGE/DELIVERY-STATUS format section below.
It is copied here in case your email client is unable to show it to you.
The information here below is in Internet Standard format designed to
assist automatic, and accurate presentation and usage of said information.
In case you need human assistance from the Postmaster(s) of the system which
sent you this report, please include this information in your question!
Virtually Yours,
Automatic Email Delivery Software
Reporting-MTA: dns; vger.kernel.org
Arrival-Date: Mon, 19 Nov 2007 20:16:57 -0500
Local-Spool-ID: S1757551AbXKTBQ5
Original-Recipient: rfc822;afds@cs.tu-berlin.de
Final-Recipient: RFC822;afds@cs.tu-berlin.de
Action: failed
Status: 5.6.0
Remote-MTA: dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|39031)
Last-Attempt-Date: Mon, 19 Nov 2007 20:17:31 -0500
Diagnostic-Code: smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
Following is copy of the message headers. Original message content may
be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure.
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1757551AbXKTBQ5; Mon, 19 Nov 2007 20:16:57 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756416AbXKTBNp
(ORCPT <rfc822;linux-kernel-outgoing>);
Mon, 19 Nov 2007 20:13:45 -0500
Received: from relay1.sgi.com ([192.48.171.29]:49836 "EHLO relay.sgi.com"
rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
id S1753655AbXKTBNe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
Mon, 19 Nov 2007 20:13:34 -0500
Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51])
by relay1.corp.sgi.com (Postfix) with ESMTP id 2556E8F80AF;
Mon, 19 Nov 2007 17:13:34 -0800 (PST)
Received: from clameter by schroedinger.engr.sgi.com with local (Exim 3.36 #1 (Debian))
id 1IuHgE-0004iU-00; Mon, 19 Nov 2007 17:13:34 -0800
Message-Id: <20071120011333.850453474@sgi.com>
References: <20071120011132.143632442@sgi.com>
User-Agent: quilt/0.46-1
Date: Mon, 19 Nov 2007 17:11:41 -0800
From: clameter@sgi.com
From: Christoph Lameter <clameter@sgi.com>
To: ak@suse.de
Cc: akpm@linux-foundation.org
Cc: travis@sgi.com
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org
Subject: [rfc 09/45] cpu alloc: IA64 support
Content-Disposition: inline; filename=cpu_alloc_ia64_support
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
[-- Attachment #2.1.2: Type: message/delivery-status, Size: 465 bytes --]
[-- Attachment #2.1.3: Type: message/rfc822, Size: 5195 bytes --]
From: clameter@sgi.com
From: Christoph Lameter <clameter@sgi.com>
To: ak@suse.de
Cc: akpm@linux-foundation.org
Cc: travis@sgi.com
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org
Subject: [rfc 09/45] cpu alloc: IA64 support
Date: Mon, 19 Nov 2007 17:11:41 -0800
Message-ID: <20071120011333.850453474@sgi.com>
[-- Attachment #2.1.3.1: cpu_alloc_ia64_support --]
[-- Type: text/plain, Size: 3774 bytes --]
From: clameter@sgi.com
From: Christoph Lameter <clameter@sgi.com>
To: ak@suse.de
Cc: akpm@linux-foundation.org
Cc: travis@sgi.com
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org
Subject: [rfc 09/45] cpu alloc: IA64 support
Date: Mon, 19 Nov 2007 17:11:41 -0800
Message-ID: <20071120011333.850453474@sgi.com>
Typical use of per cpu memory for a small system of 8G 8p 4node is less than
64k per cpu memory. This is increasing rapidly for larger systems where we can
get up to 512k or 1M of memory used for cpu storage.
The maximum size allowed of the cpu area is 128MB of memory.
The cpu area is placed in region 5 with the kernel, vmemmap and vmalloc areas.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
arch/ia64/Kconfig | 13 +++++++++++++
arch/ia64/kernel/vmlinux.lds.S | 2 ++
include/asm-ia64/pgtable.h | 32 ++++++++++++++++++++++++++------
3 files changed, 41 insertions(+), 6 deletions(-)
Index: linux-2.6/arch/ia64/Kconfig
===================================================================
--- linux-2.6.orig/arch/ia64/Kconfig 2007-11-18 14:38:24.661283318 -0800
+++ linux-2.6/arch/ia64/Kconfig 2007-11-18 21:13:23.281093698 -0800
@@ -99,6 +99,19 @@ config AUDIT_ARCH
bool
default y
+config CPU_AREA_VIRTUAL
+ bool
+ default y
+
+# Maximum of 128 MB cpu_alloc space per cpu
+config CPU_AREA_ORDER
+ int
+ default "13"
+
+config CPU_AREA_ALLOC_ORDER
+ int
+ default "0"
+
choice
prompt "System type"
default IA64_GENERIC
Index: linux-2.6/include/asm-ia64/pgtable.h
===================================================================
--- linux-2.6.orig/include/asm-ia64/pgtable.h 2007-11-18 14:38:24.669283083 -0800
+++ linux-2.6/include/asm-ia64/pgtable.h 2007-11-18 21:13:23.296343624 -0800
@@ -224,21 +224,41 @@ ia64_phys_addr_valid (unsigned long addr
*/
+/*
+ * Layout of RGN_GATE
+ *
+ * 47 bits wide (16kb pages)
+ *
+ * 0xa000000000000000-0xa00000200000000 8G Kernel data area
+ * 0xa000002000000000-0xa00040000000000 64T vmalloc
+ * 0xa000400000000000-0xa00060000000000 32T vmemmmap
+ * 0xa000600000000000-0xa00080000000000 32T cpu area
+ *
+ * 55 bits wide (64kb pages)
+ *
+ * 0xa000000000000000-0xa00000200000000 8G Kernel data area
+ * 0xa000002000000000-0xa04000000000000 16P vmalloc
+ * 0xa040000000000000-0xa06000000000000 8P vmemmmap
+ * 0xa060000000000000-0xa08000000000000 8P cpu area
+ */
+
#define VMALLOC_START (RGN_BASE(RGN_GATE) + 0x200000000UL)
+#define VMALLOC_END_INIT (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 10)))
+
#ifdef CONFIG_VIRTUAL_MEM_MAP
-# define VMALLOC_END_INIT (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9)))
# define VMALLOC_END vmalloc_end
extern unsigned long vmalloc_end;
#else
+# define VMALLOC_END VMALLOC_END_INIT
+#endif
+
#if defined(CONFIG_SPARSEMEM) && defined(CONFIG_SPARSEMEM_VMEMMAP)
/* SPARSEMEM_VMEMMAP uses half of vmalloc... */
-# define VMALLOC_END (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 10)))
-# define vmemmap ((struct page *)VMALLOC_END)
-#else
-# define VMALLOC_END (RGN_BASE(RGN_GATE) + (1UL << (4*PAGE_SHIFT - 9)))
-#endif
+# define vmemmap ((struct page *)VMALLOC_END_INIT)
#endif
+#define CPU_AREA_BASE (RGN_BASE(RGN_GATE) + (3UL << (4*PAGE_SHIFT - 11)))
+
/* fs/proc/kcore.c */
#define kc_vaddr_to_offset(v) ((v) - RGN_BASE(RGN_GATE))
#define kc_offset_to_vaddr(o) ((o) + RGN_BASE(RGN_GATE))
Index: linux-2.6/arch/ia64/kernel/vmlinux.lds.S
===================================================================
--- linux-2.6.orig/arch/ia64/kernel/vmlinux.lds.S 2007-11-18 21:13:46.505344120 -0800
+++ linux-2.6/arch/ia64/kernel/vmlinux.lds.S 2007-11-18 21:14:03.996593749 -0800
@@ -16,6 +16,8 @@ OUTPUT_FORMAT("elf64-ia64-little")
OUTPUT_ARCH(ia64)
ENTRY(phys_start)
jiffies = jiffies_64;
+cpu_area = CPU_AREA_BASE;
+
PHDRS {
code PT_LOAD;
percpu PT_LOAD;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] Bisect reset: do nothing when not bisecting.
From: Christian Couder @ 2007-11-20 5:39 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Before this patch, using "git bisect reset" when not bisecting
did a "git checkout master" for no good reason.
This also happened using "git bisect replay" when not bisecting
because "bisect_replay" starts by calling "bisect_reset".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 4 ++++
t/t6030-bisect-porcelain.sh | 27 ++++++++++++++++++++++++++-
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 01593eb..7a6521e 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -329,6 +329,10 @@ bisect_visualize() {
}
bisect_reset() {
+ test -f "$GIT_DIR/BISECT_NAMES" || {
+ echo "We are not bisecting."
+ return
+ }
case "$#" in
0) if [ -s "$GIT_DIR/head-name" ]; then
branch=`cat "$GIT_DIR/head-name"`
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index f09db62..2ba4b00 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,31 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+test_expect_success 'bisect reset: back in the master branch' '
+ git bisect reset &&
+ echo "* master" > branch.expect &&
+ git branch > branch.output &&
+ cmp branch.expect branch.output
+'
+
+test_expect_success 'bisect reset: back in another branch' '
+ git checkout -b other &&
+ git bisect start &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH3 &&
+ git bisect reset &&
+ echo " master" > branch.expect &&
+ echo "* other" >> branch.expect &&
+ git branch > branch.output &&
+ cmp branch.expect branch.output
+'
+
+test_expect_success 'bisect reset when not bisecting' '
+ git bisect reset &&
+ git branch > branch.output &&
+ cmp branch.expect branch.output
+'
+
test_expect_success 'bisect reset removes packed refs' '
git bisect reset &&
git bisect start &&
@@ -179,7 +204,7 @@ test_expect_success 'bisect skip: add line and then a new test' '
git bisect skip &&
git bisect good > my_bisect_log.txt &&
grep "$HASH5 is first bad commit" my_bisect_log.txt &&
- git bisect log > log_to_replay.txt
+ git bisect log > log_to_replay.txt &&
git bisect reset
'
--
1.5.3.5.1816.g0b82e-dirty
^ permalink raw reply related
* Re: git-daemon
From: Jeff King @ 2007-11-20 5:07 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27017BCC8D@az33exm24.fsl.freescale.net>
On Mon, Nov 19, 2007 at 03:49:36PM -0700, Medve Emilian wrote:
> v1.5.3.6 works but the HEAD of master and next don't. I considered the
> patches below but they seemed harmless. I think the problem comes form
> upload-pack (and below it). Weirdly enough running git-daemon standalone
> seems to work fine. Cloning over ssh or on the same file system seems to
> work fine too.
>
> I was hoping somebody can repeat the experiment (build the latest master
> or maint) and invalidate my experience.
I can't find any breakage on the current master (ea559605). Can you be
more specific about what you are trying, how it is breaking, other
details of your setup, etc?
-Peff
^ permalink raw reply
* Re: t9106 failure, bisect weirdness
From: Christian Couder @ 2007-11-20 4:52 UTC (permalink / raw)
To: carbonated beverage; +Cc: git
In-Reply-To: <20071119230601.GA15624@net-ronin.org>
Le mardi 20 novembre 2007, carbonated beverage a écrit :
[...]
> I tried running the test manually and noticed something weird as well:
>
> ramune/lycaeum:t: sh t9106-git-svn-dcommit-clobber-series.sh
> * ok 1: initialize repo
> * ok 2: (supposedly) non-conflicting change from SVN
> * ok 3: some unrelated changes to git
> * ok 4: change file but in unrelated area
> * passed all 4 test(s)
> ramune/lycaeum:t:
> ramune/lycaeum:t: pwd
> /home/ramune/src/git/git/t
> ramune/lycaeum:t:
> ramune/lycaeum:t: sh t9106-git-svn-dcommit-clobber-series.sh
> * ok 1: initialize repo
> * ok 2: (supposedly) non-conflicting change from SVN
> * ok 3: some unrelated changes to git
> * FAIL 4: change file but in unrelated area
>
> test x"`sed -n -e 4p < file`" = x4 &&
> test x"`sed -n -e 7p < file`" = x7 &&
> perl -i -p -e 's/^4$/4444/' file &&
> perl -i -p -e 's/^7$/7777/' file &&
> test x"`sed -n -e 4p < file`" = x4444 &&
> test x"`sed -n -e 7p < file`" = x7777 &&
> git commit -m '4 => 4444, 7 => 7777' file &&
> git svn dcommit &&
> svn up tmp &&
> cd tmp &&
> test x"`sed -n -e 4p < file`" = x4444 &&
> test x"`sed -n -e 7p < file`" = x7777 &&
> test x"`sed -n -e 58p < file`" = x5588 &&
> test x"`sed -n -e 61p < file`" = x6611
>
> * failed 1 among 4 test(s)
>
> So it succeeds once, then fails.
>
> /bin/sh is dash 0.5.3-7 from Debian.
>
> Any additional information needed?
Could you try running the test twice when you bisect ?
This way bisecting should give you the real first bad commit.
Could you also try to find the line that fails in the 4th test ?
For example you could replace all the trailing "&&" in this test with a new
line that contains "echo $?".
Thanks in advance,
Christian.
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Jeff King @ 2007-11-20 4:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071118182901.GA5939@steel.home>
On Sun, Nov 18, 2007 at 07:29:01PM +0100, Alex Riesen wrote:
> > jonsmirl@terra:~/ds$ git push digispeaker
> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
> > ! [rejected] master -> master (non-fast forward)
> > error: failed to push to
>
> the branch you are pushing does not fast-forward to the one on
> digispeaker. IOW, the master on digispeaker has changed since you made
> changes on your local master.
Alex, are you going to rework your "consolidate nonff errors and print a
more extended message" patch on top of what's in next (I think it should
be much simpler now).
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-send-email: show all headers when sending mail
From: Ask Bjørn Hansen @ 2007-11-20 1:53 UTC (permalink / raw)
To: ddkilzer; +Cc: Junio C Hamano, git
In-Reply-To: <327906.50991.qm@web52410.mail.re2.yahoo.com>
On Nov 19, 2007, at 10:50, David D. Kilzer wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Thanks. Looks nice and obviously correct.
>>
>> One thing that has been bugging me for a long time now stands
>> out like a sore thumb much more: empty Cc: is shown.
>
> I can't seem to reproduce this. Could you send me (off-list)
> 0001-branch-contains.txt and any relevant config bits?
You need to make git-send-email not have an implicit Cc (from signed-
off-by or some such), then it'll appear.
I sent a patch yesterday for it,
Subject: [PATCH] Don't print an empty Cc header in SMTP mode when
there's no cc recipient defined
Message-Id: <1195469295-5774-1-git-send-email-ask@develooper.com>
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: git merge no longer handles add/add
From: Johannes Schindelin @ 2007-11-20 1:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhspor$9ci$1@ger.gmane.org>
Hi,
On Mon, 19 Nov 2007, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > Exactly. ?We may keep conflict markers in the file left in the work
> > tree to highlight which lines are unique to the side that added more
> > (iow, one group of lines delimited by <<< === >>> is empty while the
> > other is not) but this is currently treated as "fishy, needs human
> > validation" to catch mismerges.
>
> BTW can xdifflib merge use original diff3 conflict markers, i.e. <<<
> [main] |||| [ancestor] === [branch] >>>?
There was a patch floating around which added git-diff3, just after I went
public with my xmerge patch. This seemed to have the code you look for.
Ciao,
Dscho
P.S.: I will refuse to reply to you in future whenever you do not Cc: me.
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Daniel Barkalow @ 2007-11-20 0:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711191454i40d56fa2h9791415c092b9b9c@mail.gmail.com>
On Mon, 19 Nov 2007, Jon Smirl wrote:
> On 11/19/07, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > "Jon Smirl" <jonsmirl@gmail.com> wrote:
> > > On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> > >> "Jon Smirl" <jonsmirl@gmail.com> writes:
> > >>
> > >> > What's causing this? I'm using stgit on the master branch.
> > [...]
> > >> pushed "A" to the remote's 'master', then built this history:
> > >>
> > >> o---o---A
> > >> /
> > >> ---o---o---o---o---A'
> > >>
> > >> by rewinding and rebuilding, and the tip of the branch now
> > >> points at A', which you tried to push to the remote.
> > >
> > > stgit must be doing this when I rebase. It pops all of it's patches,
> > > moves to head of linus/master and then rebases them.
> > [...]
> > > What is the right way to share repositories using stgit? I have a set
> > > of patches which I am working on for kernel inclusion. I have them
> > > applied as a stgit stack on top of linus/master. I need to share this
> > > patch stack with other developers. These developers may want to change
> > > one of my patches. Right now they are emailing me deltas and I apply
> > > them to the appropriate stgit patch. I have seventeen patches in my
> > > stack currently.
> >
> > StGIT is meant for keeping a clean history but with the big
> > disadvantage that this history is volatile.
> >
> > A solution is for the other developers to use StGIT or just git-rebase
> > so that they always have the same base (volatile) history and keep
> > their patches on top of yours.
> >
> > A 2nd approach is to use topic branches rather than StGIT patches but
> > you might lose some flexibility.
> >
> > Yet another approach (which I used) is to keep a public branch (can be
> > maintained by StGIT) where the history doesn't change and a devel
> > volatile branch. When I modify some patches and they are ready for
> > publishing, switch to the public branch and cherry-pick them (stg
> > pick) from the devel branch. Because this is done with a three-way
> > merge in StGIT, you will only get the new changes rather than the full
> > patch. You need to change the patch message (as it is that of the
> > original patch) to describe the specific changes and run 'stg refresh
> > && stg commit' to store it into the immutable history (well, there is
> > an 'uncommit' command as well if something goes wrong).
>
>
> Is a StGit where we can transparently share patches under version
> control in the works?
>
> Something like this:
> clone repo with stgit
> normal stg commands work with no setup
> change a patch
> stg push the repo
>
> I stg pull and the patch is updated.
> I also get rebased forward if the base repo has been updated
I've been thinking vaguely about support for essentially version
controlling a quilt series, with the fundamental idea being that the
history of the branch you're working on is a sequence of states of the
series, with magic for having both the series specification and the final
state in each commit.
Note that this is a different concept from stgit (and, I think, guilt),
which uses the git engine as the magic behind the quilt-like operation,
meaning that the history of the commit at the end of the series goes back
through the patches in the series, not back through the changes to the
series.
I've got a bunch of ideas on the subject, but I don't really have the
quilt experience to know how to make this useful to people who want to do
this kind of thing. My dream, from the perspective of a user of the
results of somebody else's use of this feature, would be being able to
bisect -mm to determine first that -mm stopped working when Andrew updated
a particular tree, and then bisect within that tree (in each case
generating the test tree with the complete -mm series, but with that
tree's patch series being from the test point).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix warning about bitfield in struct ref
From: Johannes Schindelin @ 2007-11-19 23:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071118093137.GA2196@spearce.org>
Hi,
On Sun, 18 Nov 2007, Shawn O. Pearce wrote:
> + unsigned int force:1,
Isn't this "unsigned force:1" everywhere else in git's source?
Ciao,
Dscho
^ 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