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

From: "Jeff King" <redacted>

On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:

quoted

quoted

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.

quoted

quoted

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".

quoted

quoted

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).

quoted

"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