git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Franck <vagabon.xyz@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [QUESTION] about .git/info/grafts file
Date: Thu, 19 Jan 2006 11:51:22 +0100	[thread overview]
Message-ID: <cda58cb80601190251v5251c8bdh@mail.gmail.com> (raw)
In-Reply-To: <7v8xtdrqwg.fsf@assigned-by-dhcp.cox.net>

Thanks Junio for answering

2006/1/19, Junio C Hamano <junkio@cox.net>:
> Franck <vagabon.xyz@gmail.com> writes:
>
> > I'm wondering why the "grafts" files is not involved during
> > push/pull/clone operations ?
>
> Commit ancestry grafting is a local repository issue and even if
> you manage to lie to your local git that 300,000th commit is the
> epoch, the commit object you send out to the downloader would
> record its true parent (or parents, if it is a merge), so the
> downloader would want to go further back.  And no, rewriting
> that commit and feeding a parentless commit to the downloader is
> not an option, because such a commit object would have different
> object name and unpack-objects would be unhappy.
>
> If you choose not to have full history in your public repository
> for whatever reason (ISP server diskquota comes to mind)

well, dealing with a repo that has more than 300,000 objects becomes a
burden. A lots of git commands are slow, and cloning it take a while !

> that is
> OK, but be honest about it to your downloaders.  Tell them that
> you do not have the full history, and they first need to clone
> from some other repository you started your development upon, in
> order to use what you added upon.  "This repository does not
> have all the history -- please first clone from XX repository
> (you need at least xxx commit), and then do another 'git pull'
> from here", or something like that.
>

I don't try to hide or lie to my downloaders. I just want them to
avoid to deal with totaly pointless history. My work have been started
recently and is based on current XX repository. IMHO storing, dealing
with objects which are more than 10 years old is useless.

I don't see why it is so bad to create a "grafted" repository ? I want
it to be small but still want to merge by using git-resolve with XX
repository.

>
> >                $ git-merge-base master origin
> >                # nothing
>
> Maybe you did not use grafts properly to cauterize?

Well in my graft file I did:

                    $ cat > .git/info/grafts
                    <shaid> <shaid>

                    $

By reading "Documentation/repository-layout.txt", I thought it would
have been the right thing to do. If I did the same like you did ie:

                    $ cat > .git/info/grafts
                    <shaid>

                    $

It works.

Thanks
--
               Franck

  reply	other threads:[~2006-01-19 10:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cda58cb80601170928r252a6e34y@mail.gmail.com>
2006-01-17 17:32 ` [QUESTION] about .git/info/grafts file Franck
2006-01-18 17:47   ` Franck
2006-01-19  0:40   ` Junio C Hamano
2006-01-19 10:51     ` Franck [this message]
2006-01-19 13:09       ` Petr Baudis
2006-01-19 16:58         ` Linus Torvalds
2006-01-19 17:30           ` Petr Baudis
2006-01-19 17:33           ` Franck
2006-01-19 17:49             ` Linus Torvalds
2006-01-19 18:24           ` Junio C Hamano
2006-01-19 18:24       ` Junio C Hamano
2006-01-20 13:43         ` Franck
2006-01-19 11:10     ` Andreas Ericsson
2006-01-19 13:05       ` Petr Baudis
2006-01-19 13:31       ` Franck
2006-01-19 13:44         ` Andreas Ericsson
2006-01-19 17:45           ` Petr Baudis
2006-01-20 20:48           ` Ryan Anderson
2006-01-20  1:14     ` Junio C Hamano
2006-01-20 10:07       ` Franck
2006-01-20 17:59         ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cda58cb80601190251v5251c8bdh@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.
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 NNTP newsgroup(s).