From: Franck <vagabon.xyz@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC] shallow clone
Date: Tue, 31 Jan 2006 10:00:16 +0100 [thread overview]
Message-ID: <cda58cb80601310100o6ca1f0a3g@mail.gmail.com> (raw)
In-Reply-To: <43DF1F1D.1060704@innova-card.com>
2006/1/31, Franck Bui-Huu <fbh.work@gmail.com>:
> Junio C Hamano wrote:
> > Shallow History Cloning
> > =======================
> >
> > One good thing about git repository is that each clone is a
> > freestanding and complete entity, and you can keep developing in
> > it offline, without talking to the outside world, knowing that
> > you can sync with them later when online.
> >
could we be able to make a public repository from such repo ?
> > It is also a bad thing. It gives people working on projects
> > with long development history stored in CVS a heart attack when
> > we tell them that their clones need to store the whole history.
> >
yeah and I haven't survive :)
I didn't notice that other people were asking for this feature, that's great !
> > There was a suggestion by Linus to allow a partial clone using a
> > syntax like this:
[snip]
> >
> > There are some issues.
> >
> > . In the fetch above to obtain everything after v2.6.14, and
> > future runs of `git fetch origin`, if a blob that is in the
> > commit being fetched happens to match what used to be in a
> > commit that is older than v2.6.14 (e.g. a patch was reverted),
> > `upload-pack` running on the other end is free to omit sending
> > it, because we are telling it that we are up to date with
> > respect to v2.6.14. Although I think the current `rev-list
> > --objects` implementation does not always do such a revert
> > optimization if the revert is to a blob in a revision that is
> > sufficiently old, it is free to optimize more aggressively in
> > the future.
> >
oops, I wasn't aware of that. I still can resolve this issue by hand, no ?
> > . Later when the user decides to fetch older history, the
> > operation can become a bit cumbersome.
> >
[snip]
> >
> > Design
> > ------
> >
> > First, to bootstrap the process, we would need to add a way to
> > obtain all objects associated with a commit. We could do a new
> > program, or we could implement this as a protocol extension to
> > `upload-pack`. My current inclination is the latter.
is the document in "Documentation/technical/pack-protocol.txt"
uptodate ? I can't find anything on multi_ack for example.
> >
> > When talking with `upload-pack` that supports this extension,
> > the downloader can give one commit object name and get a pack
> > that contains all the objects in the tree associated with that
> > commit, plus the commit object itself. This is a rough
> > equivalent of running the commit walker with the `-t` flag.
[snip]
> >
> >
> > Anybody want to try?
> >
well, you made almost the job with your analysis, but I've never took
a look to git deep internals and with my lack of time, it would take
too much time...
Thanks
--
Franck
prev parent reply other threads:[~2006-01-31 9:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 7:18 [RFC] shallow clone Junio C Hamano
2006-01-30 11:39 ` Johannes Schindelin
2006-01-30 11:58 ` Simon Richter
2006-01-30 12:13 ` Johannes Schindelin
2006-01-30 13:25 ` Simon Richter
2006-01-30 19:25 ` Junio C Hamano
2006-01-31 11:28 ` Johannes Schindelin
2006-01-31 13:05 ` Simon Richter
2006-01-31 13:31 ` Johannes Schindelin
2006-01-31 14:23 ` Simon Richter
2006-01-30 19:25 ` Junio C Hamano
2006-01-31 8:37 ` Franck
2006-01-31 8:51 ` Junio C Hamano
2006-01-31 11:11 ` Franck
2006-01-30 18:46 ` Junio C Hamano
2006-01-31 11:02 ` [PATCH] Shallow clone: low level machinery Junio C Hamano
2006-01-31 13:58 ` Johannes Schindelin
2006-01-31 17:49 ` Junio C Hamano
2006-01-31 18:06 ` Johannes Schindelin
2006-01-31 18:22 ` Junio C Hamano
2006-02-01 14:33 ` Johannes Schindelin
2006-02-01 20:27 ` Junio C Hamano
2006-02-02 0:48 ` Johannes Schindelin
2006-02-02 1:17 ` Junio C Hamano
2006-02-02 18:44 ` Johannes Schindelin
2006-02-02 19:31 ` Junio C Hamano
2006-01-31 14:20 ` [RFC] shallow clone Johannes Schindelin
2006-01-31 20:59 ` Junio C Hamano
2006-02-01 14:47 ` Johannes Schindelin
[not found] ` <43DF1F1D.1060704@innova-card.com>
2006-01-31 9:00 ` Franck [this message]
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=cda58cb80601310100o6ca1f0a3g@mail.gmail.com \
--to=vagabon.xyz@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).