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
>>
>>
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
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 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
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 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.
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
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
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
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
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:
>
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
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
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
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
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::
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
>
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
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
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
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
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
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
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 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
(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/
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
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
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
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:
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
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
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
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
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
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
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:
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
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 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 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 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 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 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 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
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, 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.
>
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 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:
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
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
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.
> >
>
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
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
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
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 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 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
58 matches
Mail list logo
