* git replace --graft does error checking too late @ 2019-03-27 10:22 Andreas Schwab 2019-03-27 13:11 ` Christian Couder 0 siblings, 1 reply; 4+ messages in thread From: Andreas Schwab @ 2019-03-27 10:22 UTC (permalink / raw) To: git When running `git replace --graft A B' where B is a non-commit (eg. a tag) it displays an error, but creates the replace ref anyway. I think it should verify that B names a commit object before creating the ref. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git replace --graft does error checking too late 2019-03-27 10:22 git replace --graft does error checking too late Andreas Schwab @ 2019-03-27 13:11 ` Christian Couder 2019-03-27 13:21 ` Christian Couder 0 siblings, 1 reply; 4+ messages in thread From: Christian Couder @ 2019-03-27 13:11 UTC (permalink / raw) To: Andreas Schwab; +Cc: git On Wed, Mar 27, 2019 at 11:24 AM Andreas Schwab <schwab@suse.de> wrote: > > When running `git replace --graft A B' where B is a non-commit (eg. a > tag) it displays an error, Yeah, it seems that when A is a commit and B a tag I get: "error: object A is a tag, not a commit" which is wrong as A is a commit. > but creates the replace ref anyway. I think > it should verify that B names a commit object before creating the ref. Accepting a tag and using the commit the tag points to could be useful. For example someone could look at the commit graph, then decide to tag the commit(s) that should be used when replacing, and then use `git replace --graft A <tag>...` using the created tag(s). (I checked the code in builtin/replace.c and it seems that we use lookup_commit_reference() on each of the new parents, so we should be safe in case one of the given new parents cannot be peeled into a commit.) So it seems to me that the issue is that it shows a wrong error when it shouldn't show anything, or perhaps only a warning. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git replace --graft does error checking too late 2019-03-27 13:11 ` Christian Couder @ 2019-03-27 13:21 ` Christian Couder 2019-03-28 7:35 ` Christian Couder 0 siblings, 1 reply; 4+ messages in thread From: Christian Couder @ 2019-03-27 13:21 UTC (permalink / raw) To: Andreas Schwab; +Cc: git On Wed, Mar 27, 2019 at 2:11 PM Christian Couder <christian.couder@gmail.com> wrote: > > On Wed, Mar 27, 2019 at 11:24 AM Andreas Schwab <schwab@suse.de> wrote: > > > > When running `git replace --graft A B' where B is a non-commit (eg. a > > tag) it displays an error, > > Yeah, it seems that when A is a commit and B a tag I get: > > "error: object A is a tag, not a commit" > > which is wrong as A is a commit. Actually I get the above only if A is a commit but there is a tag pointing to it. If there is no tag pointing to it I get: error: object C is a tag, not a commit where C is the hash of the tag object B (C=$(git rev-parse B)) So yeah, this is weird. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git replace --graft does error checking too late 2019-03-27 13:21 ` Christian Couder @ 2019-03-28 7:35 ` Christian Couder 0 siblings, 0 replies; 4+ messages in thread From: Christian Couder @ 2019-03-28 7:35 UTC (permalink / raw) To: Andreas Schwab; +Cc: git On Wed, Mar 27, 2019 at 2:21 PM Christian Couder <christian.couder@gmail.com> wrote: > > On Wed, Mar 27, 2019 at 2:11 PM Christian Couder > <christian.couder@gmail.com> wrote: > > > > On Wed, Mar 27, 2019 at 11:24 AM Andreas Schwab <schwab@suse.de> wrote: > > > > > > When running `git replace --graft A B' where B is a non-commit (eg. a > > > tag) it displays an error, > > > > Yeah, it seems that when A is a commit and B a tag I get: > > > > "error: object A is a tag, not a commit" > > > > which is wrong as A is a commit. > > Actually I get the above only if A is a commit but there is a tag > pointing to it. If there is no tag pointing to it I get: > > error: object C is a tag, not a commit > > where C is the hash of the tag object B (C=$(git rev-parse B)) > > So yeah, this is weird. I think I understand what happens. It seems that we put the SHA-1 of the tag in the new object we create instead of the SHA-1 of the underlying commit and that's what generates the error message and other issues later. The following patch (that unfortunately Gmail is likely to muck) should fix at least part of the issue. I will send a real patch with tests later. diff --git a/builtin/replace.c b/builtin/replace.c index f5701629a8..b0a9227f9a 100644 --- a/builtin/replace.c +++ b/builtin/replace.c @@ -370,16 +370,19 @@ static int replace_parents(struct strbuf *buf, int argc, const char **argv) /* prepare new parents */ for (i = 0; i < argc; i++) { struct object_id oid; + struct commit *commit; + if (get_oid(argv[i], &oid) < 0) { strbuf_release(&new_parents); return error(_("not a valid object name: '%s'"), argv[i]); } - if (!lookup_commit_reference(the_repository, &oid)) { + commit = lookup_commit_reference(the_repository, &oid); + if (!commit) { strbuf_release(&new_parents); - return error(_("could not parse %s"), argv[i]); + return error(_("could not parse %s as a commit"), argv[i]); } - strbuf_addf(&new_parents, "parent %s\n", oid_to_hex(&oid)); + strbuf_addf(&new_parents, "parent %s\n", oid_to_hex(&commit->object.oid)); } /* replace existing parents with new ones */ ^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-28 7:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-03-27 10:22 git replace --graft does error checking too late Andreas Schwab 2019-03-27 13:11 ` Christian Couder 2019-03-27 13:21 ` Christian Couder 2019-03-28 7:35 ` Christian Couder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).