Re: [PATCH] disable grafts during fetch/push/bundle

On 03/06/2014 04:56 PM, Jeff King wrote:

On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:

quoted

Replace objects are better than grafts in *almost* every dimension.  The
exception is that it is dead simple to create grafts, whereas I always
have to break open the man pages to remember how to create a replace
object that does the same thing.

So I think a helpful step towards deprecating grafts would be to offer a
couple of convenience features to help people kick the "grafts" habit:

I agree that better tool support would make "git replace" more pleasant
to use.

quoted

* A tool that converts grafts (i.e., the grafts read from
$GIT_DIR/info/grafts) into the equivalent replacements.

I don't know if this is strictly necessary, if we make your command
below pleasant to use. I.e., it should just be:

  while read sha1 parents; do
    git replace --graft $sha1 $parents
  done <.git/info/grafts

We can wrap that in "git replace --convert-grafts", but I do not think
grafts are so common that there would be a big demand for it.

It's probably easier to wrap it than to explain to Windows users what
they have to do.

quoted

* A tool that creates a new replacement object that is the equivalent of
a graft.  I.e., it should do, using replace references, the equivalent
of the following command:

      echo SHA1 [PARENT1...] >>$GIT_DIR/info/grafts

These features could be added to "git replace" or could be built into a
new "git grafts" command.

I think it would be nice to have a set of "mode" options for
"git-replace" to do basic editing of a sha1 and install the result
(technically you could split the editing into a separate command, but I
do not see the point in editing a sha1 and then _not_ replacing it).

If modifying without replacing is needed, it would be pretty easy to add
an option --stdout that writes the SHA1 of the modified object to stdout
instead of creating a replace reference.  That way what you want 95% of
the time is the default but there is still an escape hatch.

Perhaps:

  # pretty-print sha1 based on type, start $EDITOR, create a
  # type-appropriate object from the result (e.g., using hash-object,
  # mktree, or mktag), and then set up the object as a replacement for
  # SHA1
  git replace --edit SHA1

  # ditto, but replace the $EDITOR step with the parent list
  git replace --graft SHA1 PARENT1 PARENT2

  # ...or remove entries from a tree
  git replace --remove-entry SHA1 foo bar

I like this idea a lot, especially the pretty-printer round-tripping.

"git replace" could support some of the options that "git filter-branch"
can take, like --env-filter, --msg-filter, etc. (at least if the target
is a commit object).

All of this would make it possible to build up the changes that you want
to integrate via "filter-branch" piecemeal instead of having to have a
single monster filter-branch invocation.  For example,

    for c in $(git rev-list --all --before=2007-01-01
--author=root@localhost)
    do
        git replace --env-filter 'export AUTHOR_EMAIL=john@example.com' $c
    done
    # Make some more changes to other commits...
    # And when everything is done and checked:
    git filter-branch --all --tag-name-filter=cat

To me this is easier to construct than the equivalent filter-branch
invocation, and can be faster because its processing can be more easily
limited to the commits that need it.  Of course to really gain speed,
there should be a C program that bakes in replace references by
traversing the object tree rather than processing each commit
separately, like filter-branch.  I predict that this approach would have
most of the speed of BFG.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/