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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
