Re: [RFC/PATCH] replace: add --graft option

[Jeff King <peff@peff.net>]

On Sun, May 18, 2014 at 08:29:38PM +0200, Christian Couder wrote:

> +static int create_graft(int argc, const char **argv, int force)
> +{
> +	unsigned char old[20], new[20];
> +	const char *old_ref = argv[0];
> +	struct strbuf buf = STRBUF_INIT;
> +	struct strbuf new_parents = STRBUF_INIT;
> +	const char *parent_start, *parent_end;
> +	int i;
> +
> +	if (get_sha1(old_ref, old) < 0)
> +		die(_("Not a valid object name: '%s'"), old_ref);
> +	lookup_commit_or_die(old, old_ref);
> +	if (read_sha1_commit(old, &buf))
> +		die(_("Invalid commit: '%s'"), old_ref);

Do we want to peel to commits here? That is, should:

  git replace --graft v1.5.0 v1.4.0

work? On the one hand, I see it as friendly. On the other, it may be a
bit surprising when working with something as potentially dangerous a
replace refs. If we don't do it automatically, the user can still say
"v1.5.0^{commit}" to be explicit. I dunno; maybe I am being overly
paranoid.

> +	/* prepare new parents */
> +	for (i = 1; i < argc; i++) {
> +		unsigned char sha1[20];
> +		if (get_sha1(argv[i], sha1) < 0)
> +			die(_("Not a valid object name: '%s'"), argv[i]);
> +		lookup_commit_or_die(sha1, argv[i]);
> +		strbuf_addf(&new_parents, "parent %s\n", sha1_to_hex(sha1));
> +	}

Either way, I think _this_ peeling is a sane thing to do.

-Peff