On Mon, 10 Mar 2014 19:39:00 +, Shawn Pearce wrote:
Yes, this was my real concern. Eclipse users using EGit expect EGit to
be compatible with git-core at the filesystem level so they can do
something in EGit then switch to a shell and bang out a command, or
run a script provided by their
Karsten,
Thanks for your feedback!
On 03/11/2014 11:56 AM, Karsten Blees wrote:
Am 10.03.2014 12:00, schrieb Michael Haggerty:
Reference transactions --
Very cool ideas indeed.
However, I'm concerned a bit that transactions are conceptual
overkill. How many
On Wed, Mar 12, 2014 at 3:26 AM, Andreas Krey a.k...@gmx.de wrote:
On Mon, 10 Mar 2014 19:39:00 +, Shawn Pearce wrote:
Yes, this was my real concern. Eclipse users using EGit expect EGit to
be compatible with git-core at the filesystem level so they can do
something in EGit then switch to
Am 10.03.2014 12:00, schrieb Michael Haggerty:
Reference transactions
--
Very cool ideas indeed.
However, I'm concerned a bit that transactions are conceptual overkill. How
many concurrent updates do you expect in a repository? Wouldn't a single
repo-wide lock suffice
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
(This morning I removed this project from the GSoC ideas page, because
it is unfair to ask a student to shoot at a moving target.)
Why?
Currently, the reference- and
On Mon, Mar 10, 2014 at 12:00 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
No comments or useful feedback yet, except that I enthusiastically
approve of the objective and
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
Yay!
JGit already has pluggable ref backends, so it is good to see this
starting in git-core.
On 10.03.2014, at 15:30, Shawn Pearce spea...@spearce.org wrote:
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
Yay!
Yay, too!
JGit
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, 10 Mar 2014, David Kastrup wrote:
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, Mar 10, 2014 at 10:46:01AM -0700, Junio C Hamano wrote:
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know SQLLite is pretty amazing, but implementing
compatibility with it from JGit will
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
[storing refs in sqlite]
Of course, the basic premise for this feature is let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity. There have been two historically
Jeff King p...@peff.net writes:
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
[storing refs in sqlite]
Of course, the basic premise for this feature is let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity.
On 03/10/2014 04:52 PM, Jeff King wrote:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit
On Mon, Mar 10, 2014 at 2:07 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 03/10/2014 04:52 PM, Jeff King wrote:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core.
17 matches
Mail list logo
