# [PATCH] replace: forbid replacing an object with one of a different type 4 messages from 2013-08-07 to 2013-08-08. Participants: Christian Couder, Thomas Rast, Philip Oakley, Junio C Hamano. Thread: https://gitlist.dev/t/34629 ## Christian Couder, 2013-08-07 04:42 Subject: [PATCH] replace: forbid replacing an object with one of a different type Message-ID: <20130807044248.17464.35806.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/20130807044248.17464.35806.chriscool%40tuxfamily.org ``` Users replacing an object with one of a different type were not prevented to do so, even if it was obvious, and stated in the doc, that bad things would result from doing that. To avoid mistakes, it is better to just forbid that though. The doc will be updated in a later patch. Signed-off-by: Christian Couder --- If this patch is considered useful, I will update the doc and maybe add tests. builtin/replace.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/builtin/replace.c b/builtin/replace.c index 59d3115..0246ab3 100644 --- a/builtin/replace.c +++ b/builtin/replace.c @@ -85,6 +85,7 @@ static int replace_object(const char *object_ref, const char *replace_ref, int force) { unsigned char object[20], prev[20], repl[20]; + enum object_type obj_type, repl_type; char ref[PATH_MAX]; struct ref_lock *lock; @@ -100,6 +101,14 @@ static int replace_object(const char *object_ref, const char *replace_ref, if (check_refname_format(ref, 0)) die("'%s' is not a valid ref name.", ref); + obj_type = sha1_object_info(object, NULL); + repl_type = sha1_object_info(repl, NULL); + if (obj_type != repl_type) + die("Object ref '%s' is of type '%s'\n" + "while replace ref '%s' is of type '%s'.", + object_ref, typename(obj_type), + replace_ref, typename(repl_type)); + if (read_ref(ref, prev)) hashclr(prev); else if (!force) -- 1.8.4.rc1.22.g132b1a0 ``` ## Thomas Rast, 2013-08-07 08:46 Subject: Re: [PATCH] replace: forbid replacing an object with one of a different type Message-ID: <87iozhyjki.fsf@linux-k42r.v.cablecom.net> URL: https://gitlist.dev/e/87iozhyjki.fsf%40linux-k42r.v.cablecom.net In-Reply-To: <20130807044248.17464.35806.chriscool@tuxfamily.org> ``` Christian Couder writes: > Users replacing an object with one of a different type were not > prevented to do so, even if it was obvious, and stated in the doc, > that bad things would result from doing that. > > To avoid mistakes, it is better to just forbid that though. > > The doc will be updated in a later patch. > > Signed-off-by: Christian Couder Feel free to steal some of my other email for the commit message, to write down for posterity that reverting would not really be a useful step. The patch looks good to me. > If this patch is considered useful, I will update the doc and > maybe add tests. > > builtin/replace.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/builtin/replace.c b/builtin/replace.c > index 59d3115..0246ab3 100644 > --- a/builtin/replace.c > +++ b/builtin/replace.c > @@ -85,6 +85,7 @@ static int replace_object(const char *object_ref, const char *replace_ref, > int force) > { > unsigned char object[20], prev[20], repl[20]; > + enum object_type obj_type, repl_type; > char ref[PATH_MAX]; > struct ref_lock *lock; > > @@ -100,6 +101,14 @@ static int replace_object(const char *object_ref, const char *replace_ref, > if (check_refname_format(ref, 0)) > die("'%s' is not a valid ref name.", ref); > > + obj_type = sha1_object_info(object, NULL); > + repl_type = sha1_object_info(repl, NULL); > + if (obj_type != repl_type) > + die("Object ref '%s' is of type '%s'\n" > + "while replace ref '%s' is of type '%s'.", > + object_ref, typename(obj_type), > + replace_ref, typename(repl_type)); > + > if (read_ref(ref, prev)) > hashclr(prev); > else if (!force) -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Philip Oakley, 2013-08-08 21:09 Subject: Re: [PATCH] replace: forbid replacing an object with one of a different type Message-ID: URL: https://gitlist.dev/e/A88E12BCC58A401DBDD2EB300C1AAA2D%40PhilipOakley In-Reply-To: <20130807044248.17464.35806.chriscool@tuxfamily.org> ``` From: "Christian Couder" Sent: Wednesday, August 07, 2013 5:42 AM > Users replacing an object with one of a different type were not > prevented to do so, even if it was obvious, and stated in the doc, > that bad things would result from doing that. > > To avoid mistakes, it is better to just forbid that though. > > The doc will be updated in a later patch. > > Signed-off-by: Christian Couder > --- > If this patch is considered useful, I will update the doc and > maybe add tests. Acked-by: Philip Oakley Improved documentation would always be useful. > > builtin/replace.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/builtin/replace.c b/builtin/replace.c > index 59d3115..0246ab3 100644 > --- a/builtin/replace.c > +++ b/builtin/replace.c > @@ -85,6 +85,7 @@ static int replace_object(const char *object_ref, > const char *replace_ref, > int force) > { > unsigned char object[20], prev[20], repl[20]; > + enum object_type obj_type, repl_type; > char ref[PATH_MAX]; > struct ref_lock *lock; > > @@ -100,6 +101,14 @@ static int replace_object(const char *object_ref, > const char *replace_ref, > if (check_refname_format(ref, 0)) > die("'%s' is not a valid ref name.", ref); > > + obj_type = sha1_object_info(object, NULL); > + repl_type = sha1_object_info(repl, NULL); Do (very) large blobs have any issues here? As I understand it, such blobs, as with other smaller objects, need to be expanded to determine the type. Is there a heuristic (and is it worth it) to do a 'large object == blob' initial check to avoid such an expansion? Small objects shouldn't be an overhead. Just a thought. > + if (obj_type != repl_type) > + die("Object ref '%s' is of type '%s'\n" > + "while replace ref '%s' is of type '%s'.", > + object_ref, typename(obj_type), > + replace_ref, typename(repl_type)); Perhaps start with "Objects must be of the same type.\n" > + > if (read_ref(ref, prev)) > hashclr(prev); > else if (!force) > -- > 1.8.4.rc1.22.g132b1a0 ``` ## Junio C Hamano, 2013-08-08 21:38 Subject: Re: [PATCH] replace: forbid replacing an object with one of a different type Message-ID: <7vsiyj982w.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsiyj982w.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` "Philip Oakley" writes: > From: "Christian Couder" > Sent: Wednesday, August 07, 2013 5:42 AM >> Users replacing an object with one of a different type were not >> prevented to do so, even if it was obvious, and stated in the doc, >> that bad things would result from doing that. >> >> To avoid mistakes, it is better to just forbid that though. >> >> The doc will be updated in a later patch. >> >> Signed-off-by: Christian Couder >> --- >> If this patch is considered useful, I will update the doc and >> maybe add tests. > > Acked-by: Philip Oakley > Improved documentation would always be useful. Will wait for a reroll with tests and doc updates, then. >> @@ -100,6 +101,14 @@ static int replace_object(const char *object_ref, >> const char *replace_ref, >> if (check_refname_format(ref, 0)) >> die("'%s' is not a valid ref name.", ref); >> >> + obj_type = sha1_object_info(object, NULL); >> + repl_type = sha1_object_info(repl, NULL); > > Do (very) large blobs have any issues here? As I understand it, such > blobs, as with other smaller objects, need to be expanded to determine > the type. sha1_object_info() is coded to peek into only the early part of a loose object or the object header part of a packed object. Loose ones we do mmap(), but we only inflate a tiny bit (the first 32 bytes). >> + if (obj_type != repl_type) >> + die("Object ref '%s' is of type '%s'\n" >> + "while replace ref '%s' is of type '%s'.", >> + object_ref, typename(obj_type), >> + replace_ref, typename(repl_type)); > > Perhaps start with "Objects must be of the same type.\n" Yes. ```