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

From: Jeff King <peff@peff.net>
Date: Mar 6, 2014, 17:48 UTC
Message-ID: <20140306174803.GA30486@sigill.intra.peff.net>
In-Reply-To: <5318A537.4010400@alum.mit.edu>

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

Show 5 quoted lines

> > 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! ;)

It should be easy to do "--convert-grafts", though, and I think it fits into the scheme we're discussing below.

Show 9 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

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