Thread (28 messages) flat view 28 messages, 12 authors, 2016-06-15

Re: How it was at GitTogether'08 ?

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:37

Hi,

On Mon, 10 Nov 2008, Kai Blin wrote:
On Monday 10 November 2008 10:58:05 Johannes Schindelin wrote:
quoted
quoted
Tim was talking about that media/ folder and managing that in git. 
If you want to work on the media, you might end up getting hundreds 
of gigabytes of data to get that folder, even if you only need to 
change one single file.

That's the issue we're running into, and I don't thing submodules 
solve this at all.
You'd have to have a single repository for each and every media file, 
and you'd need to use shallow clones and shallow fetches.

However, a push-conflict will probably be beyond any non-programmer 
skillz.
Ok, I agree. But you could work around that by teaching the artists to 
fetch/rebase/push instead of just pushing, or hiding this in the GUI. If 
there's a conflict on a binary data file you're screwed anyway. :)
A fetch in that case would make the artist download things she does not 
need, right?  So maybe that is not the way to go.
quoted
I'd rather propose to have a different interface, like through a web 
server, where the user can say "I have some cool new graphics, in this 
.zip file" together with a commit message.

Kind of a git-gui via browser.
Incidentally I'm currently working on something like this, just aimed at 
the "artist side", instead of the VCS side. This certainly is a useable 
solution for artists.
Seems like a nice starting point for a git-gui-in-a-browser.
But at some point a developer will want to check out the repository to 
cut a release tarball, and we're back to wanting shallow and narrow 
clones. :)
Shallow clones are not an issue.  They _should_ work.

And for releasing you do not want narrow clones.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help