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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 03/06/2014 04:56 PM, Jeff King wrote:
> On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:
> 
>> 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.
> 
>> * 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.

>> * 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/