On 04/28/2015 12:08 AM, Eric Sunshine wrote:
On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak karthik@gmail.com wrote:
On 04/25/2015 10:34 PM, Junio C Hamano wrote:
karthik nayak karthik@gmail.com writes:
Yes this gives the best description, but its large, while we could use
something
On 04/25/2015 10:34 PM, Junio C Hamano wrote:
karthik nayak karthik@gmail.com writes:
Is there any other way to make cat-file looser other than accepting
an unknown type name from the future? If not, then perhaps it may
make sense to give it a generic name that implies that we would
On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak karthik@gmail.com wrote:
On 04/25/2015 10:34 PM, Junio C Hamano wrote:
karthik nayak karthik@gmail.com writes:
Yes this gives the best description, but its large, while we could use
something like --no-strict instead.
We could, if you
karthik nayak karthik@gmail.com writes:
Is there any other way to make cat-file looser other than accepting
an unknown type name from the future? If not, then perhaps it may
make sense to give it a generic name that implies that we would
trigger such additional looseness in the future.
On 04/22/2015 02:06 AM, Junio C Hamano wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
It's easy to be blinded into thinking that cat-file's new option
should be named --literally since it was inspired by the --literally
option of hash-object, but indeed it may not be the best choice.
On Tue, Apr 21, 2015 at 6:16 AM, Charles Bailey char...@hashpling.org wrote:
On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote:
On 04/20/2015 02:49 PM, Charles Bailey wrote:
As far as I could tell - and please correct me if I've misunderstood,
cat-file's literally is about dealing
On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote:
On 04/20/2015 02:49 PM, Charles Bailey wrote:
As far as I could tell - and please correct me if I've misunderstood,
cat-file's literally is about dealing with unrecognized types whereas
hash-object's --literally is about both
Eric Sunshine sunsh...@sunshineco.com writes:
It's easy to be blinded into thinking that cat-file's new option
should be named --literally since it was inspired by the --literally
option of hash-object, but indeed it may not be the best choice.
Yeah, I wouldn't even say inspired. It was
On Mon, Apr 20, 2015 at 02:27:44PM +0530, Karthik Nayak wrote:
Sorry, but I didn't get you, broken objects created using hash-object
--literally do not work with cat-file without the --literally option.
Perhaps an example would help:
I cannot create a bad tree without --literally:
$ echo
On April 20, 2015 1:14:34 PM GMT+05:30, Charles Bailey char...@hashpling.org
wrote:
On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
The option isn't a true opposite of hash-object's --literally
because
that also allows the
On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
The option isn't a true opposite of hash-object's --literally because
that also allows the creation of known types with invalid contents (e.g.
corrupt trees) whereas cat-file is
On 04/20/2015 02:49 PM, Charles Bailey wrote:
On Mon, Apr 20, 2015 at 02:27:44PM +0530, Karthik Nayak wrote:
Sorry, but I didn't get you, broken objects created using hash-object
--literally do not work with cat-file without the --literally option.
Perhaps an example would help:
I cannot
Charles Bailey char...@hashpling.org writes:
I'm sorry to come in with such a fundamental question at such a late
revision of this patch series, but am I the only person to wonder about
the choice of option name?
To me, cat-file already output objects literally (without -p) as
opposed to
On Wed, Apr 15, 2015 at 10:29:34PM +0530, Karthik Nayak wrote:
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
karthik nayak karthik@gmail.com writes:
On 04/16/2015 02:22 AM, Junio C Hamano wrote:
This is a tangent, but while we are in the vicinity, we may want to
rethink the help message we attach to the '-e' option. Technically
the current message is _not_ wrong per-se, but it misses the
On Thu, Apr 16, 2015 at 7:10 PM, Karthik Nayak karthik@gmail.com wrote:
On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano gits...@pobox.com
wrote:
I meant just a different message. The point of -e is to see if the
thing exists. It is good to mention _how_ the result is reported
On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano gits...@pobox.com
wrote:
karthik nayak karthik@gmail.com writes:
On 04/16/2015 02:22 AM, Junio C Hamano wrote:
This is a tangent, but while we are in the vicinity, we may want to
rethink the help message we attach to the '-e'
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of a broken/corrupt object without throwing
an error.
Junio C Hamano gits...@pobox.com writes:
Karthik Nayak karthik@gmail.com writes:
...
-if (argc != 3 argc != 2)
+if (argc 2 || argc 4)
usage_with_options(cat_file_usage, options);
Hmm, why this change?
By allowing 4 args blindly like this, you will let
Karthik Nayak karthik@gmail.com writes:
case 's':
- type = sha1_object_info(sha1, size);
- if (type 0) {
- printf(%lu\n, size);
- return 0;
- }
- break;
+ oi.sizep = size;
+
20 matches
Mail list logo
