From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:01
quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] writes:
LT> In fact, the most recent push was gone with a
LT> git-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/git.git
Congrats for a job well done.
Now is there anything for us poor mortals who would want to have
a "pull" support? Logging in via ssh and run send-pack on the
other end is workable but not so pretty ;-).
Now is there anything for us poor mortals who would want to have
a "pull" support? Logging in via ssh and run send-pack on the
other end is workable but not so pretty ;-).
I'm thinking about it. You can't actually do send-pack from the other end,
since send-pack needs to know what the base is, and the base you have may
not even exist in the remote.
So a "git-pull-pack" will follow the objects on the other side until it
hits one we have, and _then_ it can send a nice pack. It's not hard per
se, and some of the problems are actually simpler than git-send-pack, but
it needs more communication (and in order to be efficient you want to not
ping-pong a "do-you-have-it" query every time around).
I also want to make sure that the biggest burden is on the pull side, not
the push side. I have a plan, though.
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:01
On Thu, 30 Jun 2005, Junio C Hamano wrote:
quoted
quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] writes:
LT> In fact, the most recent push was gone with a
LT> git-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/git.git
Congrats for a job well done.
Now is there anything for us poor mortals who would want to have
a "pull" support? Logging in via ssh and run send-pack on the
other end is workable but not so pretty ;-).
I suspect that I'll be able to merge send-pack/receive-pack with
ssh-push/ssh-pull this evening, and then it'll have the feature of not
caring too much which side your command line is on.
-Daniel
*This .sig left intentionally blank*
From: Dan Holmsand <hidden> Date: 2016-06-15 22:42:01
Junio C Hamano wrote:
quoted
quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] writes:
LT> In fact, the most recent push was gone with a
LT> git-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/git.git
Congrats for a job well done.
Agree totally. And the whole pack thing is really cool. Git is sooo much
faster when running from pack-files only on my poor laptop.
Now is there anything for us poor mortals who would want to have
a "pull" support? Logging in via ssh and run send-pack on the
other end is workable but not so pretty ;-).
Agreed again :-)
Even cooler would be pack-pulls via http. That would be a bit hard on
the servers with the current git-pack-objects, but it ought to be
possible to create something similar that doesn't re-delta anything, but
instead just spits out what's in an existing pack-file, and (perhaps)
deltifies objects from the file system.
If people then re-pack their repositories occasionally, this should be
plenty fast, the number of files for rsync to deal with could be kept
down, as could download times for mortal users.
/dan
I suspect that I'll be able to merge send-pack/receive-pack with
ssh-push/ssh-pull this evening, and then it'll have the feature of not
caring too much which side your command line is on.
The simple thing to do is to just get one commit at a time, see if you
have it already, parse if it not, and go on to the parents.
That would fit the current git-pull thing, and may be good enough, but it
has the downside that it can need a _lot_ of back-and-forth fecthing of
commit objects from the other side until you find the one you want. That's
going to be _very_ slow over a high-latency connection.
So what I'd suggest is:
- puller starts by just asking "what's your SHA1 for the ref I want"
The puller wants to know this, because a common case may be that it
already has it, in which case it doesn't need to do anything. But more
importantly, the puller will need to know this anyway if it gets an
object-pack, so that the puller can update it's FETCH_HEAD.
- if puller doesn't have it, then the _puller_ does:
"git-rev-list my-current-refs"
to generate an in-date-order list of commits it has, and it starts
feeding the result in chunks of 100 entries or something to the other
end.
- now, the server sees this stream of SHA1's that the client wants, and
it can very cheaply just test "do I have this SHA1". Now, if the client
hasn't made any changes at all, then the first one will be a hit, and
we already have sufficient knowledge to tell what the difference
between the client and the server is.
But more importantly, even if the client _has_ made changes, the client
likely has more available CPU than the server has, _and_ the client
likely has a shorter list of changes than the server has, so it's
really the client that should do this. We should burden the server as
lightly as possible for this to scale.
- At some point the server sees the first SHA1 it recognizes, and at that
point the server will have to start working. It will just send back an
"ok, got it" message (telling the client to not bother continuing to
send it any more commit ID's), and then does
git-rev-list --objects ref-client-wants ^first-common-sha1 |
git-pack-objects --stdout
- the client just unpacks the objects, and if successful, it puts the new
top ref it got into FETCH_HEAD. It's now done.
And I do _not_ think that it makes a lot of sense to try to be symmetric.
For one thing, while a "git-send-pack" should update all the refs
in-place, a "git-pull-pack" should _not_ update the ref, it should just
set FETCH_HEAD instead and the puller can decide what he wants to do with
that ref (possibly merge it, but possibly just make it be a new local
branch "remote-branch").
So I think sending and receiving are fundamentally non-symmetric.
Linus
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
It seems to me that git always defines a DAG of objects, such that if
you have a list of terminals (defined as objects not referenced by other
objects), you can, given access to the same objects, figure out all
intervening objects.
The tricky bit becomes finding the DAG both sides have in common with as
little traffic as possible.
For producing minimum network traffic, I think something like this would
work:
a) The sender sends a list of its terminals to the receiver.
b) The receiver sends a list of nodes it needs, plus a list of all its
own meta-terminals, obtained by pruning its own DAG according to the
terminals list of the sender.
c) This may have to be performed iteratively? I need to sit down and
work out the exact algorithm for all cases, including branch trees and
multi-rooted DAGs.
d) Once the sender knows the subset of its own DAG available to the
receiver, it can transmit either all objects that it has the sender does
not, or all objects on the path to one or more specific objects (e.g. HEAD.)
-hpa
For producing minimum network traffic, I think something like this would
work:
In the "minimum traffic", the thing to look at is number of packets, and
penalize further for anything that requires a synchronous reply.
That's why I'd suggest just letting the client stream out the list of
objects it has - it may appear wasteful to stream out even a thousand
SHA1's, but hey, that's just 20kB worth of data, and especially if there
is no synchronous stuff, that's just 15 ethernet packets.
For the server side, looking up a thousand SHA's is pretty easy (it's
_really_ cheap if the server ends up using a few big packed objects: you
don't even have to look at the pack data itself, it can look at just the
index and say "yup, I've got it")
So I'd go for simple brute force over anything that needs to discuss
things and have a back-and-forth between server/client. And making the
client do the heavy lifting is the right thing to do (the server will have
to create the pack, which can be expensive, but you can tune the delta
window for how much CPU the server has)
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:01
On Thu, 30 Jun 2005, Linus Torvalds wrote:
On Thu, 30 Jun 2005, Daniel Barkalow wrote:
quoted
I suspect that I'll be able to merge send-pack/receive-pack with
ssh-push/ssh-pull this evening, and then it'll have the feature of not
caring too much which side your command line is on.
The simple thing to do is to just get one commit at a time, see if you
have it already, parse if it not, and go on to the parents.
That would fit the current git-pull thing, and may be good enough, but it
has the downside that it can need a _lot_ of back-and-forth fecthing of
commit objects from the other side until you find the one you want. That's
going to be _very_ slow over a high-latency connection.
So what I'd suggest is:
1- puller starts by just asking "what's your SHA1 for the ref I want"
The puller wants to know this, because a common case may be that it
already has it, in which case it doesn't need to do anything. But more
importantly, the puller will need to know this anyway if it gets an
object-pack, so that the puller can update it's FETCH_HEAD.
Already have this, for the non-pack case.
- At some point the server sees the first SHA1 it recognizes, and at that
point the server will have to start working. It will just send back an
"ok, got it" message (telling the client to not bother continuing to
send it any more commit ID's), and then does
git-rev-list --objects ref-client-wants ^first-common-sha1 |
git-pack-objects --stdout
Right.
- the client just unpacks the objects, and if successful, it puts the new
top ref it got into FETCH_HEAD. It's now done.
Or wherever it's been told to, yes.
And I do _not_ think that it makes a lot of sense to try to be symmetric.
For one thing, while a "git-send-pack" should update all the refs
in-place, a "git-pull-pack" should _not_ update the ref, it should just
set FETCH_HEAD instead and the puller can decide what he wants to do with
that ref (possibly merge it, but possibly just make it be a new local
branch "remote-branch").
My expectation is that the puller will have a ref "remote-branch", and
will therefore: (1) want to update it, and (2) know the last commit pulled
from it. In this situation, we can skip figuring out the start (the two
points I didn't quote), because we saved it from before.
At least, this is how I've always done it; I've got a "linus" branch that
follows the public repo, and I commit changes to a different branch. I
suppose one could skip hanging onto this info, but it seems like an
obviously useful thing to keep, if for no other reason than that I want to
diff against it. This is essentially promoting FETCH_HEAD to a refs/heads/
thing, and having separate ones when you pull from separate sources.
I suppose things are different if you do a lot of one-shot pulls, rather
than tracking branches that you pull from; I'll need to think about this
case (assuming that's actually what you do).
-Daniel
*This .sig left intentionally blank*
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
On Thu, 30 Jun 2005, H. Peter Anvin wrote:
quoted
For producing minimum network traffic, I think something like this would
work:
In the "minimum traffic", the thing to look at is number of packets, and
penalize further for anything that requires a synchronous reply.
That's why I'd suggest just letting the client stream out the list of
objects it has - it may appear wasteful to stream out even a thousand
SHA1's, but hey, that's just 20kB worth of data, and especially if there
is no synchronous stuff, that's just 15 ethernet packets.
In your linux-2.6 tree, there are currently 54,204 objects, and that is
after less than one full 2.6.x kernel release cycle. That's a megabyte
of SHA1s.
In /pub/scm on kernel.org, there are currently 1,815,573 objects or hard
links to objects, which would take a 36.3 MB list to produce.
Although this is better than what rsync does, which is it encodes this
list into ASCII with pathnames and all and it ends up being closer to
200 MB, it isn't fundamentally different.
-hpa
My expectation is that the puller will have a ref "remote-branch", and
will therefore: (1) want to update it, and (2) know the last commit pulled
from it. In this situation, we can skip figuring out the start (the two
points I didn't quote), because we saved it from before.
This is _never_ how I do things, so I think that's a bad expectation. I
have other peoples trees "just show up", since they are actually based on
mine..
Linus
In your linux-2.6 tree, there are currently 54,204 objects, and that is
after less than one full 2.6.x kernel release cycle. That's a megabyte
of SHA1s.
But that's _all_ objects. There are "only" 4040 commit objects (which are
always the starting point for a search).
So streaming out the commit objects a few hundred at a time is actually
a very simple strategy.
Also, note that the server is usually _more_ ahead than the client is, and
the server is the one that potentially has lots of commits that the
client doesn't have. Not the other way around. So if the client makes a
list of it's top commits, it almost certainly won't have to make a very
long list until the server can tell it "ok, stop, I've seen it".
Yeah, maybe we want to limit the "burst" to 70 sha1's, since that will fit
in a regular-sized ethernet packet, but whatever - you'd burst out your
commits "latest first", so you'd never even get to the current 4040 unless
you've literally done the kind of work we've done in the git tree for the
last 3 months _and_you've_not_pulled_from_that_server_in_the_whole_time_.
Linus
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
On Thu, 30 Jun 2005, H. Peter Anvin wrote:
quoted
In your linux-2.6 tree, there are currently 54,204 objects, and that is
after less than one full 2.6.x kernel release cycle. That's a megabyte
of SHA1s.
But that's _all_ objects. There are "only" 4040 commit objects (which are
always the starting point for a search).
Well, there are objects that reference commit objects (e.g. tag
objects), not the other way around, but your point is well taken.
So streaming out the commit objects a few hundred at a time is actually
a very simple strategy.
Also, note that the server is usually _more_ ahead than the client is, and
the server is the one that potentially has lots of commits that the
client doesn't have. Not the other way around. So if the client makes a
list of it's top commits, it almost certainly won't have to make a very
long list until the server can tell it "ok, stop, I've seen it".
Well, what I proposed was pretty much that except to have the client
(receiver) start first.
I prefer calling it sender and receiver, because in the case of upload
and download you have different sides being the "server".
Yeah, maybe we want to limit the "burst" to 70 sha1's, since that will fit
in a regular-sized ethernet packet, but whatever - you'd burst out your
commits "latest first", so you'd never even get to the current 4040 unless
you've literally done the kind of work we've done in the git tree for the
last 3 months _and_you've_not_pulled_from_that_server_in_the_whole_time_.
Well, in the common case (sender has a superset of receiver), what I
proposed would converge on the first iteration. I'm not even convinced
that the algorithm *ever* needs to iterate.
-hpa
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:01
On Thu, 30 Jun 2005, Linus Torvalds wrote:
On Thu, 30 Jun 2005, Daniel Barkalow wrote:
quoted
My expectation is that the puller will have a ref "remote-branch", and
will therefore: (1) want to update it, and (2) know the last commit pulled
from it. In this situation, we can skip figuring out the start (the two
points I didn't quote), because we saved it from before.
This is _never_ how I do things, so I think that's a bad expectation. I
have other peoples trees "just show up", since they are actually based on
mine..
Okay, so my next task will be to support this case.
What I'm doing now is:
- if the source is using an old version, fall back on individual objects
- send one (or more) ids to exclude
- find out if the server recognized any of the ids
- if not, fall back on transferring individual objects (or we could try
another batch)
- request a pack for the given hash, excluding whatever we've said to
exclude
I've implemented this for the case of updating a head, and got it to
transfer a pack of 11 objects. It took 31s (including connecting) to
transfer the entire history of git (3973 objects) over a DSL-DSL link with
a 39ms ping time. I sent the same thing with the old method previously,
and it took ages (wasn't timing it, though).
It should be possible to notice that we're not updating a ref, send all
the refs you have instead, see if the source recognized any, try again
with the next 70 commits, check, and repeat. Does this match what you were
suggesting?
I can send you the messy version tomorrow if you want to hack on it or
test it, and I'll have a clean patch series over the weekend.
-Daniel
*This .sig left intentionally blank*
From: Mike Taht <hidden> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
Also, note that the server is usually _more_ ahead than the client is, and
the server is the one that potentially has lots of commits that the
client doesn't have. Not the other way around. So if the client makes a
list of it's top commits, it almost certainly won't have to make a very
long list until the server can tell it "ok, stop, I've seen it".
Yeah, maybe we want to limit the "burst" to 70 sha1's, since that will fit
in a regular-sized ethernet packet, but whatever - you'd burst out your
commits "latest first", so you'd never even get to the current 4040 unless
you've literally done the kind of work we've done in the git tree for the
last 3 months _and_you've_not_pulled_from_that_server_in_the_whole_time_.
You are getting closer and closer to where something like bitTorrent or
a multicast protocol makes sense. The problem isn't just the number of
outstanding commit objects but the number of machines and developers
that want to grab those commits at the same time.
Mike Taht
PostCards From The Bleeding Edge
http://the-edge.blogspot.com "Tempel 1 worth 2.2 million trillion bux"
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Mike Taht wrote:
You are getting closer and closer to where something like bitTorrent or
a multicast protocol makes sense. The problem isn't just the number of
outstanding commit objects but the number of machines and developers
that want to grab those commits at the same time.
You are getting closer and closer to where something like bitTorrent or
a multicast protocol makes sense. The problem isn't just the number of
outstanding commit objects but the number of machines and developers
that want to grab those commits at the same time.
I don't think so. First off, I don't think the decision is kernel-
specific, in the sense that I at least use git for sparse and git itself
too, so the solution should make sense for small projects as well.
Also, even for the kernel, the total dataset right now (after three months
or whatever) is a 60MB pack. It's not like we're sending DVD's or even
CD's worth of data around - we're sending the equivalent of 20MB per
_month_. That's really not a lot of data. You could easily keep up with a
slow modem.
Also, the number of people involved isn't _that_ big. We're talking a few
thousand people who actively would update their trees for a big project,
and many smaller projects have anything from a couple to maybe a hundred.
A few mirrors, and you don't have any problem.
So I think that the problem is actually not that big, and we just need to
find an acceptable format. Quite frankly, it might be perfectly acceptable
for kernel.org to run a simple packing script once a week which packs
everything into one single file, and even if that means that the mirrors
will have to re-get everything once a week, that actually sounds
acceptable.
It's obviously a _stupid_ way to handle the rsync problem, so there's
bound to be some cleaner solution, but the point is that we can probably
make mirroring acceptable even with a really really stupid approach. I'd
be a bit ashamed of just how ugly it is, but it would likely _work_ fine.
You'd create 52 pack-files in a year, but each pack-file is likely just
ten megabytes each.
Oh, each pack-file should also be associated with the list of "refs" that
were used to generate that pack-file, so make that 104 files per project
year (but the list of "refs" would usually be something small, like
refs/heads/master 4a89a04f1ee21a7c1f4413f1ad7dcfac50ff9b63
refs/tags/v2.6.11 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
refs/tags/v2.6.11-tree 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
refs/tags/v2.6.12 26791a8bcf0e6d33f43aef7682bdb555236d56de
refs/tags/v2.6.12-rc2 9e734775f7c22d2f89943ad6c745571f1930105f
refs/tags/v2.6.12-rc3 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
refs/tags/v2.6.12-rc4 ebb5573ea8beaf000d4833735f3e53acb9af844c
refs/tags/v2.6.12-rc5 06f6d9e2f140466eeb41e494e14167f90210f89d
refs/tags/v2.6.12-rc6 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e
refs/tags/v2.6.13-rc1 733ad933f62e82ebc92fed988c7f0795e64dea62
which was trivially generated from my current tree with
for i in refs/*/*; do echo -ne $i"\t"; cat $i; done
so now you can use the refs associated with the previous pack-file as the
list of refs you're _not_ interested in, and the current list of refs as
the list you _are_ interested in, and generate the new pack-file.
Generating the pack-file would literally be something like
obj=$(git-rev-parse $(cut -f2 new-list) --not $(cut -f2 old-list))
git-rev-list $obj | git-pack-objects --stdin > new-pack
so a few one-liners like this, run from a cron-job once a week, should
just do it.
Linus
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
Also, the number of people involved isn't _that_ big. We're talking a few
thousand people who actively would update their trees for a big project,
and many smaller projects have anything from a couple to maybe a hundred.
A few mirrors, and you don't have any problem.
So I think that the problem is actually not that big, and we just need to
find an acceptable format. Quite frankly, it might be perfectly acceptable
for kernel.org to run a simple packing script once a week which packs
everything into one single file, and even if that means that the mirrors
will have to re-get everything once a week, that actually sounds
acceptable.
It's obviously a _stupid_ way to handle the rsync problem, so there's
bound to be some cleaner solution, but the point is that we can probably
make mirroring acceptable even with a really really stupid approach. I'd
be a bit ashamed of just how ugly it is, but it would likely _work_ fine.
You'd create 52 pack-files in a year, but each pack-file is likely just
ten megabytes each.
Any reason not to simply append objects to an existing packfile? It
really seems like an easy solutions, and should have relatively good I/O
patterns to boot simply because it naturally creates a topological sort
of the objects.
-hpa
Any reason not to simply append objects to an existing packfile?
What happens when somebody screws up in the middle?
The one thing I care about more than anything else is consistency. We are
careful about writing objects in the right order, and we can re-create the
state from the originator etc. But if we start appending stuff and
something goes wrong in the middle, I'm just not going to touch it. A
"truncate and hope for the best" algorithm?
Besides, the result is not a valid git archive any more.
Linus
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
On Fri, 1 Jul 2005, H. Peter Anvin wrote:
quoted
Any reason not to simply append objects to an existing packfile?
What happens when somebody screws up in the middle?
The one thing I care about more than anything else is consistency. We are
careful about writing objects in the right order, and we can re-create the
state from the originator etc. But if we start appending stuff and
something goes wrong in the middle, I'm just not going to touch it. A
"truncate and hope for the best" algorithm?
Besides, the result is not a valid git archive any more.
It's a log. It's a standard technique to append entries to a log. The
requirements for this to always be consistent is that a) it's possible
to know when the entry/entries at the end are inconsistent and b) it's
always possible to roll back the log to a consistent state.
This is normally done with commit records (write data - fdatasync -
write commit record - fdatasync), but in the case of git, the commit
record isn't required because each git record is self-validating. This
is an incredibly powerful property.
If the log is written in topological sort order, then even a truncated
log file is a valid (subset) git object store.
-hpa
..but that's not what we're looking for. I'm not looking for kernel.org to
be my distributed backup tape.
For it to be useful, it must do more than just log all activity and mirror
it out via rsync. It must also be usable for people pulling on it. Which
means that it has to be a valid git archive or at least easily
incrementally unpackable, so that people can actually use the end result.
A log of packs that are just incremented is certainly unpackable: you
teach git-unpack-objects to just unpack several packs after each other.
But since it's not seekable, you'd have to unpack a 100MB compressed
archive just to get the last tip of it that you don't have unpacked yet.
Also, it means that it's impossible to efficiently do a git-specific
thing. I want people to be able to do what we used to be able to do with
BK: just do a
git pull master.kernel.org:xxxx
and get something useful. And that means _not_ having to pull a 100MB blob
to get the last objects at the end.
And don't tell me "rsync can efficiently get just the end". That's true
for _mirrors_, but it's not true for users that don't have every single
archive on kernel.org. I don't have (and I don't want to have) a copy of
every single persons log that ever might want to push to me.
So no, a log simply isn't useful. It _has_ to be a valid git archive to be
useful. Thousands of objects satisfy that. Or a "few packs + few objects".
Not a log.
Linus
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Linus Torvalds wrote:
..but that's not what we're looking for. I'm not looking for kernel.org to
be my distributed backup tape.
For it to be useful, it must do more than just log all activity and mirror
it out via rsync. It must also be usable for people pulling on it. Which
means that it has to be a valid git archive or at least easily
incrementally unpackable, so that people can actually use the end result.
A log of packs that are just incremented is certainly unpackable: you
teach git-unpack-objects to just unpack several packs after each other.
But since it's not seekable, you'd have to unpack a 100MB compressed
archive just to get the last tip of it that you don't have unpacked yet.
Agreed, you also need an index file. The index file can be recreated
from the log file in case of corruption, but is what you'd use to seek
directly to an object.
-hpa
From: Tony Luck <hidden> Date: 2016-06-15 22:42:01
Here's another approach.
Teach the variants of git-pull to look for a file that names an
alternate repository
that should be used to get any object that is referenced in the repository, but
doesn't exist in it.
At least part of the problem for kernel.org is that there around 50 repositories
that are tracking the 2.6 kernel. All of them have 50,000 objects that are
duplicates of each other ... and a few hundred 'unique' objects that belong
to just one repo, or are minimally shared.
If there was a way to specify an alternate repo, then a large GIT server like
kernel.org could set up a "git-history"[1] repo which each of the hosted repos
could point to. Then a cron job could look for duplicates, and move them
off to the history area.
-Tony
[1] Different projects, like git and sparse, might never have any common
files with the Linux kernel ... but they can all share the same history.
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:42:01
Tony Luck wrote:
At least part of the problem for kernel.org is that there around 50 repositories
that are tracking the 2.6 kernel. All of them have 50,000 objects that are
duplicates of each other ... and a few hundred 'unique' objects that belong
to just one repo, or are minimally shared.
If there was a way to specify an alternate repo, then a large GIT server like
kernel.org could set up a "git-history"[1] repo which each of the hosted repos
could point to. Then a cron job could look for duplicates, and move them
off to the history area.
This is why I've been talking about a global object repository --
including the problems associated with them. git as it currently stands
permit a single global object store, *except* for the issue of duplicate
tags.
-hpa
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:42:01
H. Peter Anvin wrote:
Tony Luck wrote:
quoted
...
This is why I've been talking about a global object repository --
including the problems associated with them. git as it currently stands
permit a single global object store, *except* for the issue of duplicate
tags.
So why not store just the git objects in the global repository and keep
all the things that reference an object (HEAD, branches/*, refs/*/*,
etc.) in a per project and/or contributor area like it is currently?