On Sat, Feb 15, 2014 at 7:17 PM, Thomas Rast t...@thomasrast.ch wrote:
It also includes an ok from Nicolas Pitre, who has been the driving
force behind packv5 development. The only thing that makes me uneasy is
Nit: pack v4. You are probably confused with index v5, which is also
cooking for a
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
This definitely should not be we'll think about it if and when that
project is finished material.
Yes, all of this is true. However, you are painting a big devil on
the wall.
[...]
Your scenario above mostly
On Sat, Feb 15, 2014 at 4:17 AM, Thomas Rast t...@thomasrast.ch wrote:
David Kastrup d...@gnu.org writes:
Thomas Rast t...@thomasrast.ch writes:
Motivation: I believe that migrating to libgit2 is the better approach,
medium term, than rewriting everything ourselves to be nice, clean and
Thomas Rast t...@thomasrast.ch writes:
Here's my moonshot:
--- 8 ---
Replace object loading/writing layer by libgit2
Git reads objects from storage (loose and packed) through functions in
sha1_file.c. Most commands only require very simple, opaque read and
write access to the object
On Thu, Feb 13, 2014 at 06:17:17PM -0500, Ramkumar Ramachandra wrote:
I'll throw in a few ideas from half-finished work.
Thanks. A few comments:
1. Speed up git-rebase--am.sh
Currently, git-rebase--am.sh is really slow because it dumps each
patch to a file using git-format-patch, and
Jeff King wrote:
1. Speed up git-rebase--am.sh
Isn't the merge backend faster? I thought that was the point of it.
I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the reason it was using
On Fri, Feb 14, 2014 at 10:30:28AM -0500, Ramkumar Ramachandra wrote:
Isn't the merge backend faster? I thought that was the point of it.
I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the
On Thu, Feb 13, 2014 at 10:45 PM, Thomas Rast t...@thomasrast.ch wrote:
Replace object loading/writing layer by libgit2
Git reads objects from storage (loose and packed) through functions in
sha1_file.c. Most commands only require very simple, opaque read and
write access to the object
On Thu, Feb 13, 2014 at 04:10:37AM -0500, Jeff King wrote:
The Google Summer of Code application process is upon us. We have about
34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very
much time, but I know some people have been thinking about projects for
a while, so I have
The Google Summer of Code application process is upon us. We have about
34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very
much time, but I know some people have been thinking about projects for
a while, so I have hope that we can put together an ideas page.
What we need
Jeff King p...@peff.net writes:
- somebody to be the backup admin (I am assuming I'll be the primary
admin, but as always, if somebody else wants to...)
I can be backup, if Shawn doesn't want it.
- ideas ideas ideas
Here's my moonshot:
--- 8 ---
Replace object loading/writing layer
Thomas Rast t...@thomasrast.ch writes:
Downside: not listing code merged as a goal may not make the project
as shiny, neither for Git nor for the student.
I'd actually view that as an upside. This sounds like a good first
step for a feasibility study that is really necessary.
I wonder why the
Jeff King wrote:
- ideas ideas ideas
I'll throw in a few ideas from half-finished work.
1. Speed up git-rebase--am.sh
Currently, git-rebase--am.sh is really slow because it dumps each
patch to a file using git-format-patch, and picks it up to apply
subsequently using git-am. Find a way to
Junio C Hamano gits...@pobox.com writes:
Thomas Rast t...@thomasrast.ch writes:
Downside: not listing code merged as a goal may not make the project
as shiny, neither for Git nor for the student.
I'd actually view that as an upside. This sounds like a good first
step for a feasibility
14 matches
Mail list logo
