On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
> > I think it's fine to tell them to do "git pull --merge". What I'd worry
> > more about is somebody who is suddenly presented with the choice between
> > "--rebase" and "--merge" and doesn't know which to choose. We've created a
On Sun, Sep 08, 2013 at 01:28:47PM +0700, Nguyen Thai Ngoc Duy wrote:
> > From a cursory read, this seems fine. If it were done in complete
> > isolation, I'd say it was a slight regression, just because we are doing
> > more I/O for the unpack case, and it is not really saving us any code
> > (it
On Sun, Sep 8, 2013 at 11:44 AM, Jeff King wrote:
> On Fri, Sep 06, 2013 at 07:46:01AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> ---
>> I had something that could unpack without writing to temp pack file
>> but I scraped it and chose this way because it follows closely how
>> index-pack works. It
The parameter is called break_score, not minimum_edit.
Signed-off-by: Ramkumar Ramachandra
---
diffcore-break.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 1d9e530..34dd1e0 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -
On 2013-09-07 22:41, Felipe Contreras wrote:
> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:
>
>> Which can be solved by adding the above "fail" option, and then
>> renaming them to "pull.integrate" and "branch..integrate" to
>> clarify what these variables are about (it is no longer "do
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
>
>> > It's not if you understand the difference between merge-then-commit and
>> > commit-then-merge. But for a clueless user who has been told "replace
>> > svn commit" with "git
Remove dead code around remove_dir_recursively().
Signed-off-by: Ramkumar Ramachandra
---
dir.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/dir.c b/dir.c
index 910bfcd..2b31241 100644
--- a/dir.c
+++ b/dir.c
@@ -1464,11 +1464,11 @@ int is_empty_dir(
Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport. This enables bzrlib to reuse
existing transports when possible, avoiding multiple concurrent
connections to the same remote server.
If the remote server is accessed via ssh, this fixes a
On 2013-09-07 20:30, Felipe Contreras wrote:
> On Sat, Sep 7, 2013 at 7:02 PM, Richard Hansen wrote:
>> On 2013-09-07 19:58, Richard Hansen wrote:
>>> Pass a list of open bzrlib.transport.Transport objects to each bzrlib
>>> function that might create a transport. This enables bzrlib to reuse
>>>
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
> > It's not if you understand the difference between merge-then-commit and
> > commit-then-merge. But for a clueless user who has been told "replace
> > svn commit" with "git commit && git push" and replace "svn update" with
> > "g
On Sat, Sep 7, 2013 at 11:43 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
>
>> > By "svn-like", I mean the people whose workflow is:
>> >
>> > $ hack hack hack
>> > $ git commit
>> > $ git push ;# oops, somebody else pushed in the meantime
>> > $
On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote:
> > Ah, you mean "if you think that the compare function should behave like
> > C *_cmp functions, it should be A-B". Perhaps it is simply that I do not
> > think of the function in those terms, but more like "show me the
> > differ
On Sat, Sep 7, 2013 at 11:56 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 10:02:59PM -0500, Felipe Contreras wrote:
>
>> 'git checkout -' works perfectly fine, and it's the closest we have to
>> my suggested test_checkout() which I think would be ideal, but I'm not
>> going to work on.
>
> I do
On Sat, Sep 07, 2013 at 10:02:59PM -0500, Felipe Contreras wrote:
> 'git checkout -' works perfectly fine, and it's the closest we have to
> my suggested test_checkout() which I think would be ideal, but I'm not
> going to work on.
I do not think it works perfectly fine if the checkout itself fai
On Sat, Sep 7, 2013 at 11:26 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:13:10PM -0500, Felipe Contreras wrote:
>
>> > If the reasoning is "cmp(actual, expect) makes more sense to humans"
>> > then I do not think it is universal.
>>
>> No.
>>
>> ---
>> A(ny) sanely defined "compare A with B"
On Fri, Sep 06, 2013 at 07:46:02AM +0700, Nguyen Thai Ngoc Duy wrote:
> static int get_pack(struct fetch_pack_args *args,
> - int xd[2], char **pack_lockfile)
> + int xd[2], char **pack_lockfile_p)
> {
> struct async demux;
> - const char *argv[22];
> +
On Fri, Sep 06, 2013 at 07:46:01AM +0700, Nguyen Thai Ngoc Duy wrote:
> ---
> I had something that could unpack without writing to temp pack file
> but I scraped it and chose this way because it follows closely how
> index-pack works. It's a good thing imo because .pack v4 is coming
> and I do
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
> > By "svn-like", I mean the people whose workflow is:
> >
> > $ hack hack hack
> > $ git commit
> > $ git push ;# oops, somebody else pushed in the meantime
> > $ git pull
> > $ git push
>
> But that's not svn-like at a
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
>
>> On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:
>>
>> > The patch in jc/pull-training-wheel talks about annoying old timers, but
>> > I think you may also be annoying cluele
On Sat, Sep 07, 2013 at 11:13:10PM -0500, Felipe Contreras wrote:
> > If the reasoning is "cmp(actual, expect) makes more sense to humans"
> > then I do not think it is universal.
>
> No.
>
> ---
> A(ny) sanely defined "compare A with B" function should yield the
> result of subtracting B from A
On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
> On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:
>
> > The patch in jc/pull-training-wheel talks about annoying old timers, but
> > I think you may also be annoying clueless new users who simply want an
> > svn-like workflow wit
On Sat, Sep 7, 2013 at 11:13 PM, Felipe Contreras
wrote:
> On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
>> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>>
>>> > Though I prefer the current, I can certainly live and adapt to a changed
>>> > standard, and I do not mind doi
On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>
>> > Though I prefer the current, I can certainly live and adapt to a changed
>> > standard, and I do not mind doing so if there is a good reason. But I've
>> > yet to see any ar
On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
> > Though I prefer the current, I can certainly live and adapt to a changed
> > standard, and I do not mind doing so if there is a good reason. But I've
> > yet to see any argument beyond "it is not what I like". Which to me
> > ar
On Sun, Sep 8, 2013 at 10:28 AM, Nicolas Pitre wrote:
>> @@ -794,6 +799,83 @@ static void *unpack_raw_entry(struct object_entry *obj,
>> return data;
>> }
>>
>> +static void *patch_one_base_tree(const struct object_entry *src,
>> + const unsigned char *src_buf,
On Sat, 7 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
> This is the most common case for delta trees. In fact it's the only
> kind that's produced by packv4-create. It fits well in the way
> index-pack resolves deltas and benefits from threading (the set of
> objects depending on this base does not over
On Wed, Sep 4, 2013 at 1:36 PM, Jeff King wrote:
> On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote:
>
>> >> This is way off tangent, but I am somewhat sympathetic to Felipe's
>> >> "compare actual with expect", with reservations.
>> >
>> > This isn't an argument either way, but note
On Wed, Sep 4, 2013 at 12:19 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Sep 3, 2013 at 5:59 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
On Tue, Sep 3, 2013 at 2:32 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>> test_expect_succ
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:
> The patch in jc/pull-training-wheel talks about annoying old timers, but
> I think you may also be annoying clueless new users who simply want an
> svn-like workflow without thinking too hard about it.
How? Subversion would complain if you have
On Sat, 7 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/index-pack.c | 104
> +--
> 1 file changed, 100 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
>
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:
> Which can be solved by adding the above "fail" option, and then
> renaming them to "pull.integrate" and "branch..integrate" to
> clarify what these variables are about (it is no longer "do you
> rebase or not---if you choose not to rebase, b
On Fri, Sep 6, 2013 at 5:14 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> John Keeping wrote:
>>> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
>>
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am not remembering
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote:
> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
>> Are there cases where you do not want to either rebase nor merge?
>> If so what do you want to do after "git pull" fetches from the other
>> side? Nothing?
>
> One other thing
On Sat, 7 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
[...]
> @@ -1677,6 +1727,15 @@ int cmd_index_pack(int argc, const char **argv, const
> char *prefix)
> free(objects);
> free(index_name_buf);
> free(keep_name_buf);
> + free(sha
On Tue, Sep 3, 2013 at 11:45 PM, Drew Northup wrote:
> On Thu, Aug 29, 2013 at 6:10 PM, Felipe Contreras
> wrote:
>> On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote:
>>> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote:
Felipe Contreras writes:
> It has been discussed ma
On Tue, Sep 3, 2013 at 11:23 PM, Drew Northup wrote:
> On Fri, Aug 30, 2013 at 1:16 AM, Piotr Krukowiecki
> wrote:
>> Drew Northup napisał:
>>>I agree with Junio. This effort is better spent making the
>>>documentation clearer and more succinct. The reality is that a user
>>>needs to build a mod
On Wed, Sep 4, 2013 at 8:36 AM, Drew Northup wrote:
> On Wed, Sep 4, 2013 at 3:13 AM, Piotr Krukowiecki
> wrote:
>> Just wanted to point to a Dr. Dobb's article from Monday:
>> http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2
>>
>> The author does not use the
On Wed, Sep 4, 2013 at 2:13 AM, Piotr Krukowiecki
wrote:
> Just wanted to point to a Dr. Dobb's article from Monday:
> http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2
>
> The author does not use the use the word "index" at all. Instead he
> writes in followin
On Sat, Sep 7, 2013 at 11:19 AM, John Keeping wrote:
> When it was originally added, the git_remote_helpers library was used as
> part of the tests of the remote-helper interface, but since commit
> fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) a simple
> shell script is used for thi
On Fri, Sep 6, 2013 at 11:30 PM, David Aguilar wrote:
>
> On Sep 6, 2013 7:51 PM, "Felipe Contreras"
> wrote:
>>
>> Junio C Hamano wrote:
>> > Sebastian Schuberth writes:
>> >
>> > > For custom builds of Git it sometimes is inconvenient to annotate tags
>> > > because there simply is nothing to
On Sat, Sep 7, 2013 at 11:10 AM, Junio C Hamano wrote:
> I am not sure what you mean by automated, but if you can tell your
> automation infrastructure that the way to build this Git software is
> to run "make" in it, shouldn't it be trivial to instead tell it to
> run something like this instead
When "git stash" does its work, if the index and the work
directory are out of sync, but the work directory is in sync with
the HEAD commit, the work directory commit does not contain the
file in its work-directory state, but rather in its index-state.
This seems wrong. For instance, "git stash b
On Fri, Sep 6, 2013 at 2:29 PM, Tim Chase wrote:
> On 2013-09-06 17:51, Konstantin Khomoutov wrote:
>> I found this guide [1] very useful back in the time I tried to grok
>> Mercurial.
>>
>> 1.
>> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
I've written various blog posts
On Sat, Sep 7, 2013 at 7:02 PM, Richard Hansen wrote:
> On 2013-09-07 19:58, Richard Hansen wrote:
>> Pass a list of open bzrlib.transport.Transport objects to each bzrlib
>> function that might create a transport. This enables bzrlib to reuse
>> existing transports when possible, avoiding multip
On Sat, Sep 7, 2013 at 6:58 PM, Richard Hansen wrote:
> Pass a list of open bzrlib.transport.Transport objects to each bzrlib
> function that might create a transport. This enables bzrlib to reuse
> existing transports when possible, avoiding multiple concurrent
> connections to the same remote s
On 2013-09-07 19:58, Richard Hansen wrote:
> Pass a list of open bzrlib.transport.Transport objects to each bzrlib
> function that might create a transport. This enables bzrlib to reuse
> existing transports when possible, avoiding multiple concurrent
> connections to the same remote server.
>
>
Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport. This enables bzrlib to reuse
existing transports when possible, avoiding multiple concurrent
connections to the same remote server.
If the remote server is accessed via ssh, this fixes a
On 07/09/13 22:03, Lee Carver wrote:
As noted in several forums, a recommended way to move trees between
repositories
is to use git-filter-branch to revise the history for a single tree:
http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth
er-preserving-history/
http://sta
As noted in several forums, a recommended way to move trees between
repositories
is to use git-filter-branch to revise the history for a single tree:
http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth
er-preserving-history/
http://stackoverflow.com/questions/1365541/how-to
Andreas -
So that's what the "eval set -- " does!
We actually got it to work with a temporary file Š I'll send that patch in
a minute.
Thanks
Lee
On 9/7/13 1:29 PM, "Andreas Schwab" wrote:
>Lee Carver writes:
>
>> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>> index ac2a005..
Lee Carver writes:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index ac2a005..d7e0fae 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -255,8 +255,6 @@ else
> remap_to_ancestor=t
> fi
>
> -rev_args=$(git rev-parse --revs-only "$@")
> -
> case "$filt
As noted in several forums, a recommended way to move trees between
repositories is to use git-filter-branch to revise the history for a
single tree
(http://gbayer.com/development/moving-files-from-one-git-repository-to-anot
her-preserving-history/,
http://stackoverflow.com/questions/1365541/how-t
On Sat, Sep 7, 2013 at 6:19 PM, John Keeping wrote:
> When it was originally added, the git_remote_helpers library was used as
> part of the tests of the remote-helper interface, but since commit
> fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) a simple
> shell script is used for this
On Sat, Sep 7, 2013 at 6:10 PM, Junio C Hamano wrote:
>>> If you want to give build a custom name,
>>>
>>> echo buildname >version
>>>
>>> should be sufficient, no?
>>
>> That's not sufficient if you care about a proper (automated) release
>> workflow with your releases tagged.
>
> I take the
From: "Junio C Hamano"
Sent: Saturday, September 07, 2013 4:50 PM
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
Does this have any impact on the alleged bug in `git bundle --all`
(which can then be cloned from) where the current HEAD ref wasn't
included in the bun
On 06-09-2013 23:49, Phil Hord wrote:
Can you think of a sane way to separate the "from" and the "to" branches in
the GUI? I mean, I would like to push "HEAD" and I would like it to
go to "refs/for/frotz-2.0".
My first attemt at this change was to do do exactly that: always push
HEAD, and bei
Ramsay Jones writes:
> In order to allow the user to specify the correct tool, introduce
> the GIT_TEST_HIGHLIGHT_BIN variable. Also, add ' command line of the highlight invocation; this avoids hanging the
> test if the filter script is used nonetheless.
gitweb/Makefile seems to have a rule to s
Sebastian Schuberth writes:
> On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano wrote:
>
>>> For custom builds of Git it sometimes is inconvenient to annotate tags
>>> because there simply is nothing to say, so do not require an annotation.
>>>
>>> Signed-off-by: Sebastian Schuberth
>>> ---
>>
>>
i have a business proposal for you, write me back for more info.
-Sent from my ipad.
--
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-info.html
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> "Philip Oakley" writes:
>>
>>> Does this have any impact on the alleged bug in `git bundle --all`
>>> (which can then be cloned from) where the current HEAD ref wasn't
>>> included in the bundle? Or am I mis-remembering?
>>
>> Not "current HEA
On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano wrote:
>> For custom builds of Git it sometimes is inconvenient to annotate tags
>> because there simply is nothing to say, so do not require an annotation.
>>
>> Signed-off-by: Sebastian Schuberth
>> ---
>
> H, personally I'd actually want thi
On Sat, Sep 7, 2013 at 12:34 AM, Kyle J. McKay wrote:
>> For custom builds of Git it sometimes is inconvenient to annotate tags
>> because there simply is nothing to say, so do not require an annotation.
>
> It's not that hard to add -m "" to the command line:
It's not hard to type those charact
On Fri, Sep 06, 2013 at 03:14:25PM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > John Keeping wrote:
> >> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
> >
> >>> I somehow thought that rebase by default looked in the reflog to do
> >>> exactly that. Perhaps I am n
This is the most common case for delta trees. In fact it's the only
kind that's produced by packv4-create. It fits well in the way
index-pack resolves deltas and benefits from threading (the set of
objects depending on this base does not overlap with the set of
objects depending on another base)
M
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 33722e1..1fa74f4 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1171,10 +1171,13 @@ sta
For v2, ofs-delta and ref-delta can only have queue one delta base at
a time. A v4 tree can have more than one delta base. Move the queuing
code up to unpack_raw_entry() and give unpack_tree_v4() more
flexibility to add its bases.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 46
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 59b6c56..db2370d 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -742,6 +742,
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 61 +++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 0dd7193..59b6c56 100644
--- a/builtin/index-pack.c
+++ b/builtin
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index c5a8f68..33722e1 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 95 ++--
1 file changed, 92 insertions(+), 3 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index db2370d..210b78d 100644
--- a/builtin/index-pack.c
+++ b/builti
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 104 +--
1 file changed, 100 insertions(+), 4 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 210b78d..51ca64b 100644
--- a/builtin/index-pack.c
+++ b/built
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 82
1 file changed, 45 insertions(+), 37 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 9c1cfac..5b1395d 100644
--- a/builtin/index-pack.c
+++ b/built
We do need deltas until the second pass. Allocating a buffer for it
then freeing later is wasteful is unnecessary. Make it use fixed_buf
(aka large blob code path).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
This makes index-pack recognize pack v4. It still lacks:
- the ability to walk through multi-base trees
- thin pack support
The first is not easy to solve imo and but does not impact us in short
term because pack-objects probably will not learn to produce such
trees any time soon.
The second s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 63 --
packv4-parse.h | 8
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 63bba03..82661ba 100644
--- a/packv4-parse.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 62 +++-
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a47cc34..0dd7193 100644
--- a/builtin/index-pack.c
+++ b/built
cmt...@gmail.com wrote on Fri, 06 Sep 2013 15:03 -0400:
> Finally, I claim success! Unfortunately I did not try either of the OOM
> score or strace suggestions - sorry! After spending so much time on
> this, I've gotten to the point that I'm more interested in getting it to
> work than in figurin
On Sat, Sep 7, 2013 at 11:52 AM, Nicolas Pitre wrote:
> On Fri, 6 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> Should be up to date with Nico's latest implementation and also cover
>> additions to the format that everybody seems to agree on:
>>
>>
78 matches
Mail list logo
