From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Philip Oakley <philipoakley@iee.org>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 00/16] First class shallow clone
Date: Wed, 24 Jul 2013 18:50:49 +0200 [thread overview]
Message-ID: <b66fdf09-5e84-4ecc-899d-cebc644f74b7@email.android.com> (raw)
In-Reply-To: <CACsJy8BouRHZAmCKQ779iAUiEX-rK9_FSrxu9V-bn6MCBTBEzg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> napisał:
>On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki
><piotr.krukowiecki@gmail.com> wrote:
>> (resending, as my phone mail client decided to send it in html, sorry
>> about that)
>>
>> On Wed, Jul 24, 2013 at 3:57 AM, Duy Nguyen <pclouds@gmail.com>
>wrote:
>>> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley
><philipoakley@iee.org> wrote:
>>>> There have been comments on the git-user list about the
>>>> problem of accidental adding of large files which then make the
>repo's foot
>>>> print pretty large as one use case [Git is consuming very much
>RAM]. The
>>>> bigFileThreshold being one way of spotting such files as separate
>objects,
>>>> and 'trimming' them.
>>>
>>> I think rewriting history to remove those accidents is better than
>>> working around it (the same for accidentally committing password).
>We
>>> might be able to spot problems early, maybe warn user at commit time
>>> that they have added an exceptionally large blob, maybe before push
>>> time..
>>
>> I can imagine a situation where large files were part of the project
>> at some point in history (they were required to build/use it) and
>> later were removed because build/project has changed.
>>
>> It would be useful to have the history for log/blame/etc even if you
>> could not build/use old versions. A warning when checking
>> out/branching such incomplete tree would be needed.
>
>That's what shallow clone is for. You fetch the latest (not including
>old large blobs) and work on top. For archaeology, make a full clone.
>Or do you mean log/blame/etc other paths that don't touch big blobs,
>and the clone is still incomplete?
Yes, for example if large files were removed recently the last-n-commits-shallow would be useless from blame/log POV.
prev parent reply other threads:[~2013-07-24 16:51 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 12:47 [PATCH 0/7] First class shallow clone Nguyễn Thái Ngọc Duy
2013-07-17 12:47 ` [PATCH 1/7] transport.h: remove send_pack prototype, already defined in send-pack.h Nguyễn Thái Ngọc Duy
2013-07-17 12:47 ` [PATCH 2/7] {receive,upload}-pack: advertise shallow graft information Nguyễn Thái Ngọc Duy
2013-07-17 12:47 ` [PATCH 3/7] connect.c: teach get_remote_heads to parse "shallow" lines Nguyễn Thái Ngọc Duy
2013-07-20 3:27 ` Junio C Hamano
2013-07-17 12:47 ` [PATCH 4/7] Move setup_alternate_shallow and write_shallow_commits to shallow.c Nguyễn Thái Ngọc Duy
2013-07-17 12:47 ` [PATCH 5/7] fetch-pack: support fetching from a shallow repository Nguyễn Thái Ngọc Duy
2013-07-20 3:17 ` Junio C Hamano
2013-07-17 12:47 ` [PATCH 6/7] {send,receive}-pack: support pushing from a shallow clone Nguyễn Thái Ngọc Duy
2013-07-17 12:47 ` [PATCH 7/7] send-pack: support pushing to " Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 00/16] First class " Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 01/16] send-pack: forbid pushing from a shallow repository Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 02/16] {receive,upload}-pack: advertise shallow graft information Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 03/16] connect.c: teach get_remote_heads to parse "shallow" lines Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 04/16] Move setup_alternate_shallow and write_shallow_commits to shallow.c Nguyễn Thái Ngọc Duy
2013-07-20 9:57 ` [PATCH v2 05/16] fetch-pack: support fetching from a shallow repository Nguyễn Thái Ngọc Duy
2013-07-22 19:10 ` Philip Oakley
2013-07-23 2:06 ` Duy Nguyen
2013-07-23 14:39 ` Duy Nguyen
2013-07-20 9:58 ` [PATCH v2 06/16] {send,receive}-pack: support pushing from a shallow clone Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 07/16] send-pack: support pushing to " Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 08/16] upload-pack: let pack-objects do the object counting in shallow case Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 09/16] pack-protocol.txt: a bit about smart http Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 10/16] Add document for command arguments for supporting " Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 11/16] {fetch,upload}-pack: support fetching from a shallow clone via " Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 12/16] receive-pack: support pushing to a shallow clone via http Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 13/16] send-pack: support pushing from " Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 14/16] git-clone.txt: remove shallow clone limitations Nguyễn Thái Ngọc Duy
2013-07-20 9:58 ` [PATCH v2 15/16] config: add core.noshallow to prevent turning a repo into a shallow one Nguyễn Thái Ngọc Duy
2013-07-22 19:23 ` Philip Oakley
2013-07-23 1:28 ` Duy Nguyen
2013-07-23 4:06 ` Junio C Hamano
2013-07-23 19:44 ` Philip Oakley
2013-07-20 9:58 ` [PATCH v2 16/16] clone: use git protocol for cloning shallow repo locally Nguyễn Thái Ngọc Duy
2013-07-22 23:41 ` [PATCH v2 00/16] First class shallow clone Philip Oakley
2013-07-23 1:20 ` Duy Nguyen
2013-07-23 4:08 ` Junio C Hamano
2013-07-23 5:01 ` Duy Nguyen
2013-07-23 22:33 ` Philip Oakley
2013-07-24 1:57 ` Duy Nguyen
2013-07-24 7:38 ` Philip Oakley
2013-07-24 8:30 ` Piotr Krukowiecki
2013-07-24 10:35 ` Duy Nguyen
2013-07-24 16:50 ` Piotr Krukowiecki [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=b66fdf09-5e84-4ecc-899d-cebc644f74b7@email.android.com \
--to=piotr.krukowiecki@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=philipoakley@iee.org \
/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).