On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote:
> On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker
> wrote:
> > On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote:
> >> Duy Nguyen writes:
> >>
> >> > On Mon, Dec 2, 2013 at 2:04 AM, Dennis Kaarsemaker
> >> > wrote:
> >> >> We always ignore
On 02/12/2013 14:40, Trần Ngọc Quân wrote:
> On 02/12/2013 12:57, Duy Nguyen wrote:
>>> I suggest use C preprocessor instead. The person who complete git (make
>>> debian, rpm etc. package) decide enable it or not (disable by default).
>>> Most of people use git from distribution instead of comp
On Mon, Dec 2, 2013 at 2:40 PM, Trần Ngọc Quân wrote:
> On 02/12/2013 12:57, Duy Nguyen wrote:
>>> I suggest use C preprocessor instead. The person who complete git (make
>>> debian, rpm etc. package) decide enable it or not (disable by default).
>>> Most of people use git from distribution ins
On Mon, Dec 2, 2013 at 3:01 PM, Dennis Kaarsemaker
wrote:
> On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote:
>> On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker
>> wrote:
>> > On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote:
>> >> Duy Nguyen writes:
>> >>
>> >> > On Mon, Dec 2, 2013 at
Hi,
When directory/ does not exist, I'd expect this to fail:
git mv existing-file directory/
(note the trailing slash, to make it clear that directory/ is a
directory). Unix's mv does fail:
$ mv existing-file directory/
mv: cannot move `existing-file' to `directory/': Not a directory
Ins
Paul Mackerras wrote:
> On Thu, Nov 28, 2013 at 11:20:18PM +0200, Max Kirillov wrote:
> > Custom tags have higher priority than `sel`, and when they define their
> > own background, it makes selection invisible. Especially inconvenient
> > for `filesep` (to select filenames), but also affects oth
On Thu, 2013-11-28 at 20:13 -0500, Eric Sunshine wrote:
> On Thu, Nov 28, 2013 at 6:44 AM, Krzesimir Nowak
> wrote:
> > Allow @additional_branch_refs configuration variable to tell gitweb to
> > show refs from additional hierarchies in addition to branches in the
> > list-of-branches view.
> >
>
Thomas Rast wrote:
> When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection,
> passing its ->new all the options that would otherwise go to
> Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the
> SSL options).
>
> However, while Net::SMTP::SSL replaces the underlying socke
Matěj Cepl wrote:
> I am trying to git-svn clone
> https://svn.calendarserver.org/repository/calendarserver/CalendarServer/
> and I cannot say I am much succesful.
Consider using (the somewhat experimental) git-remote-testsvn and the
underlying contrib/svn-fe/. For starters, try:
$ git clone
t
On ma, 2013-12-02 at 16:35 +0700, Duy Nguyen wrote:
> On Mon, Dec 2, 2013 at 3:01 PM, Dennis Kaarsemaker
> wrote:
> > On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote:
> >> On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker
> >> wrote:
> >> > On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote:
On Mon, Dec 2, 2013 at 6:40 PM, Dennis Kaarsemaker
wrote:
>> ~/w/git $ cd t
>> ~/w/git/t $ GIT_TRACE_SETUP=1 ../git --git-dir=../.git --work-tree=..
>> --no-pager status
>> setup: git_dir: /home/pclouds/w/git/.git
>> setup: worktree: /home/pclouds/w/git
>> setup: cwd: /home/pclouds/w/git
>> setup:
On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
> wrote:
>
> > Allow @additional_branch_refs configuration variable to tell gitweb to
> > show refs from additional hierarchies in addition to branches in the
> > list-of-branches view.
>
When git is compiled with current gcc and "-march=native"
git-blame segfaults:
For example:
% gdb --args /var/tmp/git/git-blame gcc/tree-object-size.c
...
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x0051
On Mon, Dec 02, 2013 at 11:04:06AM +0100, Matthieu Moy wrote:
> Hi,
>
> When directory/ does not exist, I'd expect this to fail:
>
> git mv existing-file directory/
>
> (note the trailing slash, to make it clear that directory/ is a
> directory). Unix's mv does fail:
>
> $ mv existing-file
On Mon, Dec 2, 2013 at 1:57 PM, Markus Trippelsdorf
wrote:
> When git is compiled with current gcc and "-march=native"
> git-blame segfaults:
>
> For example:
>
> % gdb --args /var/tmp/git/git-blame gcc/tree-object-size.c
> ...
> Program received signal SIGSEGV, Segmentation fault.
> 0x00
On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote:
> Here is a patch series to improve the way sha1_object_info_extended()
> behaves when it is passed a replaced object.
> [...]
> Christian Couder (5):
> replace_object: don't check read_replace_refs twice
> introduce lookup_repl
On 2013.12.02 at 15:15 +0100, Antoine Pelisse wrote:
> On Mon, Dec 2, 2013 at 1:57 PM, Markus Trippelsdorf
> wrote:
> > When git is compiled with current gcc and "-march=native"
> > git-blame segfaults:
> >
> > For example:
> >
> > % gdb --args /var/tmp/git/git-blame gcc/tree-object-size.c
> > ..
On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
> directly in lookup_replace_object. That means that it is now a
> meaningful flag for sha1_object_info_extended, even though the name does
> not say so. It also mean
On Sun, Dec 01, 2013 at 08:49:13AM +0100, Christian Couder wrote:
> This is a new patch series along the lines Junio suggested in this
> thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/238054/
>
> I send it now because I saw a 1.8.5 tag.
This looks sane to me. Your 4/5 did no
On Sun, Dec 01, 2013 at 09:41:55PM +0100, Thomas Rast wrote:
> When allocating the slab, the code accidentally computed the array
> size from s->slab (an elemtype**). The slab is an array of elemtype*,
> however, so we should take the size of *s->slab.
Looks obviously correct.
> I browsed aroun
On Fri, Nov 29, 2013 at 10:21:04PM +0100, Thomas Rast wrote:
> I do think it's worth fixing the syntax pedantry at the end so that we
> can keep supporting arcane compilers, but otherwise, meh.
Agreed. I've picked up those changes in my tree.
> > +static int open_pack_bitmap_1(struct packed_git
Duy Nguyen writes:
> This may be a start. Does not seem to break anything..
I did not thoroughly review/test, but it does fix my case. Below is the
same patch with one test case. No time to do more right now.
Thanks,
>From 99985341ed1312cf6a7b63e14be7da0d51c701b4 Mon Sep 17 00:00:00 2001
From:
W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
wrote:
Allow @additional_branch_refs configuration variable to tell gitweb to
show refs from additional hierarchies in addition to branch
Thomas Rast writes:
> The problem here is that shell scripts that want to do something with a
> worktree tend to call require_work_tree in git-sh-setup:
>
> require_work_tree () {
> test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
> die "fatal: $0 cannot be used wit
Krzesimir Nowak writes:
> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
>> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
>> wrote:
>>
>> > Allow @additional_branch_refs configuration variable to tell gitweb to
>> > show refs from additional hierarchies in addition to branches in
On Mon, Dec 2, 2013 at 7:18 PM, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
>>> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
>>> wrote:
>>>
>>> > Allow @additional_branch_refs configuration variable to tell gitweb to
>>> > show
Jeff King writes:
> On Sun, Dec 01, 2013 at 08:49:13AM +0100, Christian Couder wrote:
>
>> This is a new patch series along the lines Junio suggested in this
>> thread:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/238054/
>>
>> I send it now because I saw a 1.8.5 tag.
>
> This l
The latest feature release Git v1.8.5 is now available at the
usual places. This was actually tagged a few days ago, but I forgot
to send this release notes.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
56e4e3c59b0bd2996
From: Jonathan Nieder
Date: Mon, 25 Nov 2013 13:01:05 -0800
The Makefile only runs po/po2msg.sh using tclsh, but because the
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
The Windows git-gui wrapper is usable in-place for the same reason.
Signed-off-by:
From: Junio C Hamano
>
> Jeff King writes:
>
>> On Sun, Dec 01, 2013 at 08:49:13AM +0100, Christian Couder wrote:
>>
>>> This is a new patch series along the lines Junio suggested in this
>>> thread:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/238054/
>>>
>>> I send it now b
On Mon, Dec 2, 2013 at 8:29 PM, Christian Couder
wrote:
> From: Junio C Hamano
>>
>> Jeff King writes:
>>
>>> On Sun, Dec 01, 2013 at 08:49:13AM +0100, Christian Couder wrote:
>>>
This is a new patch series along the lines Junio suggested in this
thread:
http://thread.gmane.o
Seems that grep.exe is too outdated for some scripts:
https://github.com/creationix/nvm/issues/75#issuecomment-13735767
Updating to a newer grep distro fixes the problem:
https://github.com/creationix/nvm/issues/75#issuecomment-29054164
Seems other OSX & Linux don't have problems with the same sc
(cc-ing the msysgit@ group, which maintains Git for Windows)
Hi,
Tom Byrer wrote:
> Seems that grep.exe is too outdated for some scripts:
> https://github.com/creationix/nvm/issues/75#issuecomment-13735767
>
> Updating to a newer grep distro fixes the problem:
> https://github.com/creationix/nvm/
On Mon, Dec 2, 2013 at 8:36 PM, Tom Byrer wrote:
> Seems that grep.exe is too outdated for some scripts:
> https://github.com/creationix/nvm/issues/75#issuecomment-13735767
-o is not an option of POSIX grep [1] and you should probably not rely
on it for portable script.
[1]: http://pubs.opengrou
Jeff King writes:
> I do wonder if at some point we should revisit our "do not use any
> C99-isms" philosophy. It was very good advice in 2005. I don't know how
> good it is over 8 years later (it seems like even ancient systems should
> be able to get gcc compiled as a last resort, but maybe the
On Mon, Dec 02, 2013 at 12:36:34PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do wonder if at some point we should revisit our "do not use any
> > C99-isms" philosophy. It was very good advice in 2005. I don't know how
> > good it is over 8 years later (it seems like even ancient s
Zoltan Klinger writes:
> When --prompt option is set, git-difftool displays a prompt for each
> modified file to be viewed in an external diff program. At that point it
> could be useful to display a counter and the total number of files in
> the diff queue.
>
> Below is the current difftool prom
Jakub Narębski writes:
> I think that additional-branch-refs (or just branch-refs) is different enough
> from remote_heads feature (which is about showing "remotes" section
> in "summary" view, and IIRC adding "remotes" view) that it should be
> kept separate.
>
> On the other hand it is similar
From: Jonathan Nieder
Date: Mon, 25 Nov 2013 13:00:10 -0800
The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
Signed-off-by: Jonathan Nieder
Signed-off-by: Junio C Hamano
---
* Paul, I
Jeff King writes:
> Sorry, I was not very clear about what I said. I do not think "go get a
> newer gcc" is a good thing to be telling people. But I wonder:
>
> a. if there are actually people on systems that have pre-c99 compilers
> in 2013
>
> b. if there are, do they actually _use_ th
Hi,
I was getting core dumps (bus error 7) with git 1.7.1 when doing a
git checkout. I tried git fsck, and same thing. I got the same with
precompiled rpms of 1.7.12, and with a locally compiled version of git
1.8.5.
The simplest/quickest repro I got is using git-fsck. The stacktrace
blames SHA
Nguyễn Thái Ngọc Duy writes:
> This is the preparation for adding --shallow-file to both
> unpack-objects and index-pack. To sum up:
>
> - status/code, ip/child, unpacker/keeper and i (now ac) are moved out
>to function top level
>
> - successful flow now ends at the end of the function
>
Ramkumar Ramachandra writes:
> Thomas Rast wrote:
>> When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection,
>> passing its ->new all the options that would otherwise go to
>> Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the
>> SSL options).
>>
>> However, while Net::
I wanted to explore the idea of exploiting knowledge about
previous repacks to help speed up future repacks.
I had various ideas that seemed like they might be good
places to start, but things quickly got away from me.
Mainly I wanted to focus on reducing and even sometimes
eliminating reac
When the built-in "git tar-tree" command (a thin wrapper around "git
archive") was removed in 925ceccf (tar-tree: remove deprecated
command, 2013-11-10), the build continued to install a non-functioning
git-tar-tree command in gitexecdir by mistake:
$ PATH=$(git --exec-path):$PATH
Jeff King writes:
> On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
>
>> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
>> directly in lookup_replace_object. That means that it is now a
>> meaningful flag for sha1_object_info_extended, even though the name does
On 27 Nov 2013, at 11:43, Junio C Hamano wrote:
> Nick Townsend writes:
>
>> On 26 Nov 2013, at 14:18, Junio C Hamano wrote:
>>
>>> Even if the code is run inside a repository with a working tree,
>>> when producing a tarball out of an ancient commit that had a
>>> submodule not at its curre
Begin forwarded message:
> From: Nick Townsend
> Subject: Re: [PATCH] submodule recursion in git-archive
> Date: 2 December 2013 16:00:50 GMT-8
> To: Junio C Hamano
> Cc: René Scharfe , Jens Lehmann ,
> git@vger.kernel.org, Jeff King
>
>
> On 27 Nov 2013, at 11:43, Junio C Hamano wrote:
>
From: Nick Townsend
Subject: Re: [PATCH] submodule recursion in git-archive
Date: 2 December 2013 15:55:36 GMT-8
To: Heiko Voigt
Cc: Junio C Hamano , René Scharfe , Jens
Lehmann , git@vger.kernel.org, Jeff King
On 29 Nov 2013, at 14:38, Heiko Voigt wrote:
> On Wed, Nov 27, 2013 at 11:43:44
As per the previous patch request, I’ve delayed the work on git-archive.
However the following two patches (attached as replies) should still
be considered.
Kind Regards
Nick--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
From: Nick Townsend
Date: Mon, 25 Nov 2013 15:31:09 -0800
Subject: [PATCH 1/2] submodule: add_submodule_odb() usability
Although add_submodule_odb() is documented as being
externally usable, it is declared static and also
has incorrect documentation. This commit fixes those
and makes no changes
From: Nick Townsend
Date: Sat, 30 Nov 2013 16:54:20 -0800
Subject: [PATCH 2/2] Additional git-archive tests
Interplay between paths specified in three ways now tested:
* After a : in the tree-ish,
* As a pathspec in the command,
* By virtue of the current working directory
Note that these tests
On Mon, Dec 02, 2013 at 11:04:09AM +0100, Stefan Haller wrote:
> I don't think that not selecting the search hint is an
> option: the selection is used to keep track of where to
> search next.
To mark the next found position, should a 0-length selection
be enough? I will try to experiment with it.
Martin Fick writes:
> I wanted to explore the idea of exploiting knowledge about
> previous repacks to help speed up future repacks.
>
> I had various ideas that seemed like they might be good
> places to start, but things quickly got away from me.
> Mainly I wanted to focus on reducing and
On Tue, Dec 3, 2013 at 7:44 AM, Junio C Hamano wrote:
>> * Scenario 4:
>>
>>Starts with Setup 1. Add some loose objects to the repo
>> via a local fast forward ref update (I am assuming this is
>> possible without adding any new unreferenced objects?)
>>
>>
>> In all 4 scenarios, I believe we
When I started learning Git, I spent a fair amount of time
reading Pro Git. I found that it was a 2 steps forward, 1
step back experience. By this I mean I’d learn a couple of
new things but then I’d either read something I didn’t
understand, or else I’d realize that my previous
understanding was
On Mon, Dec 2, 2013 at 8:32 PM, Antoine Pelisse wrote:
> On Mon, Dec 2, 2013 at 8:29 PM, Christian Couder
> wrote:
>> From: Junio C Hamano
>>>
>>> Jeff King writes:
>>>
This looks sane to me. Your 4/5 did not make it to the list (nor
directly to me), though. Perhaps because it is huge
Duy Nguyen writes:
>> If nothing else has happened in the repository, perhaps, but I
>> suspect that the real problem is how you would prove it. For
>> example, I am guessing that your Scenario 4 could be something like:
>>
>> : setup #1
>> $ git repack -a -d -f
>> $ git prune
>>
>>
58 matches
Mail list logo
