Am 17.09.2018 um 17:58 schrieb Jonathan Nieder:
[...]
> Ah, thanks. See git-config(1):
>
> core.bigFileThreshold
> Files larger than this size are stored deflated,
> without attempting delta compression.
>
> Default is 512 MiB on all platforms.
On Mon, Sep 24, 2018 at 09:05:56PM -0700, John Austin wrote:
> On Mon, Sep 24, 2018 at 12:58 PM Taylor Blau wrote:
> > I'm replying to this part of the email to note that this would cause Git
> > LFS to have to do some extra work, since running 'git lfs install'
> > already writes to
On Mon, Sep 24, 2018 at 12:58 PM Taylor Blau wrote:
> I'm replying to this part of the email to note that this would cause Git
> LFS to have to do some extra work, since running 'git lfs install'
> already writes to .git/hooks/post-commit (ironically, to detect and
> unlock locks that we should
On Mon, Sep 24, 2018 at 08:34:44AM -0700, John Austin wrote:
> Perhaps git-global-graph is a decent name. GGG? G3? :). The structure
> right now in my head looks a bit like:
>
> Global Graph:
> client - post-commit git hooks to push changes up to the GG
I'm replying to this part of the email
Perhaps git-global-graph is a decent name. GGG? G3? :). The structure
right now in my head looks a bit like:
Global Graph:
client - post-commit git hooks to push changes up to the GG
git server - just the standard git server configuration
query server - replies with information
On Sun, Sep 23, 2018 at 12:53:58PM -0700, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> wrote:
> > I would even like to help with your effort and have non-unixy platforms
> > I'd like to do this on.
> > Having this separate from git LFS is an even better idea IMO,
On Sun, Sep 23, 2018 at 01:56:37PM -0400, Randall S. Becker wrote:
> On September 23, 2018 1:29 PM, John Austin wrote:
> > I've been putting together a prototype file-locking implementation for a
> > system that plays better with git. What are everyone's thoughts on
> > something like the
On September 23, 2018 3:54 PM, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> wrote:
> > I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> > Having this separate from git LFS is an even better idea IMO, and I would
>
Regarding integration into LFS, I'd like to build the library in such
a way that it would easy to bundle with LFS (so they could share the
same git hooks), but also make it flexible enough to work for other
workflows.
On Sun, Sep 23, 2018 at 12:53 PM John Austin wrote:
>
> On Sun, Sep 23, 2018 at
On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
wrote:
> I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> Having this separate from git LFS is an even better idea IMO, and I would
> suggest implementing this using the same set of build
On September 23, 2018 1:29 PM, John Austin wrote:
> I've been putting together a prototype file-locking implementation for a
> system that plays better with git. What are everyone's thoughts on
> something like the following? I'm tentatively labeling this system git-sync or
> sync-server. There
I've been putting together a prototype file-locking implementation for
a system that plays better with git. What are everyone's thoughts on
something like the following? I'm tentatively labeling this system
git-sync or sync-server. There are two pieces:
1. A centralized repository called the
On Mon, Sep 17 2018, Joey Hess wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> There's surely other aspects of that square peg of large file tracking
>> not fitting the round hole of file locking, the point of my write-up was
>> not that *that* solution is perfect, but there's prior art here that's
Ævar Arnfjörð Bjarmason wrote:
> There's surely other aspects of that square peg of large file tracking
> not fitting the round hole of file locking, the point of my write-up was
> not that *that* solution is perfect, but there's prior art here that's
> very easily adopted to distributed locking
On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > > together." This isn't possible in Git LFS today with the existing
"git
> > > lfs
Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> > On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > > Taylor Blau wrote:
Right, though this still subjects the remote copy to all of the
difficulty of packing large objects (though
On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > together." This isn't possible in Git LFS today with the existing "git
> > lfs lock" command (I had to check, but it takes only _one_ filename
On Mon, Sep 17 2018, Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> In the hypothetical git-annex-like case (simplifying a bit for the
>> purposes this explanation), for every FILE in your tree you have a
>> corresponding FILE.lock file, but
On September 17, 2018 9:55 AM Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the hypothetical git-annex-like case (simplifying a bit for the
> > purposes this explanation), for every FILE in your tree you have a
> > corresponding FILE.lock
On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> Hi,
>
> On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > Taylor Blau wrote:
>
> >> Right, though this still subjects the remote copy to all of the
> >> difficulty of packing large objects (though Christian's work to
On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> In the hypothetical git-annex-like case (simplifying a bit for the
> purposes this explanation), for every FILE in your tree you have a
> corresponding FILE.lock file, but it's not a boolean, but a log of who's
> asked for
On Sun, Sep 16, 2018 at 12:56:04AM -0700, David Aguilar wrote:
> Combining changes is inherently file-format specific, and I suspect
> that native authoring tools are best used in those scenarios.
> Maybe LFS can help deal with binary conflicts by having short and sweet
> ways to grab the "base",
Hi,
On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> Taylor Blau wrote:
>> Right, though this still subjects the remote copy to all of the
>> difficulty of packing large objects (though Christian's work to support
>> other object database implementations would go a long way to help
Thanks for all the thoughts so far -- I'm going to try to collate some
of my responses to avoid this getting too lengthy.
## Regarding Merging / Diffing
A couple of folks have suggested that we could improve merging /
diffing of binary files in general. I think this is useful, but can
only ever
> Right, though this still subjects the remote copy to all of the
> difficulty of packing large objects (though Christian's work to support
> other object database implementations would go a long way to help this).
Ah, interesting -- I didn't realize this step was part of the
bottleneck. I
On Sat, Sep 15 2018, Taylor Blau wrote:
> On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote:
>> I've been working myself on strategies for handling binary conflicts,
>> and particularly how to do it in a git-friendly way (ie. avoiding as
>> much centralization as possible and playing
On Fri, Sep 14, 2018 at 02:13:28PM -0700, John Austin wrote:
> Hey Taylor,
>
> Great to have your support! I think LFS has done a great job so far
> solving the large file issue. I've been working myself on strategies
> for handling binary conflicts, and particularly how to do it in a
>
On Fri, Sep 14, 2018 at 04:36:19PM -0700, John Austin wrote:
> > There's also the nascent "don't fetch all the blobs" work-in-progress
> > clone mode which might be of interest to you:
> > https://blog.github.com/2018-09-10-highlights-from-git-2-19/#partial-clones
>
> Yes! I've been pretty excited
On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote:
> I've been working myself on strategies for handling binary conflicts,
> and particularly how to do it in a git-friendly way (ie. avoiding as
> much centralization as possible and playing into the commit/branching
> model of git).
Git
> There's also the nascent "don't fetch all the blobs" work-in-progress
> clone mode which might be of interest to you:
> https://blog.github.com/2018-09-10-highlights-from-git-2-19/#partial-clones
Yes! I've been pretty excited about this functionality. It drives a
lot of GVFS/VFS for Git under
On Fri, Sep 14 2018, John Austin wrote:
> - improvements to large file management (mostly solved by LFS, GVFS)
There's also the nascent "don't fetch all the blobs" work-in-progress
clone mode which might be of interest to you:
Hey Taylor,
Great to have your support! I think LFS has done a great job so far
solving the large file issue. I've been working myself on strategies
for handling binary conflicts, and particularly how to do it in a
git-friendly way (ie. avoiding as much centralization as possible and
playing into
Hey Taylor,
Great to have your support! I think LFS has done a great job so far
solving the large file issue. I've been working myself on strategies
for handling binary conflicts, and particularly how to do it in a
git-friendly way (ie. avoiding as much centralization as possible and
playing into
Hi John,
On Fri, Sep 14, 2018 at 10:55:39AM -0700, John Austin wrote:
> Is anyone interested in contributing/offering insights? I suspect most
> folks here are git users as is, but if you know someone stuck on
> Perforce, I'd love to chat with them!
I'm thrilled that other folks are interested
Hey all,
I've been putting together a working group for game studios wanting to
use Git. There are a couple of blockers that keep most game and media
companies on Perforce or others, but most would love to use git if it
were feasible.
The biggest tasks I'd like to tackle are:
- improvements to
35 matches
Mail list logo
