From: "Jeff King" <peff@xxxxxxxx>
On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
> 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.
How would Windows users get a graft file in the first-place? There's
no
GUI for it! ;)
Now, now... It's dead easy using the git-gui and Notepad++, you can see
and confirm the sha1's, copy and paste, and the graft file is a very
easy format, so even wimps (windows, icons, menus, pointers aka mouse)
folks can do it. (It worked for me when I needed it ;-)
The main point is that grafts are very easy to create [1], in that there
is no object manipulation, while the replace mechanism does need a fresh
object to be created that will 'replace' the old object. This
manipulation can be perceived at least an awkward step. The replace
mechanism needs to be at least as easy as the graft.
Something as simple as the 'git replace --graft $sha1 $parents' idea
would make it very easy to deprecate the older graft process with this
conceptually almost identical syntax. There are a few other
documentation places that should also be updated when its sorted [2].
It should be easy to do "--convert-grafts", though, and I think it
fits
into the scheme we're discussing below.
> 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.
Agreed. I had originally though that perhaps something like this
should
be part of "hash-object", and that "replace" should farm out the work.
But thinking on it more, it doesn't really make sense as part of
"hash-object".
> 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
Here's a rough series that gets us this far:
[1/4]: replace: refactor command-mode determination
[2/4]: replace: use OPT_CMDMODE to handle modes
[3/4]: replace: factor object resolution out of replace_object
[4/4]: replace: add --edit option
It shouldn't be too hard to do "--graft" or "--convert-grafts" on top.
I also noticed that doing:
git replace foo foo
is less than friendly (we notice the cycle, but just barf). It's
especially easy to do with "git replace --edit", if you just exit the
editor without making changes. Or if you make changes to an
already-replaced object to revert it back, in which case we would want
to notice and delete the replacement.
So I think we want to have "git replace foo foo" silently converted
into
"git replace -d foo" (but without an error if there is no existing
replacement), and then "--edit" will just do the right thing, as it's
built on top.
I also noticed that the diff engine does not play well with
replacements
of blobs. When we are diffing the trees, we see that the sha1 for path
"foo" is the same on either side, and do not look further, even though
feeding those sha1s to builtin_diff would fetch the replacements. I
think compare_tree_entry would have to learn lookup_replace_object
(and
I suspect it would make tree diffs noticeably slower when you have
even
one replace ref).
"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,
Right. I was tempted to suggest that, too, but I think it can get
rather
tricky, as you need to replace in a loop, and sometimes the exact
objects you need aren't obvious. For example, a common use of
"--index-filter" is to remove a single file. But to remove
"foo/bar/baz", you would need to loop over each commit, find the tree
for "foo/bar", and then remove the "baz" entry in
Still, I really like the workflow of having decent "replace" tools,
followed by "cementing" the changes into place with a "filter-branch"
run (which, btw, does not yet know how to cement trees and blobs into
place). It lets you work on the filtering incrementally, and even
share
or work collaboratively on it by pushing refs/replace).
And as you mention, it could be a heck of a lot faster than what we
have
now.
-Peff
--
Philip
[1] https://git.wiki.kernel.org/index.php/GraftPoint
[2] http://stackoverflow.com/q/6800692/717355
--
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