* [RFC] git cat-file "literally" option
@ 2015-02-18 9:39 karthik nayak
2015-02-18 12:50 ` karthik nayak
0 siblings, 1 reply; 5+ messages in thread
From: karthik nayak @ 2015-02-18 9:39 UTC (permalink / raw)
To: Git List, Junio C Hamano
Hey,
After reading http://thread.gmane.org/gmane.comp.version-control.git/256878
I have started working on the git cat file --literally option.
I'm wondering if I should implement it as an add on to the existing options,
wherein we could say "git cat-file (t | -s | -e | -p | <type> |
--texconv) --literally <object>"
so that it would be able to print the required data literally or should
I implement it such that
we could say "git cat-file (-t | -s | -e | -p | <type> | --texconv |
--literally) <object>"
so it would just give all information about the given object. (Maybe
like the -p option?)
For example :
if I create a bogus object like
git hash-object -t bogus --literally -w --stdin </dev/null
Should I implement
git cat-file -t --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
or should I implement
git cat-file --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
To get information pertaining to the object "bogus:.
What do you people think?
Thanks
-Karthik
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] git cat-file "literally" option
2015-02-18 9:39 [RFC] git cat-file "literally" option karthik nayak
@ 2015-02-18 12:50 ` karthik nayak
2015-02-18 13:58 ` Duy Nguyen
0 siblings, 1 reply; 5+ messages in thread
From: karthik nayak @ 2015-02-18 12:50 UTC (permalink / raw)
To: Git List, Junio C Hamano
On 02/18/2015 03:09 PM, karthik nayak wrote:
> Hey,
> After reading
> http://thread.gmane.org/gmane.comp.version-control.git/256878
> I have started working on the git cat file --literally option.
>
> I'm wondering if I should implement it as an add on to the existing
> options,
> wherein we could say "git cat-file (t | -s | -e | -p | <type> |
> --texconv) --literally <object>"
> so that it would be able to print the required data literally or
> should I implement it such that
> we could say "git cat-file (-t | -s | -e | -p | <type> | --texconv |
> --literally) <object>"
> so it would just give all information about the given object. (Maybe
> like the -p option?)
>
> For example :
> if I create a bogus object like
>
> git hash-object -t bogus --literally -w --stdin </dev/null
>
> Should I implement
> git cat-file -t --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
> or should I implement
> git cat-file --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
> To get information pertaining to the object "bogus:.
>
>
> What do you people think?
> Thanks
> -Karthik
Also,
Is there any way I can get the type of object made via git hash-object
--literally. The problem I'm facing is "sha1_object_info()" returns a
object_type enum, so objects not specified there are considered as errors.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] git cat-file "literally" option
2015-02-18 12:50 ` karthik nayak
@ 2015-02-18 13:58 ` Duy Nguyen
2015-02-18 15:47 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Duy Nguyen @ 2015-02-18 13:58 UTC (permalink / raw)
To: karthik nayak; +Cc: Git List, Junio C Hamano
On Wed, Feb 18, 2015 at 7:50 PM, karthik nayak <karthik.188@gmail.com> wrote:
> Also,
> Is there any way I can get the type of object made via git hash-object
> --literally. The problem I'm facing is "sha1_object_info()" returns a
> object_type enum, so objects not specified there are considered as errors.
Use what sha1_object_info() uses behind the scene. Loose object
encodes object type as a string, you could just print that string and
skip the enum object_type conversion. You probably need special
treatment for packed objects too. See parse_sha1_header() and
unpack_object_header().
--
Duy
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] git cat-file "literally" option
2015-02-18 13:58 ` Duy Nguyen
@ 2015-02-18 15:47 ` Junio C Hamano
2015-02-19 10:10 ` karthik nayak
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2015-02-18 15:47 UTC (permalink / raw)
To: Duy Nguyen; +Cc: karthik nayak, Git List
On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> ... skip the enum object_type conversion. You probably need special
> treatment for packed objects too.
I do not think you can store object of type "bogus" in a pack data stream
to begin with, so I wouldn't worry about packed objects.
"cat-file --literally" that does not take "-t" would not be useful, as the
output "cat-file <type> <object>" does not tell what <type> the thing
is. Other things like sizes and existence can be inferred once you have
an interface to do "cat-file <type> <object>", so in that sense -e and -s
are not essential (this also applies to "cat-file" without --literally).
By definition, "--literally -p" would not be able to do anything fancier than
just dump the bytes (i.e. what "cat-file <type> <object>" does), as the
bogus type is not something the code would know the best external
representation for.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] git cat-file "literally" option
2015-02-18 15:47 ` Junio C Hamano
@ 2015-02-19 10:10 ` karthik nayak
0 siblings, 0 replies; 5+ messages in thread
From: karthik nayak @ 2015-02-19 10:10 UTC (permalink / raw)
To: Junio C Hamano, Duy Nguyen; +Cc: Git List
On 02/18/2015 07:28 PM, Duy Nguyen wrote:> On Wed, Feb 18, 2015 at 7:50
> Use what sha1_object_info() uses behind the scene. Loose object
> encodes object type as a string, you could just print that string and
> skip the enum object_type conversion. You probably need special
> treatment for packed objects too. See parse_sha1_header() and
> unpack_object_header().
Thank you will look into that!
On 02/18/2015 09:17 PM, Junio C Hamano wrote:
> On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> ... skip the enum object_type conversion. You probably need special
>> treatment for packed objects too.
>
> I do not think you can store object of type "bogus" in a pack data stream
> to begin with, so I wouldn't worry about packed objects.
>
> "cat-file --literally" that does not take "-t" would not be useful, as the
> output "cat-file <type> <object>" does not tell what <type> the thing
> is. Other things like sizes and existence can be inferred once you have
> an interface to do "cat-file <type> <object>", so in that sense -e and -s
> are not essential (this also applies to "cat-file" without --literally).
>
> By definition, "--literally -p" would not be able to do anything fancier than
> just dump the bytes (i.e. what "cat-file <type> <object>" does), as the
> bogus type is not something the code would know the best external
> representation for.
>
Thanks for clearing that out. Will work on this for now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-02-19 10:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-18 9:39 [RFC] git cat-file "literally" option karthik nayak
2015-02-18 12:50 ` karthik nayak
2015-02-18 13:58 ` Duy Nguyen
2015-02-18 15:47 ` Junio C Hamano
2015-02-19 10:10 ` karthik nayak
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.