threads / discuss / 31149

Centralized git

Subject: Centralized git

## tl;dr

6 messages between Jul 31, 2012 and Jul 31, 2012.

replies: 5people: 5as markdown or json

Javier Domingo· Jul 31, 2012, 12:03 UTC · lore

I know that currently that statement (Git centralized) is an oxymoron, but let me explain why would it be interesting.

I am currently planifying a 3D project, and I will be having large binary files. If I add a distributed VCS, the amount of disk space required will increase significantly.

Due to that, I started looking for an alternative VCS, such as svn, cvs. But none of them satisfied me, mainly because they didn't have the branch concept Git does.

I read the bzr docs, and I found that was nearly what I wanted, except for the branch concept git has. I am maybe explaining myself in the wrong way, but I hope someone understands.

What I would like, would be the posibility of having something like the history horizon in bzr, or the partial repos that git-annex provides. The idea is to have a repo with all the branches (just the head of them).

Another thing I would like to see would be being able to commit like git actually works. Though all the history wouldn't be available, making commits offline would be a great thing, althought later, when pushing, they would be just in the remote, getting erased from local.

I tryed to achieve this through porcelain commands, but didn't work the few examples I tryed.

I know this breaks with Git's main philosophy, but that is something that would be very great. For what I know, one of the bad things to deal with is that the compression algorithm is thought for text files.

I am looking for your answers,

Javier Domingo

jaseem abid· Jul 31, 2012, 12:55 UTC · re: Javier Domingo · lore

Re: Centralized git

On Tue, Jul 31, 2012 at 5:33 PM, Javier Domingo <javierdo1@gmail.com> wrote:

>
> I am currently planifying a 3D project, and I will be having large binary
> files. If I add a distributed VCS, the amount of disk space required will
> increase significantly.

You are going to transfer something that wont fit into your hard disk up and down your network once in a while ?

I assume disk to be cheaper than network.

-- Jaseem Abid http://jaseemabid.github.com

Edward Toroshchin· Jul 31, 2012, 15:40 UTC · re: Javier Domingo · lore

Re: Centralized git

Javier,

Are you sure you need git for those big binary files at all?

Branching makes sense only if merging makes sense, and I can hardly see how you can merge three 700-megabyte video files.

-- 
Edward "Hades" Toroshchin
dr_lepper on irc.freenode.org

Javier Domingo· Jul 31, 2012, 13:08 UTC · lore

Re: Centralized git

Network, in this case is cheaper. The thing is that If I commit frecuently, will have plenty of GBs of history, that nearly for sure I won't use. I just need to have other people's work to merge. But I want to think in Git style, I am pretty accustomed to that way of doing things. That is why I sent this mail here.

The idea is that if I modify 700MBs of video, with 20 commits I would get in 21GB. And making a pull would be... just even more horrible than anything. That is why I need to have also last checkouts filter. Just download branch's HEADs.

Javier Domingo

2012/7/31 jaseem abid <jaseemabid@gmail.com>

Show 16 quoted lines

>
> On Tue, Jul 31, 2012 at 5:33 PM, Javier Domingo <javierdo1@gmail.com> wrote:
> >
> > I am currently planifying a 3D project, and I will be having large binary
> > files. If I add a distributed VCS, the amount of disk space required will
> > increase significantly.
>
>
> You are going to transfer something that wont fit into your hard disk
> up and down your network once in a while ?
>
> I assume disk to be cheaper than network.
>
> --
> Jaseem Abid
> http://jaseemabid.github.com

Ævar Arnfjörð Bjarmason· Jul 31, 2012, 14:52 UTC · re: Javier Domingo · lore

Re: Centralized git

On Tue, Jul 31, 2012 at 3:08 PM, Javier Domingo <javierdo1@gmail.com> wrote:

Show 10 quoted lines

> Network, in this case is cheaper. The thing is that If I commit
> frecuently, will have plenty of GBs of history, that nearly for sure I
> won't use. I just need to have other people's work to merge. But I
> want to think in Git style, I am pretty accustomed to that way of
> doing things. That is why I sent this mail here.
>
> The idea is that if I modify 700MBs of video, with 20 commits I would
> get in 21GB. And making a pull would be... just even more horrible
> than anything. That is why I need to have also last checkouts filter.
> Just download branch's HEADs.

You're obviously aware of git-annex, is there any reason you can't just use that?

That would give you what you want, you'd have a moving window of current files, and then you'd delete old files as they become un-needed.

Vipul Amler· Jul 31, 2012, 15:47 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: Centralized git

On Tue, Jul 31, 2012 at 8:22 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 18 quoted lines

> On Tue, Jul 31, 2012 at 3:08 PM, Javier Domingo <javierdo1@gmail.com> wrote:
>> Network, in this case is cheaper. The thing is that If I commit
>> frecuently, will have plenty of GBs of history, that nearly for sure I
>> won't use. I just need to have other people's work to merge. But I
>> want to think in Git style, I am pretty accustomed to that way of
>> doing things. That is why I sent this mail here.
>>
>> The idea is that if I modify 700MBs of video, with 20 commits I would
>> get in 21GB. And making a pull would be... just even more horrible
>> than anything. That is why I need to have also last checkouts filter.
>> Just download branch's HEADs.
>
> You're obviously aware of git-annex, is there any reason you can't
> just use that?
>
> That would give you what you want, you'd have a moving window of
> current files, and then you'd delete old files as they become
> un-needed.

If there is a lot of static content, you should try git-media[1]. Its specifically aimed at what you are trying to achieve.

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[1] https://github.com/schacon/git-media/