From: Linus Torvalds <torvalds@osdl.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: git@vger.kernel.org
Subject: Re: git push sends more objects than it needs to
Date: Mon, 31 Oct 2005 11:36:09 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0510311119170.27915@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0510311035310.27915@g5.osdl.org>
On Mon, 31 Oct 2005, Linus Torvalds wrote:
> >
> > Now the "unpack" on kernel.org did the right thing and noticed
> > that over 9000 of the objects were already in the packfile. But
> > I wonder if it couldn't have been smarter and not sent them?
>
> It should have been smarter, but I suspect you got caught by the fact that
> kernel.org by default has git-0.99.8f on it, which has the old
> pre-multi_ack code to figure out what the common commit was.
Oh, actually, I take that back.
This is not the multi-ack code at all, I suspect.
The problem is totally different: you copied the new pack to your
master.kernel.org repository, but you never updated any branches there.
So you had the objects, but git had no way of knowing. The pack generation
doesn't look at what _objects_ you have, it looks at what _refs_ you have.
And your refs were all to the old state.
So git actually did everything right (you can never rely on objects: you
may have a partial object list due to some earlier incomplete pull/push).
This is actually easy enough to fix up in one of several ways:
a) The "don't do that then" approach:
Don't go behind git's back and add objects on your own, and expect git
to realize what you did. ;^p
b) The "live with it" approach:
You copied the pack by hand, and that will keep git-unpack-objects
from duplicating the objects, but you'll still waste time and network
when trying pushing the objects (just once, though).
Ie this is what happened this time: nothing really lost, and the end
result is fine. Now you know why it happened, and you're fine.
c) The "I'm smarter than git" approach:
When you copy my objects, copy my reference to the top-of-tree too
(and rename it). NOTE! Now you need to be really careful, and you need
to make sure you copy _all_ the objects, because if you screw this up,
your repo will be missing objects that you claim are there, and it
will be all your fault.
I really don't advocate this approach at all. It's certainly doable,
but it's also the only approach where you can really screw up.
d) Just let git do it for you.
Copy the pack-files, or add my object directory as an "alternates" for
your object directory, do the "git prune-objects", and then _locally_
on master.kernel.org just do something like
git fetch ..linus-directory.. master:linus
which will still create the unnecessary pack-file and unpack it into
nothingness (since you have the objects in the pack-file you copied by
hand), but at least it won't eat any network bandwidth, and it will do
the right thing if it turns out that I've pushed something after doing
the pack-file, and fetch those individual objects in _addition_ to the
pack-file you snarfed by hand. It will also obviously update a ref in
your tree (the "linus" branch), so now when you send stuff later, it
will know all about the objects you already have.
e) Re-create the tree entirely
Blow away your tree on master entirely, just re-create it locally with
"git clone -l -s" from my tree (which will do all the "alternates"
object files for you), and then populate the result with a simple push
from your home tree.
f) any number of variations on a theme. IOW, there are endless ways to do
this.
Hmm?
Linus
next prev parent reply other threads:[~2005-10-31 19:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 18:23 git push sends more objects than it needs to Luck, Tony
2005-10-31 18:44 ` Linus Torvalds
2005-10-31 19:36 ` Linus Torvalds [this message]
2005-10-31 19:50 ` Luck, Tony
2005-10-31 18:49 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0510311119170.27915@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).