All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: git@vger.kernel.org
Subject: Cover grafting in the Git User's Manual
Date: Wed, 28 Nov 2007 19:23:01 +0100	[thread overview]
Message-ID: <87ejeateka.fsf@pike.pond.sub.org> (raw)

The only mention of grafting in the manual is in the glossary:

    Grafts enables two otherwise different lines of development to
    be joined together by recording fake ancestry information for
    commits. This way you can make git pretend the set of parents
    a commit has is different from what was recorded when the
    commit was created. Configured via the .git/info/grafts file.

I believe it would be useful to cover this better, perhaps in chapter
5. Rewriting history and maintaining patch series.  It certainly would
have saved me a few hours of digging.  I already understood enough of
git to *know* that what I wanted must be possible (supply missing
parents of merges in a repository imported with parsecvs), but I
didn't know the magic keyword was graft.  I managed to figure it out
from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.

I'm neither writer nor git expert, but here's my try anyway:

Rewriting ancestry with grafts

Grafts enables two otherwise different lines of development to be
joined together by recording fake ancestry information for commits.
This way you can make git pretend the set of parents a commit has is
different from what was recorded when the commit was created.

Why would you want to do that?  Say, you imported a repository from an
SCM that doesn't record merges properly, e.g. CVS.  Grafts let you add
the missing parents to the merge commits.  Or you switched your
project to git by populating a new repository with current sources,
and later decide you want more history.  Committing old versions is
easy enough, but you also need to graft a parent to your original root
commit.

Graft points are configured via the .git/info/grafts file.  It has one
record per line describing a commit and its fake parents by listing
object names separated by a space and terminated by a newline.

    <commit sha1> <parent sha1> [<parent sha1>]*

A graft point does not actually change its commit.  Nothing can.  What
can be done is rewriting the commit and its descendants.
git-filter-branch does that:

    $ cat .git/info/grafts
    db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251
    git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251

This rewrites history between head and the graft-point to include the
grafted parents.

             reply	other threads:[~2007-11-28 18:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 18:23 Markus Armbruster [this message]
2007-11-28 18:42 ` Cover grafting in the Git User's Manual Peter Baumann
2007-11-29 13:20   ` Markus Armbruster
2007-11-29 18:10     ` Peter Baumann

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=87ejeateka.fsf@pike.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=git@vger.kernel.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.