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

Reply via email to