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@xxxxxxxxxxx' $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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html