On Thu, Jun 6, 2013 at 1:44 AM, Jeff King wrote:
> On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:
>
>> > Thanks. I wasn't quite clear on how the signal handling worked on
>> > Windows, but from your description, I agree there is not any point in
>> > running the test at all.
>>
On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:
> > Thanks. I wasn't quite clear on how the signal handling worked on
> > Windows, but from your description, I agree there is not any point in
> > running the test at all.
>
> Shouldn't we clarify that Git exit codes only work on
On Thu, Jun 6, 2013 at 1:37 AM, Jeff King wrote:
> On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:
>
>> From: Johannes Sixt
>>
>> The test case depends on that test-sigchain can commit suicide by a call
>> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
>>
On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:
> From: Johannes Sixt
>
> The test case depends on that test-sigchain can commit suicide by a call
> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
> as death through a signal. There are no POSIX signals on
From: Johannes Sixt
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Micro
On Wed, Jun 5, 2013 at 1:13 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
You didn't answer, what happens when you run --skip-empty and
--allow-empty?
>>>
>>> I'll answer to a slightly
From: Wieland Hoffmann
Signed-off-by: Wieland Hoffmann
---
po/de.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index 4901488..cd6919f 100644
--- a/po/de.po
+++ b/po/de.po
@@ -885,7 +885,7 @@ msgstr[1] "Ihr Zweig ist vor '%s' um %d Versionen.\n"
#:
On Thu, Jun 6, 2013 at 12:09 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Jun 5, 2013 at 4:12 AM, Eric Sunshine
>> wrote:
+Caveats:
+
+1. Many of the placeholders in "PRETTY FORMATS" are designed to work
+ specifically on commit objects: when non-commit obje
If we are traversing trees during a "--objects"
traversal, we may skip blobs if the "blob_objects" field of
rev_info is not set. But we do so as the first thing in
process_blob(), only after we have actually created the
"struct blob" object, incurring a hash lookup. We can
optimize out this no-op c
When serving a remote request, git-upload-archive tries to
restrict access to unreachable objects, which matches the
behavior of upload-pack. However, we did so by restricting
the requested tree to "[:]", because it is fast.
That covers the common cases, but does not allow requesting
items by a spe
We cannot create an archive from a blob object, so we would
not expect anyone to provide one to us. And if they do, we
will fail anyway just after the reachability check. We can
therefore optimize our reachability check to ignore blobs
completely, and not even create a "struct blob" for them.
Dep
Many code paths will free a tree object's buffer and set it
to NULL after finishing with it in order to keep memory
usage down during a traversal. However, out of 8 sites that
do this, only one actually unsets the "parsed" flag back.
Those sites that don't are setting a trap for later users of
the
On Wed, Jun 05, 2013 at 12:38:23PM -0400, Jeff King wrote:
> 2. Actually do a reachability check. Doing a full object check to
> allow fetching an arbitrary tree by sha1 is probably prohibitively
> expensive[2], but we could allow the form "[:]", check
> that "" is reachable, and
Am 05.06.2013 00:04, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> @@ -62,12 +57,7 @@ test_expect_success 'git update-index to add conflicting
>> file path2 should fail'
>>
>> test_expect_success 'git update-index to add conflicting symlink path3
>> should fail' '
>>
>> -if test
On Wed, Jun 05, 2013 at 12:28:08PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > This includes bugfixes related to handling of --suppress-cc=self
> > flag. Tests are also included.
> >
> > Changes from v3:
> > - v3 submission was missing one patch (1/7). Re-add it.
> > Cha
Am 04.06.2013 23:55, schrieb Junio C Hamano:
> Johannes Sixt writes:
>> diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
>> index 88be904..563ac7f 100755
>> --- a/t/t3000-ls-files-others.sh
>> +++ b/t/t3000-ls-files-others.sh
>> @@ -19,12 +19,7 @@ filesystem.
>>
>> test_expe
Am 04.06.2013 23:06, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> There are many instances where the treatment of symbolic links in the
>> object model and the algorithms are tested, but where it is not
>> necessary to actually have a symbolic link in the worktree. Make
>> adjustments to
"Michael S. Tsirkin" writes:
> This includes bugfixes related to handling of --suppress-cc=self
> flag. Tests are also included.
>
> Changes from v3:
> - v3 submission was missing one patch (1/7). Re-add it.
> Changes from v2:
> - add a new test, split patches differently add code com
Charles McGarvey writes:
> The bug is manifest when running gitweb in a persistent process (e.g.
> FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
> includes the searchtext parameter (i.e. s), subsequent requests using
> the project_list action--which is the default action--and w
Felipe Contreras writes:
> On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> You didn't answer, what happens when you run --skip-empty and --allow-empty?
>>
>> I'll answer to a slightly different question: What should happen?
>>
>> I think it should error
This includes bugfixes related to handling of --suppress-cc=self
flag. Tests are also included.
Changes from v3:
- v3 submission was missing one patch (1/7). Re-add it.
Changes from v2:
- add a new test, split patches differently add code comments
to address commen
Michael Haggerty writes:
> For completeness, let me point out two other small advantages of contrib:
>
> * a tool in contrib can assume that it is being bundled with the
> corresponding version of Git, and therefore doesn't necessarily have to
> go to the effort of supporting older versions of Gi
Duy Nguyen writes:
> On Wed, Jun 5, 2013 at 4:12 AM, Eric Sunshine wrote:
>>> +Caveats:
>>> +
>>> +1. Many of the placeholders in "PRETTY FORMATS" are designed to work
>>> + specifically on commit objects: when non-commit objects are
>>> + supplied, those placeholders won't work.
>>
>> Shoul
On Wed, May 29, 2013 at 12:05:41PM +, Ian Harvey wrote:
> So, did this patch make it anywhere? We could really use it.
>
> Here's the use case. The original ee27ca4 patch broke our build system when
> the git server was upgraded to Debian Wheezy last night. The builder fetches
> source from t
Hi,
I'm having issues with a Git hosting in a chroot (based on fusion
forge). The problem is that receive-pack triggers a "git gc --auto",
which itself triggers a "git repack", which is a shell-script.
The shell script needs basic commands [1], which are not available within the
chroot.
Is there
On Wed, Jun 05, 2013 at 10:34:11AM +0300, Orgad Shaneh wrote:
> Running "git rev-parse --show-toplevel" doesn't print anything when it
> is run inside .git dir (on all levels)
This is by design. "--show-toplevel" does not print anything when you
do not have a working tree, and you do not have one
Excellent response. I had not even considered that the hook for creating
these tags would be in the mix.
I withdraw my bug report happily :)
Thanks,
Roy Lyons
On 6/5/13 10:51 AM, "Jeff King" wrote:
>On Wed, Jun 05, 2013 at 03:26:18PM +, Lyons, Roy wrote:
>
>> $ git push origin :ABRA
On Wed, Jun 05, 2013 at 12:58:00PM +0200, benoit.per...@ensimag.fr wrote:
> From: Benoit Person
>
> In 52dce6d, a new credential function was added to Git.pm, based on
> git-remote-mediawiki's functions. The logical follow-up is to use
> those functions in git-remote-mediawiki.
>
> Signed-off-b
On Wed, Jun 05, 2013 at 03:26:18PM +, Lyons, Roy wrote:
> $ git push origin :ABRANCHNAME
> remote: Firing Pre - receive hook
> remote:
> remote:
> remote: Firing Post receive hook
> remote:
> remote: Branch is ABRANCHNAME -- not creating Trigger file since this is not
> _int branch
> remote:
On Wed, Jun 05, 2013 at 01:19:18PM +0200, Ian Kumlien wrote:
> > Older versions of git silently ignored errors reading config files, but
> > it was tightened in v1.8.1.1, as there can be quite serious implications
> > to failing to read expected config (e.g., imagine transfer.fsckobjects,
> > or r
$ git push origin :ABRANCHNAME
remote: Firing Pre - receive hook
remote:
remote:
remote: Firing Post receive hook
remote:
remote: Branch is ABRANCHNAME -- not creating Trigger file since this is not
_int branch
remote: error: Trying to write ref
refs/tags/ABRANCHNAME!SN-BL-20130605_100513_04363 w
On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> You didn't answer, what happens when you run --skip-empty and --allow-empty?
>
> I'll answer to a slightly different question: What should happen?
>
> I think it should error out, because --allow-empty is about
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
> I however do not know how much extra burden it would place to add
> dependencies to platform folks, so obviously the safer approach is 1
> at least in the immediate future. My understanding is that msysgit
> folks
On Tue, Jun 4, 2013 at 10:02 PM, David Lang wrote:
> On Tue, 4 Jun 2013, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>>
>> On Ruby:
>>
>> Assuming "related" is a good idea, to make it as the proper part of
>> the system out of contrib/ when its design review phase is finished,
>> one of
On Wed, Jun 5, 2013 at 4:12 AM, Eric Sunshine wrote:
>> +Caveats:
>> +
>> +1. Many of the placeholders in "PRETTY FORMATS" are designed to work
>> + specifically on commit objects: when non-commit objects are
>> + supplied, those placeholders won't work.
>
> Should "won't work" be expanded upo
On Wed, 05 Jun 2013 13:19:18 +, Ian Kumlien wrote:
...
> Well, I have no idea of how to control HOME in xinetd - access to the
> machine is limited and x doesn't give that much access (nothing really
> important is actually stored in /root)
Make xinetd execute '/usr/bin/env HOME=/home/yourstru
On Tue, Jun 04, 2013 at 12:08:15PM -0400, Jeff King wrote:
> On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote:
>
> > Due to the earlier problem I upgraded git on all machines
> > and eneded up with a ubunut machine running in to problems.
> >
> > I started getting errors like:
> > "fa
From: Benoit Person
In 52dce6d, a new credential function was added to Git.pm, based on
git-remote-mediawiki's functions. The logical follow-up is to use
those functions in git-remote-mediawiki.
Signed-off-by: Benoit Person
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/git-remote-mediawik
On Wed, Jun 5, 2013 at 3:14 PM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>> I mentioned it before and I do it again. This is not optimal.
>
> Yeah, I'll attempt to fix this, but it's not urgent.
Agreed it's not urgent.
>> But I guess it's ok in this
>> shape unless you run this over hundr
On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote:
> On Tue, Jun 4, 2013 at 8:48 AM, John Keeping wrote:
> > The problem is that sometimes you do want to adjust the path and
> > sometimes you don't. Reading git-submodule(1), it says:
> >
> > This may be either an absolute URL, or (if
Duy Nguyen wrote:
> I mentioned it before and I do it again. This is not optimal.
Yeah, I'll attempt to fix this, but it's not urgent.
> But I guess it's ok in this
> shape unless you run this over hundreds of refs.
Oh, you can run over a hundred refs just fine, for scripting purposes;
but why w
Duy Nguyen wrote:
> I'm still hung up one the detached HEAD thing. It's a bit quirky to
> put in for-each-ref, but for-each-ref can't truly replace branch
> --list until it can display detached HEAD. But I think we can finish
> this part and get it in first. Should be useful for some people
> alrea
Running "git rev-parse --show-toplevel" doesn't print anything when it
is run inside .git dir (on all levels)
- Orgad
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
Sending again, the list strips html
>Oh many thanks for your answer Jeff!
>I was wondering about a fault in my side!
>I was already building 1.8.3 when I sent the first mail...
>Anyway
your software has a bunch of tests that make compilation a little slow
(and no, I don't want to disable them, t
OH, I see...
Just ubuntu is syncing from debian experimental...
https://launchpad.net/ubuntu/+source/git
Gianfranco
>
> Da: Jeff King
>A: Gianfranco Costamagna
>Cc: "git@vger.kernel.org"
>Inviato: Mercoledì 5 Giugno 2013 9:10
>Oggetto: Re: git archive --
On Wed, Jun 05, 2013 at 08:59:15AM +0200, Johannes Sixt wrote:
> Am 6/5/2013 1:45, schrieb Junio C Hamano:
> > * jk/test-exit-code-by-signal (2013-06-02) 1 commit
> > (merged to 'next' on 2013-06-03 at 25af892)
> > + t0005: test git exit code from signal death
> >
> > Will merge to 'master'.
On Wed, Jun 05, 2013 at 07:10:01AM +0100, Gianfranco Costamagna wrote:
> Just a question, is it possible to add a new test for handling this
> kind of regressions?
Yes, I added one in commit efa5f825.
> And second, is it possible to have a patch for this problem? I'll be
> glad to backport in de
Am 6/5/2013 1:45, schrieb Junio C Hamano:
> * jk/test-exit-code-by-signal (2013-06-02) 1 commit
> (merged to 'next' on 2013-06-03 at 25af892)
> + t0005: test git exit code from signal death
>
> Will merge to 'master'.
I haven't gotten around to run this new test on Windows. I've reason to
bel
48 matches
Mail list logo
