On Fri, Nov 16, 2012 at 11:34 PM, Enrico Weigelt enrico.weig...@vnc.biz wrote:
Provide one main clone which is bare, pulls automatically, and is
there to stay (no pruning), so that all others can use that as a
reliable alternates source.
The problem here, IMHO, is the assumption, that the
Hi,
That's not the only problem. I believe you only get the savings when
the main repo gets the commits first. Which is probably ok most of
the time but it's worth mentioning.
Well, the saving will just be deferred to the point where the commit
finally went to the main repo and downstreams
2012/11/15 Javier Domingo javier...@gmail.com
Is there any way to avoid this? I mean, can something be done in git,
that it checks for (when pulling) the same objects in the other forks?
I've been using git-new-workdir
(https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir)
Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44:
On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill andrew.ard...@gmail.com
wrote:
On 15 November 2012 12:15, Javier Domingo javier...@gmail.com wrote:
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it
-Original Message-
From: Javier Domingo
Sent: Wednesday, November 14, 2012 8:15 PM
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it would imply some logic (and db) over it. With the hardlinking way,
it wouldn't require anything. The idea is
Provide one main clone which is bare, pulls automatically, and is
there to stay (no pruning), so that all others can use that as a
reliable alternates source.
The problem here, IMHO, is the assumption, that the main repo will
never be cleaned up. But what to do if you dont wanna let it grow
On 15 November 2012 10:42, Javier Domingo javier...@gmail.com wrote:
Hi,
I have come up with this while doing some local forks for work.
Currently, when you clone a repo using a path (not file:/// protocol)
you get all the common objects linked.
But as you work, each one will continue
Hi Andrew,
The problem about that, is that if I want to delete the first repo, I
will loose objects... Or does that repack also hard-link the objects
in other repos? I don't want to accidentally loose data, so it would
be nice that althought avoided to repack things, it would also
hardlink them.
On 15 November 2012 11:40, Javier Domingo javier...@gmail.com wrote:
Hi Andrew,
The problem about that, is that if I want to delete the first repo, I
will loose objects... Or does that repack also hard-link the objects
in other repos? I don't want to accidentally loose data, so it would
be
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it would imply some logic (and db) over it. With the hardlinking way,
it wouldn't require anything. The idea is that you don't have to do
anything else in the server.
I understand that it would be imposible to do it
On 15 November 2012 12:15, Javier Domingo javier...@gmail.com wrote:
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it would imply some logic (and db) over it. With the hardlinking way,
it wouldn't require anything. The idea is that you don't have to do
On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill andrew.ard...@gmail.com wrote:
On 15 November 2012 12:15, Javier Domingo javier...@gmail.com wrote:
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it would imply some logic (and db) over it. With the hardlinking
12 matches
Mail list logo
