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