Revision a5bf71be4ada0d8e914c23c2fc334ce1899e36c1 authored by Stefan Beller on 22 May 2015, 19:17:52 UTC, committed by Stefan Beller on 22 May 2015, 19:17:52 UTC
It's better to start the man page with a description of what submodules actually are instead of saying what they are not. Reorder the paragraphs such that the first short paragraph introduces the submodule concept, the second paragraph highlights the usage of the submodule command, the third paragraph giving background information, and finally the fourth paragraph discusing alternatives such as subtrees and remotes, which we don't want to be confused with. This ordering deepens the knowledge on submodules with each paragraph. First the basic questions like "How/what" will be answered, while the underlying concepts will be taught at a later time. Making sure it is not confused with subtrees and remotes is not really enhancing knowledge of submodules itself, but rather painting the big picture of git concepts, so you could also argue to have it as the second paragraph. Personally I think this may confuse readers, specially newcomers though. Additionally to reordering the paragraphs, they have been slightly reworded. Signed-off-by: Stefan Beller <sbeller@google.com>
1 parent 6c1249c
blob.h
#ifndef BLOB_H
#define BLOB_H
#include "object.h"
extern const char *blob_type;
struct blob {
struct object object;
};
struct blob *lookup_blob(const unsigned char *sha1);
int parse_blob_buffer(struct blob *item, void *buffer, unsigned long size);
/**
* Blobs do not contain references to other objects and do not have
* structured data that needs parsing. However, code may use the
* "parsed" bit in the struct object for a blob to determine whether
* its content has been found to actually be available, so
* parse_blob_buffer() is used (by object.c) to flag that the object
* has been read successfully from the database.
**/
#endif /* BLOB_H */
Computing file changes ...
