* [PATCH] Fix minor nits in configure.ac
From: Ralf Wildenhues @ 2007-11-06 20:12 UTC (permalink / raw)
To: git
Avoid "test -o" as it is only XSI not POSIX, and not portable.
Avoid exit(3) in test programs in favor of return, to accommodate
for newer Autoconf not providing a declaration for exit.
---
The missing declaration can cause needlessly wrong configure results
with some CFLAGS.
Cheers,
Ralf
configure.ac | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index ed7cc89..bd80517 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,7 +73,7 @@ fi \
AC_ARG_WITH([lib],
[AS_HELP_STRING([--with-lib=ARG],
[ARG specifies alternative name for lib directory])],
- [if test "$withval" = "no" -o "$withval" = "yes"; then \
+ [if test "$withval" = "no" || test "$withval" = "yes"; then \
AC_MSG_WARN([You should provide name for --with-lib=ARG]); \
else \
GIT_CONF_APPEND_LINE(lib=$withval); \
@@ -245,9 +245,9 @@ AC_RUN_IFELSE(
[AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
[[char buf[64];
if (sprintf(buf, "%lld%hhd%jd%zd%td", (long long int)1, (char)2, (intmax_t)3, (size_t)4, (ptrdiff_t)5) != 5)
- exit(1);
+ return 1;
else if (strcmp(buf, "12345"))
- exit(2);]])],
+ return 2;]])],
[ac_cv_c_c99_format=yes],
[ac_cv_c_c99_format=no])
])
--
1.5.3.5.561.g140d
^ permalink raw reply related
* quilt upsets some recipient sites..
From: Matti Aarnio @ 2007-11-06 20:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 129 bytes --]
In my opinnion "Cc:" isn't a field where multiple occurrances are
in itself a sign of spam, but there are a lot of such sites..
[-- Attachment #2: Type: message/rfc822, Size: 9916 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 4034 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: Tue, 6 Nov 2007 14:58:34 -0500
Local-Spool-ID: S1755552AbXKFT6e
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|33024)
Last Attempt Date:
Tue, 6 Nov 2007 14:59:06 -0500
X-ZTAID:
smtp[31080]
Diagnostic Code:
smtp; 554 (Reject, id=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times)
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-S1755552AbXKFT6e@vger.kernel.org> BODY=8BITMIME SIZE=4115
->> 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=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times
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: Tue, 6 Nov 2007 14:58:34 -0500
Local-Spool-ID: S1755552AbXKFT6e
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|33024)
Last-Attempt-Date: Tue, 6 Nov 2007 14:59:06 -0500
Diagnostic-Code: smtp; 554 (Reject, id=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times)
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 S1755552AbXKFT6e; Tue, 6 Nov 2007 14:58:34 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757493AbXKFTwa
(ORCPT <rfc822;linux-kernel-outgoing>);
Tue, 6 Nov 2007 14:52:30 -0500
Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:45386 "EHLO
relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
with ESMTP id S1754321AbXKFTwE (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 6 Nov 2007 14:52:04 -0500
Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51])
by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 20E6D908B3;
Tue, 6 Nov 2007 11:52:04 -0800 (PST)
Received: from clameter by schroedinger.engr.sgi.com with local (Exim 3.36 #1 (Debian))
id 1IpUSx-0008Jf-00; Tue, 06 Nov 2007 11:52:04 -0800
Message-Id: <20071106195203.825244760@sgi.com>
References: <20071106195144.983665861@sgi.com>
User-Agent: quilt/0.46-1
Date: Tue, 06 Nov 2007 11:52:11 -0800
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Content-Disposition: inline; filename=cpu_alloc_crypto
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: 488 bytes --]
[-- Attachment #2.1.3: Type: message/rfc822, Size: 3994 bytes --]
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Date: Tue, 06 Nov 2007 11:52:11 -0800
Message-ID: <20071106195203.825244760@sgi.com>
[-- Attachment #2.1.3.1: cpu_alloc_crypto --]
[-- Type: text/plain, Size: 2489 bytes --]
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Date: Tue, 06 Nov 2007 11:52:11 -0800
Message-ID: <20071106195203.825244760@sgi.com>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
crypto/async_tx/async_tx.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6/crypto/async_tx/async_tx.c
===================================================================
--- linux-2.6.orig/crypto/async_tx/async_tx.c 2007-11-05 09:46:04.000000000 -0800
+++ linux-2.6/crypto/async_tx/async_tx.c 2007-11-05 09:49:56.000000000 -0800
@@ -207,10 +207,10 @@ static void async_tx_rebalance(void)
for_each_dma_cap_mask(cap, dma_cap_mask_all)
for_each_possible_cpu(cpu) {
struct dma_chan_ref *ref =
- per_cpu_ptr(channel_table[cap], cpu)->ref;
+ CPU_PTR(channel_table[cap], cpu)->ref;
if (ref) {
atomic_set(&ref->count, 0);
- per_cpu_ptr(channel_table[cap], cpu)->ref =
+ CPU_PTR(channel_table[cap], cpu)->ref =
NULL;
}
}
@@ -223,7 +223,7 @@ static void async_tx_rebalance(void)
else
new = get_chan_ref_by_cap(cap, -1);
- per_cpu_ptr(channel_table[cap], cpu)->ref = new;
+ CPU_PTR(channel_table[cap], cpu)->ref = new;
}
spin_unlock_irqrestore(&async_tx_lock, flags);
@@ -327,7 +327,8 @@ async_tx_init(void)
clear_bit(DMA_INTERRUPT, dma_cap_mask_all.bits);
for_each_dma_cap_mask(cap, dma_cap_mask_all) {
- channel_table[cap] = alloc_percpu(struct chan_ref_percpu);
+ channel_table[cap] = CPU_ALLOC(struct chan_ref_percpu,
+ GFP_KERNEL | __GFP_ZERO);
if (!channel_table[cap])
goto err;
}
@@ -343,7 +344,7 @@ err:
printk(KERN_ERR "async_tx: initialization failure\n");
while (--cap >= 0)
- free_percpu(channel_table[cap]);
+ CPU_FRE(channel_table[cap]);
return 1;
}
@@ -356,7 +357,7 @@ static void __exit async_tx_exit(void)
for_each_dma_cap_mask(cap, dma_cap_mask_all)
if (channel_table[cap])
- free_percpu(channel_table[cap]);
+ CPU_FREE(channel_table[cap]);
dma_async_client_unregister(&async_tx_dma);
}
@@ -378,7 +379,7 @@ async_tx_find_channel(struct dma_async_t
else if (likely(channel_table_initialized)) {
struct dma_chan_ref *ref;
int cpu = get_cpu();
- ref = per_cpu_ptr(channel_table[tx_type], cpu)->ref;
+ ref = CPU_PTR(channel_table[tx_type], cpu)->ref;
put_cpu();
return ref ? ref->chan : NULL;
} else
--
-
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
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Robin Rosenberg @ 2007-11-06 20:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711061230540.4362@racer.site>
tisdag 06 november 2007 skrev Johannes Schindelin:
> Hi,
>
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> > >
> > >> Allowing people to revert or cherry pick partially by using paths
> > >> limiter is a very good idea; the whole "it comes from a commit so we
> > >> also commit" feels an utter nonsense, though.
> > >
> > > No.
> > >
> > > When "git revert <commit>" commits the result, "git revert <commit> --
> > > <file>" should, too.
> >
> > I was not questioning about that part. "If 'git revert <some
> > other form> foo' does not talk about commit, it should not
> > commit" was what I was referring to.
>
> Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> changes to <path>, relative to the index" (which would be the same as "git
> checkout <path>"), then committing that change just does not make sense.
>
> And it is this behaviour that people are seeking, not "git revert <commit>
> <path>".
I'm not convince making every command perform enitrely all kinds of actions
just because other SCMs interpret a name differently. git revert today
creates a *new* commit. Keep it simple. I think its ok that it mentions
another comnand when it detects arguments that does not make sense. There is
no right or wrong with interepreting reset either way, but not both ways
please. The confusion with checkout and reset is enough.
-- robin
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Nicolas Pitre @ 2007-11-06 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vr6j3gof2.fsf@gitster.siamese.dyndns.org>
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Gaah.
>
> I'd blame Linus for suggesting to make parseopt part of
> rev-parse, the latter of which makes sense only inside git while
> the former of which makes sense outside git.
>
> Would something like this help?
>
> ---
> builtin-rev-parse.c | 4 ++--
> git.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
That does help indeed.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 19:42 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Steven Grimm, git
In-Reply-To: <20071106193959.GB4382@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >
>> > > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
>> > > changes to <path>, relative to the index" (which would be the same as "git
>> > > checkout <path>"), then committing that change just does not make sense.
>> > >
>> > > And it is this behaviour that people are seeking, not "git revert <commit>
>> > > <path>".
>> >
>> > Heh, I found this in the recent log somewhere.
>> >
>> > <gitte> Really, I wonder how difficult git is for people who are not
>> > brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
>> > <gitte> From a user perspective, you might be correct. But then we have to
>> > add 1000 commands to reflect the English language.
>> > <gitte> Not what I want. [06:46]
>> >
>> > I am wondering who said it ;-).
>>
>> Now, that is not fair, using my own words against me ;-)
>
> That's very funny actually :]
Yeah, it was doubly funny after I saw you posted a list of "$scm revert"
and Dscho still sided with you in that thread.
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 19:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711061827030.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> > > changes to <path>, relative to the index" (which would be the same as "git
> > > checkout <path>"), then committing that change just does not make sense.
> > >
> > > And it is this behaviour that people are seeking, not "git revert <commit>
> > > <path>".
> >
> > Heh, I found this in the recent log somewhere.
> >
> > <gitte> Really, I wonder how difficult git is for people who are not
> > brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
> > <gitte> From a user perspective, you might be correct. But then we have to
> > add 1000 commands to reflect the English language.
> > <gitte> Not what I want. [06:46]
> >
> > I am wondering who said it ;-).
>
> Now, that is not fair, using my own words against me ;-)
That's very funny actually :]
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Junio C Hamano @ 2007-11-06 19:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, git
In-Reply-To: <alpine.LFD.0.9999.0711061355330.21255@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sun, 4 Nov 2007, Pierre Habouzit wrote:
>
>> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
>> ---
>> git-clone.sh | 102 +++++++++++++++++++++++++++++++++-------------------------
>> 1 files changed, 58 insertions(+), 44 deletions(-)
>
> Well, this patch was merged in "next" and broke git-clone rather badly.
>
> Just try something as fundamental as this:
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> fatal: Not a git repository
>
> Don't we have test cases covering this really basic operation?
We do, but RUN_SETUP will happily go up to find the .git/ next
to t/ directory that is the parent of trash/ directory, in which
the tests run, without reporting errors. As parseopt does not
depend on anything in git, this will not do any harm other than
falsely succeeding the test that should not pass.
We could probably introduce an environment variable, GIT_CEILING,
that tells the setup_git_directory_gentry() never go up beyond
that point, and set it to the t/trash directory while running
the test.
Something like that may have other uses in practice. Often
people wonder what would happen if there is /.git repository and
they would want to make sure they would not accidentally add to
the repository controlled by /.git when they have bunch of other
repositories /some/where/.git in which they usually work.
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-06 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Daniel Barkalow, Git ML
In-Reply-To: <7vwssvgrm6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
On Tue, Nov 06, 2007 at 06:23:45PM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
> >
> >> On the same vein, with today's next:
> >>
> >> $ git push origin :teaser
> >> To ssh://git.corp/srv/git/mmsx.git
> >> - [deleting] teaser
> >> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> >> Everything up-to-date
> >> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> >> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> >> Use '--' to separate paths from revisions
>
> Isn't this coming from a loosely written post-receive hook that
> wants to send mail or something and forgets that a ref could be
> removed?
oooh you may be right indeed. it's probably it, I was too quick in
assuming this was a new issue with git push, I never removed a branch on
that remote yet, and it indeed has a post-receive hook.
thanks and sorry for the noise.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Junio C Hamano @ 2007-11-06 19:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, git
In-Reply-To: <alpine.LFD.0.9999.0711061355330.21255@xanadu.home>
Gaah.
I'd blame Linus for suggesting to make parseopt part of
rev-parse, the latter of which makes sense only inside git while
the former of which makes sense outside git.
Would something like this help?
---
builtin-rev-parse.c | 4 ++--
git.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 054519b..d1038a0 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -337,11 +337,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
int i, as_is = 0, verify = 0;
unsigned char sha1[20];
- git_config(git_default_config);
-
if (argc > 1 && !strcmp("--parseopt", argv[1]))
return cmd_parseopt(argc - 1, argv + 1, prefix);
+ prefix = setup_git_directory();
+ git_config(git_default_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/git.c b/git.c
index 6c5f9af..204a6f7 100644
--- a/git.c
+++ b/git.c
@@ -340,7 +340,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "rerere", cmd_rerere, RUN_SETUP },
{ "reset", cmd_reset, RUN_SETUP },
{ "rev-list", cmd_rev_list, RUN_SETUP },
- { "rev-parse", cmd_rev_parse, RUN_SETUP },
+ { "rev-parse", cmd_rev_parse },
{ "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
{ "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP | NEED_WORK_TREE },
^ permalink raw reply related
* Re: Git-windows and git-svn?
From: Robin Rosenberg @ 2007-11-06 19:27 UTC (permalink / raw)
To: Pascal Obry
Cc: Peter Karlsson, Steffen Prohaska, Abdelrazak Younes,
Git Mailing List
In-Reply-To: <4730A9C3.1090006@obry.net>
tisdag 06 november 2007 skrev Pascal Obry:
> Peter Karlsson a écrit :
> > I got errors almost right away when trying that (I need text mode to
> > interface with some other programs), so Cygwin-git is a no-go for me at
>
> Won't it be possible for you to have a specific mount point using
> textmode and one with binmode ? This should allow you to have the best
> of both world. Note that I've never done that so I don't know if it is
> working fine.
I do that. It works fine. I've set up such paths so I have /cygdrive/c for textmode and
/binmode/c for binary mode and some other extra binary paths for convenience.
-- robin
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Nicolas Pitre @ 2007-11-06 19:04 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <1194172262-1563-5-git-send-email-madcoder@debian.org>
On Sun, 4 Nov 2007, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-clone.sh | 102 +++++++++++++++++++++++++++++++++-------------------------
> 1 files changed, 58 insertions(+), 44 deletions(-)
Well, this patch was merged in "next" and broke git-clone rather badly.
Just try something as fundamental as this:
$ git clone git://git.kernel.org/pub/scm/git/git.git
fatal: Not a git repository
Don't we have test cases covering this really basic operation?
Nicolas
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Daniel Barkalow, Git ML
In-Reply-To: <7vwssvgrm6.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 06, 2007 at 10:23:45AM -0800, Junio C Hamano wrote:
> >> $ git push origin :teaser
> >> To ssh://git.corp/srv/git/mmsx.git
> >> - [deleting] teaser
> >> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> >> Everything up-to-date
> >> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> >> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> >> Use '--' to separate paths from revisions
>
> Isn't this coming from a loosely written post-receive hook that
> wants to send mail or something and forgets that a ref could be
> removed?
That would make sense. I was wondering how in the world he managed to
provoke output from git-push that came after the send_pack call. So I
think this is unrelated to the bug we were discussing (although the
'Everything up-to-date' message is easily reproducible and seems a bit
silly given that we did push some changes).
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.7
From: Patrick Aljord @ 2007-11-06 18:39 UTC (permalink / raw)
To: git list
In-Reply-To: <8c5c35580711060044i7a3d0134p42e9437cbe2a258b@mail.gmail.com>
Looks great, thanks for the new release.
It would be great if when a commit message contains something such as
#1234 it would automatically link to the bug tracker page of that bug
(like Trac does) by preconfiguring the bugtracker URL.
Such as "bug #238 test for root-window that XFree86 fixed in their"
would link the "#238" part to
http://bugs.freedesktop.org/show_bug.cgi?id=238
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aghiles, Jakub Narebski, git
In-Reply-To: <7v1wb3i6nx.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > A pull is just a fetch and a merge. And a merge is a commit with more
> > than one parent. So you can use the command "git reset --hard HEAD^" to
> > undo a merge, just as you can undo any other commit.
>
> *DANGER*
>
> A pull is usually just a fetch and a merge, but sometimes it can fast
> forward. ORIG_HEAD, not HEAD^, points at the previous HEAD location in
> both cases.
Oops. Right.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7v8x5bi703.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> > changes to <path>, relative to the index" (which would be the same as "git
> > checkout <path>"), then committing that change just does not make sense.
> >
> > And it is this behaviour that people are seeking, not "git revert <commit>
> > <path>".
>
> Heh, I found this in the recent log somewhere.
>
> <gitte> Really, I wonder how difficult git is for people who are not
> brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
> <gitte> From a user perspective, you might be correct. But then we have to
> add 1000 commands to reflect the English language.
> <gitte> Not what I want. [06:46]
>
> I am wondering who said it ;-).
Now, that is not fair, using my own words against me ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Junio C Hamano @ 2007-11-06 18:23 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, Daniel Barkalow, Git ML
In-Reply-To: <20071106180910.GA25934@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
>
>> On the same vein, with today's next:
>>
>> $ git push origin :teaser
>> To ssh://git.corp/srv/git/mmsx.git
>> - [deleting] teaser
>> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
>> Everything up-to-date
>> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
>> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
>> Use '--' to separate paths from revisions
Isn't this coming from a loosely written post-receive hook that
wants to send mail or something and forgets that a ref could be
removed?
^ permalink raw reply
* Re: git pull opinion
From: Junio C Hamano @ 2007-11-06 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Aghiles, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711061159240.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> A pull is just a fetch and a merge. And a merge is a commit with more
> than one parent. So you can use the command "git reset --hard HEAD^" to
> undo a merge, just as you can undo any other commit.
*DANGER*
A pull is usually just a fetch and a merge, but sometimes it can
fast forward. ORIG_HEAD, not HEAD^, points at the previous HEAD
location in both cases.
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 18:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Daniel Barkalow, Git ML
In-Reply-To: <20071106175627.GB9517@artemis.corp>
On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
> On the same vein, with today's next:
>
> $ git push origin :teaser
> To ssh://git.corp/srv/git/mmsx.git
> - [deleting] teaser
> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> Everything up-to-date
> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
I can't replicate this output; can you provide more information on your
test repo?
If it is related to the bug we have been discussing, there haven't been
any fixes applied yet. :)
-Peff
^ permalink raw reply
* Re: git pull opinion
From: Pascal Obry @ 2007-11-06 18:07 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
Aghiles a écrit :
> Hello,
>
> I am not sure this is the best place to write about this. Anyway,
> we just switched a couple of repositories to git (from svn) here
> at work and one thing people find annoying is a pull into
> a dirty directory. Before the "stash" feature it was even worse
> but now we can type:
>
> git stash
> git pull
> git stash apply
>
> But isn't that something we should be able to specify to the "pull"
> command ? Additionally and if I am not mistakn, those commands will
> create "dangling" commits and blobs. So one has to execute:
>
> git prune
>
> Is there an "easier" way to pull into a dirty directory ?
I'm using:
$ git config --global alias.update '!git stash && git pull && git stash
apply'
Then in a git repository just do:
$ git update
> ps; if someone is interested to hear what is the general opinion
> on switching to git from svn in our company, I could elaborate.
Would be nice to hear about that indeed.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711061230540.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> changes to <path>, relative to the index" (which would be the same as "git
> checkout <path>"), then committing that change just does not make sense.
>
> And it is this behaviour that people are seeking, not "git revert <commit>
> <path>".
Heh, I found this in the recent log somewhere.
<gitte> Really, I wonder how difficult git is for people who are not
brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
<gitte> From a user perspective, you might be correct. But then we have to
add 1000 commands to reflect the English language.
<gitte> Not what I want. [06:46]
I am wondering who said it ;-).
But anyway, I am inclined to agree that accepting "$scm revert
paths.." as a synonym for "git checkout -- paths..."
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-06 17:56 UTC (permalink / raw)
To: Nicolas Pitre, Daniel Barkalow, Jeff King, Git ML
In-Reply-To: <20071105175654.GD6205@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On the same vein, with today's next:
$ git push origin :teaser
To ssh://git.corp/srv/git/mmsx.git
- [deleting] teaser
refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
Everything up-to-date
fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-06 17:52 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Steffen Prohaska, Abdelrazak Younes, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711060857140.8577@ds9.cixit.se>
Peter Karlsson a écrit :
> I got errors almost right away when trying that (I need text mode to
> interface with some other programs), so Cygwin-git is a no-go for me at
Won't it be possible for you to have a specific mount point using
textmode and one with binmode ? This should allow you to have the best
of both world. Note that I've never done that so I don't know if it is
working fine.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Wincent Colaiuta @ 2007-11-06 17:43 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Junio C Hamano, Steven Grimm, git
In-Reply-To: <20071106124833.GA25637@artemis.corp>
El 6/11/2007, a las 13:48, Pierre Habouzit escribió:
> On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> In the same way, I would expect "git revert <commit> -- file" to
>>>>> undo the
>>>>> changes in that commit to _that_ file (something like "git merge-
>>>>> file
>>>>> file <commit>:file <commit>^:file"), but this time commit it,
>>>>> since it
>>>>> was committed at one stage.
>>>>
>>>> Allowing people to revert or cherry pick partially by using
>>>> paths limiter is a very good idea; ...
>>>
>>> As Pierre said earlier, a partial revert via "revert <commit> --
>>> <paths>" and a partial cherry-pick would make quite a lot of
>>> sense, and in addition, it should not be too hard to add.
>>
>> Yes, but Pierre also said earlier that people want to revert their
>> local
>> changes. And the logical thing to try that really is
>>
>> git revert <path>
>>
>> Now, if you read that out in English, it does not make too much
>> sense:
>> "revert the path" (not "revert the _changes_ to that file"). But
>> it is
>> what people try to do.
>>
>> However, IIUC another thing Pierre mentioned is that
>>
>> $scm revert <commit> <path>
>>
>> commonly means "revert the file _to the version_ stored in <commit>".
>> This is just different enough from "revert the _changes_ to that file
>> stored in <commit>" to bite people, no?
>
> Yeah but that's what checkout is for. The main source of iritation
> for
> new users comes (IMHO) from svn, where `svn revert path/to/file` is
> part
> of the workflow: in case of a conflict when you `svn up`, you have
> either to:
> (1) fix the conflict and `svn resolved path/to/file`
> (2) drop your changes and take the trunk version `svn revert path/
> to/file`
>
> People really expect git revert -- path/to/file to do the same as git
> checkout HEAD -- path/to/file. Though I believe that like I said,
> maybe
> we don't wan't git revert -- path/to/file to become the first class
> command to do that, but rather to do what the user meant, hinting
> him in
> the direction of the proper command. I wasn't really advocating that
> git-revert should be a complete implementation of what git checkout
> <comitish> -- <paths> does. YMMV.
I agree; they're semantically different and it wouldn't be a good
thing to start blurring the lines between them too much. It's just
unfortunate that the term "revert" is used by most other SCMs to mean
something different than what it means in "git-revert". I think the
best path here is education, what Pierre says, rather than changing
git-revert's semantics.
The other changes discussed so far in this thread (path-limiting git-
revert with preserving its semantics) seem like a good thing.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-06 17:08 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <1194367619.20020.9.camel@hinata.boston.redhat.com>
On 2007.11.06 11:46:59 -0500, Kristian Høgsberg wrote:
> On Tue, 2007-11-06 at 07:59 +0100, Björn Steinbrink wrote:
> ...
> > Note though, that Kristian had a similar check at the end of his email,
> > that included "only" (but lacked the bool conversion). The original
> > reason why I thought that it would be better was that for example
> > "git commit --all --only foo" didn't care about "only" at all. But that
> > actually was because the --all + paths usage check was broken. So the
> > fixed version actually refuses to use accept that, but with a (IMHO) not
> > so good error message:
> >
> > $ git commit -a -o file
> > Paths with -a does not make sense.
> >
> > Given that some people are used to just pass -a all the time, they might
> > just automatically pass it together with -o. And I think that we
> > actually want to tell them that -a + -o makes no sense instead. Just
> > like we do for -a + -i, which is kind of the complementary usage error.
> >
> > So I'd go for a correct version of Kristian's suggestion:
> >
> > if (!!also + !!only + !!all + !!interactive > 1)
> > die("Only one of --include/--only/--all/--interactive can be used.");
>
> Good points, I will use that in the next version of the patch. Just a
> note about the !! idiom (which I can't stand, fwiw): my version just
> added the variables, which were all integers, initialized to zero and
> incremented by the option parser when it sees the corresponding option.
> So what I had would work too, with the extra check that:
>
> $ git commit -a -a
>
> etc would give the error
>
> Only one of --include/--only/--all/--interactive can be used.
>
> which is acutally accurate.
Hm, why? The user used only one of them. The error message does not say
that you cannot pass the same one multiple times. And I don't think that
passing the same boolean flag twice should be treated as an usage error
either. There's no contradiction in wanting all files and, well, all
files to be committed.
Sidenote: The "or mask" stuff in the option parser would probably
prevent you from catching "-a -a" anyway, because the flag becomes truly
boolean ;-)
Björn
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Karl Hasselström @ 2007-11-06 16:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Alex Riesen, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711061550580.4362@racer.site>
On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> On Tue, 6 Nov 2007, Jeff King wrote:
>
> > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> >
> > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > the absence of patches. You could forget to save some patches,
> > > yes, but the presence of cur/ and new/ is no indicator for that.
> >
> > Read my message again. Alex is proposing ignoring errors in
> > opening the directories; I am proposing ignoring such errors
> > _only_ when the error is that the directory does not exist.
> >
> > IOW, if there is some other error in opening the directory, it
> > should be fatal, because you might be missing patches.
>
> Yeah, sorry, I missed that.
I think it might actually not be totally unreasonable to error out
unless both directories exist. From
http://www.qmail.org/qmail-manual-html/man5/maildir.html:
A directory in maildir format has three subdirectories, all on the
same filesystem: tmp, new, and cur.
In other words, if it doesn't have these three directories, it isn't a
Maildir directory.
On the other hand, one could argue that requiring both dirs to exist
is being too picky.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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