Assuming you tried this out on both 2.x and 3.x:
Acked-by: Sverre Rabbelier
On Fri, Jan 18, 2013 at 2:32 AM, John Keeping wrote:
> On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
>> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping wrote:
>> > [1] http://wiki.python.org/moin/Por
Torsten Bögershausen writes:
> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?
It may hide the immediate issue, but I am afraid Jonathan's patch
does not fix anything fundamental. If you do this:
git checkout next
Use one TAB for indentation and remove empty lines
Signed-off-by: Torsten Bögershausen
---
t/t0050-filesystem.sh | 48 +++-
1 file changed, 15 insertions(+), 33 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index a6fa3c5..05d
The test case "add (with different case)" indicates a
known breakage when run on a case sensitive file system.
The test is invalid for case sensitive file system,
check the precondition CASE_INSENSITIVE_FS before running it.
Signed-off-by: Torsten Bögershausen
---
t/t0050-filesystem.sh | 2 +-
This test case has passed ever since:
commit 0047dd2fd1fc1980913901c5fa098357482c2842
Author: Steffen Prohaska
Date: Thu May 15 07:19:54 2008 +0200
t0050: Fix merge test on case sensitive file systems
Demand it to pass by using test_expect_success
Signed-off-by: Torsten Bögershausen
---
On 01/19/2013 01:37 AM, Junio C Hamano wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in t
On 12-10-20, Herman van Rink wrote:
> On 10/19/2012 03:21 PM, Yann Dirson wrote:
> > As the examples in git-subtree.txt show, the synopsis in the same file
> > should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P
> > +'git subtree' add -P
> >
> > Failure to spec
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are inter
On 18.01.13 23:23, Jean-Noël AVILA wrote:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano writes:
>>> How about doing something like this and set that variable in the
>>> test instead? If STD_ONLY is not set, you will get everything, but
>>> when STD_ONLY is set
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typi
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
jus
This is an early preview of reducing the network cost while talking
with a repository with tons of refs, most of which are of use by
very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
useful only for people who are interested in the changes under
review). As long as these narrow aud
Eric Wong writes:
> I've pushed this out to git://bogomips.org/git-svn along with a few
> other things I seem to have forgotten about :x
>
> John Keeping (1):
> git-svn: teach find-rev to find near matches
>
> Jonathan Nieder (2):
> Git::SVN::Editor::T: pass $deletions to ->A and ->D
Jeff King writes:
> When we advertise a ref, the first thing we do is parse the
> pointed-to object. This gives us two things:
>
> 1. a "struct object" we can use to store flags
>
> 2. the type of the object, so we know whether we need to
> dereference it as a tag
>
> Instead, we can jus
From: "David Lang"
Sent: Friday, January 18, 2013 9:27 PM
On Fri, 18 Jan 2013, Junio C Hamano wrote:
David Lang writes:
What I would do is to have each developer have their own local copy
that they are working on.
If you have a third machine to host the bare 'master' repo that would
pro
On Fri, Jan 18, 2013 at 02:26:06PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>>> These early versions may not be unstable in the "this does not
>>> behave as specified in the language specification for 3.x" sense,
>>> but
Junio C Hamano writes:
> "Jean-Noël AVILA" writes:
>
>> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>>> Junio C Hamano writes:
>>> > How about doing something like this and set that variable in the
>>> > test instead? If STD_ONLY is not set, you will get everything, but
>>>
"Jean-Noël AVILA" writes:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano writes:
>> > How about doing something like this and set that variable in the
>> > test instead? If STD_ONLY is not set, you will get everything, but
>> > when STD_ONLY is set, we will s
John Keeping writes:
> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>> As more people have started trying to support Python 3 in the wild, it
>>> has become clear that it is often easier to have a single codebase that
>>> works with both Python 2 and P
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> Junio C Hamano writes:
> > How about doing something like this and set that variable in the
> > test instead? If STD_ONLY is not set, you will get everything, but
> > when STD_ONLY is set, we will stop reading from "help -a" when it
On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> As more people have started trying to support Python 3 in the wild, it
>> has become clear that it is often easier to have a single codebase that
>> works with both Python 2 and Python 3, and not use 2to3.
>>
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
>
> But ultimately, there shouldn't be a question of "if" you
> have a master repository but "where" you have the master repository, correct?
> Or in other words, it doesn't seem like you'd want
David Lang writes:
> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang writes:
>> ...
>>> developers then do their work locally, and after a change has been
>>> reviewed, pull it into the master repository.
>>
>> s/pull it into/push it into/; I think.
>
> fair enough, I always think in
On Fri, 18 Jan 2013, Junio C Hamano wrote:
David Lang writes:
What I would do is to have each developer have their own local copy
that they are working on.
I would then find a machine that is going to be on all the time (which
could be a developer's desktop), and create a master repository
t
David Lang writes:
> What I would do is to have each developer have their own local copy
> that they are working on.
>
> I would then find a machine that is going to be on all the time (which
> could be a developer's desktop), and create a master repository
> there. Note that if this is on a deve
Junio C Hamano writes:
> Jeff King writes:
>
>> ... did you have any comment on
>> the "struct config_key" alternative I sent as a follow-up?
>
> I did read it but I cannot say I did so very carefully. My gut
> reaction was that the "take the variable name and section name,
> return the subsect
"Dmitry V. Levin" writes:
> This fixes "hg" patch format support for locales other than C and en_*.
> Before the change, git-am was making "Date:" line from hg changeset
> metadata according to the current locale, and this line was rejected
> later with "invalid date format" diagnostics because l
What I would do is to have each developer have their own local copy that they
are working on.
I would then find a machine that is going to be on all the time (which could be
a developer's desktop), and create a master repository there. Note that if this
is on a developers desktop, this needs t
John Keeping writes:
>>> + - Where required libraries do not restrict us to Python 2, we try to
>>> + also be compatible with Python 3. In this case we use
>>> + `from __future__ import unicode_literals` if we need to differentiate
>>> + Unicode string literals, rather than prefixing Unico
Junio C Hamano writes:
> How about doing something like this and set that variable in the
> test instead? If STD_ONLY is not set, you will get everything, but
> when STD_ONLY is set, we will stop reading from "help -a" when it
> starts listing additional stuff.
>
> contrib/completion/git-comple
On Fri, Jan 18, 2013 at 11:04:15AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
>> index 69f7e9b..baf3b41 100644
>> --- a/Documentation/CodingGuidelines
>> +++ b/Documentation/CodingGuidelines
>> @@ -179,6 +1
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x
On Fri, Jan 18, 2013 at 11:08 AM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab
>> wrote:
>>> Brandon Casey writes:
>>>
+ array[$(($#array+1))]="$c"
>>>
>>> You don't need $(( )) since the array index is alre
Brandon Casey writes:
> On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab wrote:
>> Brandon Casey writes:
>>
>>> + array[$(($#array+1))]="$c"
>>
>> You don't need $(( )) since the array index is already evaluated as an
>> arithmethic expression.
>
> Ah, I didn't know t
On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab wrote:
> Brandon Casey writes:
>
>> + array[$(($#array+1))]="$c"
>
> You don't need $(( )) since the array index is already evaluated as an
> arithmethic expression.
Ah, I didn't know that. Thanks.
I think Junio will p
John Keeping writes:
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 69f7e9b..baf3b41 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -179,6 +179,22 @@ For C programs:
> - Use Git's gettext wrappers to make the use
Thanks for the reply. I'm afraid this question has become moot. I can no
longer reproduce the problem as it is now working as expected. I did
find an incorrect ownership on one of the 'objects' sub-directories but
I would think that should have given me an error. Perhaps I used root at
the wrong ti
Timothy Kretschmer venit, vidit, dixit 18.01.2013 17:59:
> The exact names of the branches are "CMT_PHASE3" and
> "BlueSimViewer5.0_20110316_Branch"
Just to be sure, not to doubt you: the svn branch name is
"BlueSimViewer5.0_20110316_Branch" and thus differs from the name
reported by git-svn? Are
On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord wrote:
>
> Yes, I can tell by the wording of the error message that you are right
> and clang has a problem. But the git code it complained about does
> have a real problem, because the result of "signed int a = ULONG_MAX"
> is implementation-defined.
O
Hi Matt and David,
Your responses have been very helpful for this newbie...thanks very much! I
have a good sense now of the difference btw a CVCS and a DVCS. Here are two
more questions...
1. I now get the sense that there's quite a few options in regards to the way
that any one group implemen
On Thu, Jan 17, 2013 at 9:14 AM, Dennis Putnam wrote:
> As a git noob I am having trouble understanding when to use which
> commands. I have a repository (bare) on my Linux server. I also created
> a build directory as a local repository. In my build script I do a 'git
> pull' to make sure the bui
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [2], there isn't any disagreement about using
2.6 as a base (see also [3]).
- T
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
Eric
On 01/17/2013 12:17 PM, Pyeron, Jason J CTR (US) wrote:
Sorry, I am in cygwin mode, and I had crossed wires in my head.
s/ProcessMon/stra
On Thu, Jan 17, 2013 at 11:44 AM, Linus Torvalds
wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk,
>> which
>> I think is a legitimate warning - perhaps someone who understands integer
>> type
>> promotio
Michael Haggerty writes:
> On 01/18/2013 01:14 AM, Junio C Hamano wrote:
>> [...]
>> * mh/imap-send-shrinkage (2013-01-15) 14 commits
>> - imap-send.c: simplify logic in lf_to_crlf()
>> - imap-send.c: fold struct store into struct imap_store
>> - imap-send.c: remove unused field imap_store::ui
Jonathan Nieder writes:
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, fo
Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
> I am seeing the following output while converting a subversion repo to git.
>
> >Found possible branch point: /trunk =>
> /branches/CMT_PHASE3, 18441
>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 Branch
>> cat-
On 01/18/2013 01:14 AM, Junio C Hamano wrote:
> [...]
> * mh/imap-send-shrinkage (2013-01-15) 14 commits
> - imap-send.c: simplify logic in lf_to_crlf()
> - imap-send.c: fold struct store into struct imap_store
> - imap-send.c: remove unused field imap_store::uidvalidity
> - imap-send.c: use st
Brandon Casey writes:
> + array[$(($#array+1))]="$c"
You don't need $(( )) since the array index is already evaluated as an
arithmethic expression.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276
On Mon, 31 Dec 2012 20:51:41 -0600
gree...@obbligato.org wrote:
> Yann Dirson writes:
>
> > As the examples in git-subtree.txt show, the synopsis in the same file
> > should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P
> > +'git subtree' add -P
> >
> > Failu
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping wrote:
> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>
> This link seems dead.
Looks like the Python wiki is down [1].
I'll replace it with [2] since the content is simil
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x
52 matches
Mail list logo
