2018-03-14 21:31:41 +03:00
|
|
|
#ifndef UPLOAD_PACK_H
|
|
|
|
|
#define UPLOAD_PACK_H
|
|
|
|
|
|
|
|
|
|
struct upload_pack_options {
|
|
|
|
|
int stateless_rpc;
|
|
|
|
|
int advertise_refs;
|
|
|
|
|
unsigned int timeout;
|
|
|
|
|
int daemon_mode;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void upload_pack(struct upload_pack_options *options);
|
|
|
|
|
|
2018-03-15 20:31:27 +03:00
|
|
|
struct repository;
|
argv-array: rename to strvec
The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.
I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).
A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.
This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:
- files retain their original names for now
- struct field names are retained for now
- there's a preprocessor compat layer that lets most users remain the
same for now. The exception is headers which made a manual forward
declaration of the struct. I've converted them (and their dependent
function declarations) here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 23:23:25 +03:00
|
|
|
struct strvec;
|
2018-03-15 20:31:27 +03:00
|
|
|
struct packet_reader;
|
argv-array: rename to strvec
The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.
I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).
A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.
This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:
- files retain their original names for now
- struct field names are retained for now
- there's a preprocessor compat layer that lets most users remain the
same for now. The exception is headers which made a manual forward
declaration of the struct. I've converted them (and their dependent
function declarations) here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 23:23:25 +03:00
|
|
|
int upload_pack_v2(struct repository *r, struct strvec *keys,
|
2019-04-29 11:28:23 +03:00
|
|
|
struct packet_reader *request);
|
2018-03-15 20:31:27 +03:00
|
|
|
|
2018-03-15 20:31:28 +03:00
|
|
|
struct strbuf;
|
2019-04-29 11:28:14 +03:00
|
|
|
int upload_pack_advertise(struct repository *r,
|
2019-04-29 11:28:23 +03:00
|
|
|
struct strbuf *value);
|
2018-03-15 20:31:28 +03:00
|
|
|
|
2018-03-14 21:31:41 +03:00
|
|
|
#endif /* UPLOAD_PACK_H */
|
