* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Junio C Hamano @ 2012-02-19 9:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Niedier, Shawn O. Pearce, Scott Chacon
In-Reply-To: <7vlinzp67m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Still draft for discussion.
Small clarifications and corrections.
> ... from a larger
> workflow point of view it would not be so useful, as it would involve
> steps like this:
>
> ...
> * Then you give the general public the resulting commit.
The point of the above is *not* that it involves hash-object or having to
preserve both author and committer dates when secondary signers sign the
commit---these are something the tool *could* learn to assist. The point
is that adding more signatures *must* change the resulting commit object
name, making it necessary not to expose it to the general public in order
to avoid history rewinding, which *is* what makes it "not so useful".
And that is why I didn't add such a tool support to help producing the end
result that wouldn't be so useful anyway.
>> +TREE OBJECTS
>> +------------
>> +Tree object payload contains a list of entries, each with a mode,
>> +object type, object name, and filename, sorted by filename. It
>> +represents the contents of a single directory tree.
>
> Drop "object type," from this list. It is inferred from the mode. I
> personally would prefer to say "path" or "pathname" when the entity
> referred to may not be a regular file.
The principle is not to say "filename" to give an incorrect impression
that we are only talking about a regular file. This principle applies to
pathnames in general (i.e. covers what is recorded in the index, too), but
because we are talking about an entry in a tree, "pathname component" is
even better than "path" or "pathname", because it has a specific meaning:
one part of pathname delimited by a slash.
POSIX does use "filename" for this purpose (and mentions "pathname
component" as a synonym), but if we use the word, without clarifying that
this document uses it in the strict POSIX sense, the reader can easily
misunderstand that we mean a more general "name of a regular file".
>> +The object type may be a blob, representing the contents of a file,
>> +another tree, representing the contents of a subdirectory, or a commit
>> +(representing a subproject).
>
> and drop the above line.
Should be obvious from the context, but I meant "drop the above three
lines".
> I personally do not think it is necessary to have the above paragraph at
> all in this object.
s/in this object/in this document/;
>> +Encoding
>> +~~~~~~~~
>
> "Encoding" is such a loaded word and does not help clarify what this
> section is really about, which is "format of a tree entry", or simply
> "Entries".
>
>> +Entries are of variable length and self-delimiting. Each entry
>> +consists of
Actually, title this section as "Tree Entries", and begin the paragraph
with
Tre entries are of ...delimiting. Each entry consists of...
>> +Ident strings
>> +~~~~~~~~~~~~~
>> +Ident strings record who's responsible of doing something at what
>> +time. For a commit, the ident string in "author" line records who is
>> +the author of the associated changes and when the changes are
>
> s/are/were/, perhaps? Again, what the purpose of this document? If this
> were more than to strictly describe the "structure", it is OK and even
s/ more than to/to/;
> preferable to leave the meaning the "author" as vague, but if this were
> also to suggest the best current practice interpretation, it may be worth
> to add something like
>
> There may be a case where it is difficult to attribute a commit to
> a single author; think of it as recording the primary contact, the
> person to ask any questions about the commit if needed later.
^ permalink raw reply
* Re: [PATCH] cherry-pick -x: always insert an empty line
From: Junio C Hamano @ 2012-02-19 8:44 UTC (permalink / raw)
To: Beat Bolli; +Cc: git, Eric Raible
In-Reply-To: <1329599690-9152-1-git-send-email-bbolli@ewanet.ch>
Beat Bolli <bbolli@ewanet.ch> writes:
> When cherry-picking a commit that has only a summary, the -x option
> creates an invalid commit message because it puts the hash of the commit
> being picked on the second line which should be left empty.
>
> This patch fixes this buglet by always inserting an empty line before
> the added line.
>
> Aside from that, even with a non-trivial commit the generated note
> "(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
> seems abrupt when appended directly.
>
> Cc: Eric Raible <raible@nextest.com>
> Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
> ---
> sequencer.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 5fcbcb8..63fd589 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -382,7 +382,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> }
>
> if (opts->record_origin) {
> - strbuf_addstr(&msgbuf, "(cherry picked from commit ");
> + strbuf_addstr(&msgbuf, "\n(cherry picked from commit ");
Doesn't this need to be conditional?
If we cherry pick your commit somewhere else with "-x -s", the resulting
commit log message would end like this:
Aside from that, even with a non-trivial commit the generated note
"(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
seems abrupt when appended directly.
Cc: Eric Raible <raible@nextest.com>
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)
Signed-off-by: Frotz Xyzzy <nitfol@example.xz>
which clearly is worse-looking with the extra LF you added in this patch.
> strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
> strbuf_addstr(&msgbuf, ")\n");
> }
^ permalink raw reply
* Re: [PATCH/RFC v2] Document format of basic Git objects
From: Junio C Hamano @ 2012-02-19 8:39 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Niedier, Shawn O. Pearce, Scott Chacon
In-Reply-To: <1329624946-32173-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Still draft for discussion. Of three people who participated on this
> thread, two favor a man page (me and Jonathan), one technical/
> (Junio), so let's put it as a man page for now.
Personally I do not have strong preference either way.
The original motivation of technical/ was that we wanted to have a place
to keep documentation that would help ourselves, the people who write the
internals of git, even though we did not yet know and did not want to have
to decide if it is a good idea to expose the end users, who may not care
about the gory details of the internal, with reams of such documents.
> - Not sure if we fix the order of gpgsig and mergetag, or they can be
> mixed together. Also not sure if we can have multiple gpgsig.
You can merge a signed tag and then sign the resulting commit yourself,
and the order of the mixing would not matter. Technically a gpgsig is a
signature over the commit object payload without gpgsig lines, so you
could have two or more gpgsigs on the same commit object but from a larger
workflow point of view it would not be so useful, as it would involve
steps like this:
* You prepare a commit object, you may perhaps sign it yourself;
* You expose this commit object to chosen others from whom you want their
signature on it;
* They sign it with "commit -S --amend", but when they do so they make
sure the resulting commit has the same committer/author header as the
original. Note that the resulting commits will all have different
object name, as the object name is over all payload including their
gpgsigs.
* You grab the gpgsig lines from these commits, paste them into the
header part of the original, and then re-hash the result with
"hash-object -w -t commit". The result will have all valid gpgsigs
over the payload in the commit without its gpgsig lines, because the
gpgsig lines from all the signers were generated that way.
* Then you give the general public the resulting commit.
> - I skipped the experimental loose object format (it's what it's
> called in sha1_file.c). I think we can call it deprecated and move
> on.
Good.
> - Do we assume tag/commit header in utf-8 or ascii?
Author-ident is typically utf-8 already, so you cannot assume "ASCII".
> +Object SHA-1
> +~~~~~~~~~~~~
> +An object SHA-1 is calculated on its header and payload. The content
> +to be consumed by SHA-1 calculation is:
> +
> +- Object type in ascii, either "commit", "tree", "tag" or "blob"
> + (without quotes)
> +- One space (ASCII SP)
> +- The payload length in ascii canonical decimal format
"canonical" may make it sound as if the document is more formal, but then
you would have to define what is canonical and what is not somewhere else,
so I would suggest dropping it.
The length of the payload in bytes, represented as a decimal integer.
Also if you spell ASCII, consistently spell it in all-caps.
> +- ASCII NUL
> +- Object payload
----------------------------------------------------------------
> +BLOB OBJECTS
> +------------
> +Blob object payload is file data.
What's the significance of saying "file data" here? In a document that
describes the structure, saying "is uninterpreted sequence of bytes" is
more accurate (the important point is that git does not care what it is)
and covers cases where blob was recorded with "hash-object -w --stdin"
where no such "file data" has ever existed in a 'file". Also a blob may
record contents of a symbolic link ;-).
> +TREE OBJECTS
> +------------
> +Tree object payload contains a list of entries, each with a mode,
> +object type, object name, and filename, sorted by filename. It
> +represents the contents of a single directory tree.
Drop "object type," from this list. It is inferred from the mode. I
personally would prefer to say "path" or "pathname" when the entity
referred to may not be a regular file. I am not sure the last sentence is
necessary, but if you must say something, say "It represents a
directory". It is by definition redundant to say that a tree represents a
"tree". Replace the above with something line this:
... entries, each with a mode, object name and path. The type of
the object is encoded in the "mode":
- 100644 or 100755: the object is a "blob" that records the
contents of a regular non-executable or executable file,
respectively, that exists at the path.
- 120000: the object is a "blob" that records the contents of a
symbolic link that exists at the path.
- 40000: the object is a "tree" that represents a subdirectory
that exists at the path.
- 160000: the object is a "commit" that records the state of a
submodule that exists at the path.
> +The object type may be a blob, representing the contents of a file,
> +another tree, representing the contents of a subdirectory, or a commit
> +(representing a subproject).
and drop the above line.
> +Since trees and blobs, like all other
> +objects, are named by a hash of their contents, two trees have the
> +same object name if and only if their contents (including,
> +recursively, the contents of all subdirectories) are identical. This
> +allows git to quickly determine the differences between two related
> +tree objects, since it can ignore any entries with identical object
> +names.
It does not make sense to say 'trees and blobs' when you explain that a
single top-level tree object defines the entire tree's state. Just say
'trees'. I know you would say "I wanted to say if tree A and tree B are
the same except for the content of a single blob recorded at path P, the
result of hash for A and B would be different", but the same can be said
for a submodule, so singling out 'blob' is incomplete. Also these trees
may record the same set of blobs but tree B may record what tree A had at
path P at path Q, so it is not like the only thing that matter in the tree
is the object names.
I personally do not think it is necessary to have the above paragraph at
all in this object.
> +Note that the files all have mode 644 or 755: git actually only pays
> +attention to the executable bit.
Saying 644 or 755 here is misleading as it does not match any reality
(except for very early incarnation of git). By rewriting the first
paragraph, these two lines can be safely eliminated.
> +Encoding
> +~~~~~~~~
"Encoding" is such a loaded word and does not help clarify what this
section is really about, which is "format of a tree entry", or simply
"Entries".
> +Entries are of variable length and self-delimiting. Each entry
> +consists of
> +
> +- a POSIX file mode in octal ascii representation, no 0 padding to the
> + left
This is not "a POSIX file mode" at all. The mode in a tree entry was
modelled after that, but there is no need to mention it, especially
because POSIX does not define the exact bit assignment for types (the
permission are defined from S_IXOTH to S_IRWXU and S_ISUID/S_ISGID with
exact bit locations) and because of S_IFGITLINK which is clearly not
POSIX. As we have enumerated them in the first paragraph,
The "mode" (see above).
is sufficient here.
> +- exactly one space (ASCII SP)
> +- filename for the entry, as a NUL-terminated string
Again, "pathname" or just "path" for this entire document.
> +- 20-byte binary object name
> +
> +The mode should be 100755 (executable file), 100644 (regular file),
> +120000 (symlink), 40000 (subdirectory), or 160000 (subproject), with
> +no leading zeroes. Modes with one leading zero and the synonym 100664
> +for 100644 are also accepted for historical reasons. Other modes are
> +not accepted.
This is made redundant by the first paragraph above.
> +The filename may be an arbitrary nonempty string of bytes, as long as
> +it contains no '/' or NUL character.
s/, as long as it contains no/; it cannot contain any/
> +The associated object must be a valid blob if the mode indicates a
> +file or symlink, tree if it indicates a subdirectory, or commit if it
> +indicates a subproject. The blob associated to a symlink entry
> +indicates the link target and its content not have any embedded NULs.
I doubt that we should even mention "and its content not have ...". It is
for readlink(2) and symlink(2) to decide.
> +Sorting
> +~~~~~~~
> +Entries are sorted by memcmp(3) on file name. No duplicate file names
> +allowed.
A sentence without a verb seen at the end of this paragraph.
> +COMMIT OBJECT
> +-------------
> +The commit object links a physical state of a tree with a description
> +of how we got there and why.
What is the intended audience and the purpose of this document? If this
were to strictly define and describe the "structure", then "and why" is
inappropriate. It is merely the best-current-practice at the human level
to describe the "why" in their commit log messages---it does not break the
structure if nobody explains "why".
On the other hand, "how we got there" is a good phrase to explain that by
refering to its immediate parents, all the previous histories are also
described.
> +... Commit object payload contains the
> +associated tree SHA-1, parent commits's SHA-1, author and comitter
> +information.
s/.$/, among other things./; as the log message is also part of the
payload.
Start by labeling what the large block of example you are going to throw
at the reader here.
> +------------------------------------------------
> +$ git cat-file commit 81d48f0aee54
> +tree 093f37084c133795e4ce71befa57185328737171
> +parent f5e4e20faa1eee3feaa0394897bbd1aca544e809
> +parent 661db794eb8179c7bea02f159bb691a2fff4a8e0
> +parent 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
> +author Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
> +committer Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
> +mergetag object 661db794eb8179c7bea02f159bb691a2fff4a8e0
> + type commit
> + tag devicetree-for-linus
> + tagger Grant Likely <grant.likely@secretlab.ca> 1326520038 -0700
> +
> + 2nd set of device tree changes for v3.3
> + -----BEGIN PGP SIGNATURE-----
> + Version: GnuPG v1.4.11 (GNU/Linux)
> +
> + iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
> + TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
Elide the above like so:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
...
=mup8
-----END PGP SIGNATURE-----
> +Merge tags 'devicetree-for-linus' and 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
> +
> +2nd set of device tree changes and SPI bug fixes for v3.3
> +
> +* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
> + of/irq: Add interrupts-names property to name an irq resource
> + of/address: Add reg-names property to name an iomem resource
> +
> +* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
> + spi/tegra: depend instead of select TEGRA_SYSTEM_DMA
> +------------------------------------------------
> +
> +More precisely, a commit object begins with of one or more lines
> +delimited by ASCII LF. The end of the header is signalled by an empty
> +line. Any remaining text after the empty line forms the commit
Drop "More precisely, ". Also notice that you abruptly said "end of the
header" without mentioning anything about "header" in the previous
sentence.
A commit object begins with the "header" part, that consists of
one or more lines delimited by LF, and the "body" part, that
records the commit log message. The first empty line delimits the
header and the body.
> +The header must not contain NUL.
I vaguely recall that you made sure neither the header nor the body
contains NUL.
> +A "continuation line" in the header begins with an SP. The remainder
> +of the line, after removing that SP, is concatenated to the previous
> +line, while retaining the LF at the end of the previous line.
> +
> +When a line in the header begins with a letter other than SP, and has
> +at least one SP in it, it is called a "field". A field consists of the
> +"field name", which is the string before the first SP on the line, and
> +its "value", which is everything after that SP. When the value
> +consists of multiple lines, continuation lines are used.
> +
> +More than one field with the same name can appear in the header of an
> +object, and the order in which they appear is significant. A commit
> +object can contain these fields in the listed order:
s/can contain/contains/; as you are marking optional ones with "zero or".
> +1. one "tree" field with the 40-character textual object name of the
> + associated tree object
> +2. zero or more "parent" fields, each with 40-character textual object
> + name of the parent commit object
> +3. one "author" field with an ident string
> +4. one "committer" field with an ident string
> +5. zero or one "encoding" field with an ascii string
s/zero or one/optionally, one/ (not a strong preference--I just felt that
would be easier to read).
After the above fields, other fields may follow, and new types of
fields may be added in later versions of git. Example of these
optional fields are:
- "mergetag" that copies the contents of a signed tag on one of
the parent commit;
- "gpgsig" that records a GPG signature for this commit object.
> +6. zero or more "mergetag" fields with associated tag object content
> +7. zero or one "gpgsig" field with gpg signature content
and exclude these two from the numbering above to make it clear they are
optional.
> +Ident strings
> +~~~~~~~~~~~~~
> +Ident strings record who's responsible of doing something at what
> +time. For a commit, the ident string in "author" line records who is
> +the author of the associated changes and when the changes are
s/are/were/, perhaps? Again, what the purpose of this document? If this
were more than to strictly describe the "structure", it is OK and even
preferable to leave the meaning the "author" as vague, but if this were
also to suggest the best current practice interpretation, it may be worth
to add something like
There may be a case where it is difficult to attribute a commit to
a single author; think of it as recording the primary contact, the
person to ask any questions about the commit if needed later.
> +made. The ident string in "committer" line records who commits the
s/commits/committed/, perhaps?
> +changes to the repository and at what time.
> +
> +An ident string consists of an email address and a timestamp. More
> +precisely:
s/of an email/of a name, an email/;
s/. More precisely:/:/;
> +1. Optionally, a name
> +2. An email address wrapped around by `<` and `>`, followed by one
> + space (ASCII SP)
The above makes it sound as if "A U Thor<author@example.xz>" is usual and
valid. How about
1. A name, followed by one ASCII SP
and after this enumeration, say something like:
Name may be missing in commit objects produced by repository
conversion from other SCMs that do not have it. Name and email
are typically encoded in UTF-8.
even though I am not sure the last sentence should be in this document.
> +3. The number of seconds since Epoch (00:00:00 UTC, January 1, 1970)
> + followed by a space (ASCII SP)
> +4. Timezone: either plus or minus sign, followed by 4 decimal digits
> +
> +Name and email are encoded in UTF-8 and must must not contain ASCII
> +NUL characters.
Drop " and must must ...characters"; you already said that the header does
not have any NUL. As I already said, I am not sure if you should mention
"UTF-8" at all in this document.
> +Commit encoding
> +~~~~~~~~~~~~~~~
> +Encoding field describes that encoding that the commit message is
> +encoded in.
s/that encoding that/the character encoding in which/;
s/encoded in/recorded/;
> +... Encoding names must be recognized by iconv(3). By default,
> +commit message is in UTF-8. It's discouraged to use encodings that can
> +generate ASCII NUL characters.
Here we would probably want to have a paragraph each for "mergetag" and
"gpgsig".
> +TAG OBJECTS
> +-----------
> +Tag object payload contains an object, object type, tag name, the name
> +of the person ("tagger") who created the tag, and a message, which may
> +contain a signature.
s/a signature/a signature at the end/;
> +------------------------------------------------
> +$ git cat-file tag v1.5.0
> +object 437b1b20df4b356c9342dac8d38849f24ef44f27
> +type commit
> +tag v1.5.0
> +tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
> +
> +GIT 1.5.0
> +-----BEGIN PGP SIGNATURE-----
> +Version: GnuPG v1.4.6 (GNU/Linux)
> +
> +iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
> +nLE/L9aUXdWeTFPron96DLA=
> +=2E+0
> +-----END PGP SIGNATURE-----
> +------------------------------------------------
> +
> +Tag object format resembles commit format. A tag commit may have the
> +following fields in listed order:
> +
> +1. one "object" field with 40-character textual object name of the
> + tagged object
> +2. one "type" field with type of the tagged object ("commit", "tag",
> + "blob", or "tree")
> +3. one "tag" field with the name of the tag
> +4. one "tagger" with an ident string
> +
> +New kinds of fields may be added in later versions of git.
> +
> +Any remaining text after the header forms the tag message. Tag message
> +has no specified encoding. Anything that does not contain ASCII NUL
> +characters are accepted.
> +
> +The object field must point to a valid object of type indicated by the
> +type field. The tag name can be an arbitrary string without NUL bytes
> +or embedded newlines; in practice it usually follows the restrictions
> +described in linkgit:git-check-ref-format[1].
A description of how the signature part is formed needs to come here.
> +GIT
> +---
> +Part of the linkgit:git[1] suite
^ permalink raw reply
* git-svn support for svn:externals
From: Nikolaus Demmel @ 2012-02-19 5:58 UTC (permalink / raw)
To: git
Hi,
has there been any recent interest / activity in getting support for svn:externals? Digging in the archives [1,2,3] I found a couple of initiatives, but none seem to have ever been completed. Also, there are a couple of independent scripts floating around the web, that implement some special cases, but most don't work very well, e.g. because they only serve the pre-1.5 syntax for svn:externals.
Support for svn:externals would make my live so much simpler :-).
Cheers,
Nikolaus
[1] http://git.661346.n2.nabble.com/Re-git-svn-and-svn-externals-was-Re-Hackontest-ideas-tc667598.html
[2] http://git.661346.n2.nabble.com/PATCH-0-3-git-svn-externals-PoC-in-a-sh-script-tc791045.html#none
[3] http://git.661346.n2.nabble.com/git-svn-importing-internal-externals-tc2982345.html#none
^ permalink raw reply
* Re: git-svn: simple user-level versions question, plus help request
From: Nikolaus Demmel @ 2012-02-19 4:25 UTC (permalink / raw)
To: git
In-Reply-To: <CAJaBf=oFpNZ3gf=Oqj9415_WpMyAM=EYnW6R9cZCPteqSxnogQ@mail.gmail.com>
Richard Holmes wrote
>
> After looking at the respective versions, it appears that git svn
> shows svn version 1.6.16 and my svn (standalone) client shows svn
> version 1.6.17 (and its associated RA modules):
>
I'm not quite sure how everything fits together, but AFAIK git-svn uses the
perl subversion module, meaning that you might possibly need to update
those.
Best regards,
Nikolaus
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-simple-user-level-versions-question-plus-help-request-tp7292358p7298053.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH/RFC v2] Document format of basic Git objects
From: Nguyễn Thái Ngọc Duy @ 2012-02-19 4:15 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jonathan Niedier, Shawn O. Pearce, Scott Chacon,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1329312140-24089-1-git-send-email-pclouds@gmail.com>
Still draft for discussion. Of three people who participated on this
thread, two favor a man page (me and Jonathan), one techincal/
(Junio), so let's put it as a man page for now.
Some notes:
- I'm tempted to include pack-format.txt because I also document
loose object format here. If it's included and
gitrepository-layout.txt links to this, we have a quite complete
documentation of what's inside $GIT_DIR (assuming rebase-apply and
such are of private use)
- Not sure if we fix the order of gpgsig and mergetag, or they can be
mixed together. Also not sure if we can have multiple gpgsig, I
haven't checked the code.
- I skipped the experimental loose object format (it's what it's
called in sha1_file.c). I think we can call it deprecated and move
on.
- Do we assume tag/commit header in utf-8 or ascii?
- We don't do any encoding on ident strings, right?
Mostly-written-by: Jonathan Nieder <jrnieder@gmail.com>
Mostly-written-by: Junio C Hamano <gitster@pobox.com>
Remaining-stolen-from: Documentation/user-manual.txt
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-object.txt | 273 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 273 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-object.txt
diff --git a/Documentation/git-object.txt b/Documentation/git-object.txt
new file mode 100644
index 0000000..359af37
--- /dev/null
+++ b/Documentation/git-object.txt
@@ -0,0 +1,273 @@
+git-object(5)
+=============
+
+NAME
+----
+git-object - Git object format
+
+SYNOPSIS
+--------
+$GIT_DIR/objects/*
+
+OBJECT ON-DISK REPRESENTATIONS
+------------------------------
+Objects can be stored on disk as loose (unpacked) objects or
+in packs. Loose objects are in $GIT_DIR/objects/[0-9a-f][0-9a-f]
+directories. Packs are $GIT_DIR/objects/pack/pack-*.pack. Each pack
+has a corresponding index file to speed up pack access.
+
+Object SHA-1
+~~~~~~~~~~~~
+An object SHA-1 is calculated on its header and payload. The content
+to be consumed by SHA-1 calculation is:
+
+- Object type in ascii, either "commit", "tree", "tag" or "blob"
+ (without quotes)
+- One space (ASCII SP)
+- The payload length in ascii canonical decimal format
+- ASCII NUL
+- Object payload
+
+Loose objects
+~~~~~~~~~~~~~
+Loose objects are simply a compressed form using zlib(3) of the
+object's header and payload, as described in Object SHA-1 section
+above.
+
+Packed objects
+~~~~~~~~~~~~~~
+FIXME maybe include Documentation/pack-format.txt
+
+BLOB OBJECTS
+------------
+Blob object payload is file data.
+
+TREE OBJECTS
+------------
+Tree object payload contains a list of entries, each with a mode,
+object type, object name, and filename, sorted by filename. It
+represents the contents of a single directory tree.
+
+The object type may be a blob, representing the contents of a file,
+another tree, representing the contents of a subdirectory, or a commit
+(representing a subproject). Since trees and blobs, like all other
+objects, are named by a hash of their contents, two trees have the
+same object name if and only if their contents (including,
+recursively, the contents of all subdirectories) are identical. This
+allows git to quickly determine the differences between two related
+tree objects, since it can ignore any entries with identical object
+names.
+
+Note that the files all have mode 644 or 755: git actually only pays
+attention to the executable bit.
+
+Encoding
+~~~~~~~~
+Entries are of variable length and self-delimiting. Each entry
+consists of
+
+- a POSIX file mode in octal ascii representation, no 0 padding to the
+ left
+- exactly one space (ASCII SP)
+- filename for the entry, as a NUL-terminated string
+- 20-byte binary object name
+
+The mode should be 100755 (executable file), 100644 (regular file),
+120000 (symlink), 40000 (subdirectory), or 160000 (subproject), with
+no leading zeroes. Modes with one leading zero and the synonym 100664
+for 100644 are also accepted for historical reasons. Other modes are
+not accepted.
+
+The filename may be an arbitrary nonempty string of bytes, as long as
+it contains no '/' or NUL character.
+
+The associated object must be a valid blob if the mode indicates a
+file or symlink, tree if it indicates a subdirectory, or commit if it
+indicates a subproject. The blob associated to a symlink entry
+indicates the link target and its content not have any embedded NULs.
+
+Sorting
+~~~~~~~
+Entries are sorted by memcmp(3) on file name. No duplicate file names
+allowed.
+
+COMMIT OBJECT
+-------------
+The commit object links a physical state of a tree with a description
+of how we got there and why. Commit object payload contains the
+associated tree SHA-1, parent commits's SHA-1, author and comitter
+information.
+
+------------------------------------------------
+$ git cat-file commit 81d48f0aee54
+tree 093f37084c133795e4ce71befa57185328737171
+parent f5e4e20faa1eee3feaa0394897bbd1aca544e809
+parent 661db794eb8179c7bea02f159bb691a2fff4a8e0
+parent 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
+author Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
+committer Linus Torvalds <torvalds@linux-foundation.org> 1326576355 -0800
+mergetag object 661db794eb8179c7bea02f159bb691a2fff4a8e0
+ type commit
+ tag devicetree-for-linus
+ tagger Grant Likely <grant.likely@secretlab.ca> 1326520038 -0700
+
+ 2nd set of device tree changes for v3.3
+ -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1.4.11 (GNU/Linux)
+
+ iQIcBAABAgAGBQJPERbzAAoJEEFnBt12D9kBmDIP/R9Vspc6yhjSAEvdp/VET2gi
+ TgAQfdp4VuYjjIt4cUPO5UQU9kw478GjTuP2blZEC9DlG1jSf/L8U+A7FHJIVVzU
+ QfjwV1Lqaqk+sQQ1bsp2ixbesKECmqU9IweOIFmn0U2ZD+xlPFIpE2iTKEqymejf
+ PVZsFlkVmhQZgudPNieyZMjQpQ9hEb6UcSfXT//nmoRRxCL/PiMHGRx3UdS3eRe7
+ FApSW0Mty/PD07QXPsDjg1GvK59Gf6R1/4Bd31+rXEz9yaxf4I4I02fL553NDVIt
+ tAPfo/4YKW1rLMWQRkAUqCaMk9v/DWxeWYbbiJNZ2R3kys9o8k26XXxvcuYnecS2
+ G8DDJpmOikbN3Gvlskh40Tn3TJb5Wlgc7o/10L/fq6FovS4Uk7yUeFMqXUYfl8TU
+ ziIlrlt9IGabXBN4JKJl3OabgkeO+Oz9DKhTQFJLY4/121LAtFVk3xd316mY+wpX
+ mI83VmWMlp3sK+OLr+UdMTCXZvSIpu3KlGKMpAssHKUKxIV20NHLFNbm94/ywXBn
+ Zb8arjcv7+WzwhSqQJj851cq4/sEYx5HB4wU5Nm5SXBwcO3ixiij6lHCoHU+NudR
+ eyPIFLfrzwnUu3yTRgUfAnkgOce+2I+vUsU4pXUR6FyK73wSmm0+4WXQfB+OBlwD
+ 2O1RjZedZCb6zzf17H2k
+ =mup8
+ -----END PGP SIGNATURE-----
+mergetag object 14c173eb63432ba5d0783b6c4b23a8fe0c76fb0f
+ type commit
+ tag spi-for-linus
+ tagger Grant Likely <grant.likely@secretlab.ca> 1326520366 -0700
+
+ SPI bug fixes for v3.3
+ -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1.4.11 (GNU/Linux)
+
+ iQIcBAABAgAGBQJPERgyAAoJEEFnBt12D9kBRMsP/RBv6kWIb/qD7yJhrdbzJ4Tv
+ 1f7coSytuHupZVpxJstELKPugRmp2R6YeFbKw8P4P/12233Q0FcdKTF6ZE2h3cBp
+ bfCtyyzlFeY/nMfJKkwh37x2fHxNHynCCJEjHhecLday7NKQoTmmafivTfVmolWK
+ /MGjDarTAzC1FaP1xpBnuiI8eCr5WIgb4WmtvOmxIntVT077xggdJLL/Co7fBCqn
+ iibz3U/VyC68kQTGw6ELhnW1d7doHp7H3DJ2gPsh6lzpbv8JAnOMPpD+3Me1DVHE
+ Ay0kxPHV4bqnDyB+uEGppUiNoaTd5InrMAw+udDad60TMwOZzIvMkgxo0PIVM9Mm
+ k6mCcE2+TSnJetueX3cfrS5bRTPxUX7KRDC/WSp67/QPmelbYeRDLR7hrrQVqOPq
+ 5hIKMfz/kTBXcaXk643TEveaZlMuOZxHBYAvsbu5BX/3SQqYFS4POdxdeZVnUf54
+ ITHhftBtrXacCsjKujp0xmKCIpF+8v3yKRxGEQssByv8v+CaymNrEls2vTF8tn5P
+ sAIjPFJYG+IHtDMIsTHOvSPA7uwWYsOVHFEYsbC1758esiBD8+qtfvFS3jAH99z+
+ v2/aGsfMnjYEIsRtSm7PVTybJAo22Gr62yE/Q+rP//O0JaDahgdm009MjUo6BSgg
+ XNhZjQRYAYEExMTjJ2TK
+ =q39P
+ -----END PGP SIGNATURE-----
+
+Merge tags 'devicetree-for-linus' and 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
+
+2nd set of device tree changes and SPI bug fixes for v3.3
+
+* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
+ of/irq: Add interrupts-names property to name an irq resource
+ of/address: Add reg-names property to name an iomem resource
+
+* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
+ spi/tegra: depend instead of select TEGRA_SYSTEM_DMA
+------------------------------------------------
+
+More precisely, a commit object begins with of one or more lines
+delimited by ASCII LF. The end of the header is signalled by an empty
+line. Any remaining text after the empty line forms the commit
+message. The header must not contain NUL.
+
+A "continuation line" in the header begins with an SP. The remainder
+of the line, after removing that SP, is concatenated to the previous
+line, while retaining the LF at the end of the previous line.
+
+When a line in the header begins with a letter other than SP, and has
+at least one SP in it, it is called a "field". A field consists of the
+"field name", which is the string before the first SP on the line, and
+its "value", which is everything after that SP. When the value
+consists of multiple lines, continuation lines are used.
+
+More than one field with the same name can appear in the header of an
+object, and the order in which they appear is significant. A commit
+object can contain these fields in the listed order:
+
+1. one "tree" field with the 40-character textual object name of the
+ associated tree object
+2. zero or more "parent" fields, each with 40-character textual object
+ name of the parent commit object
+3. one "author" field with an ident string
+4. one "committer" field with an ident string
+5. zero or one "encoding" field with an ascii string
+6. zero or more "mergetag" fields with associated tag object content
+7. zero or one "gpgsig" field with gpg signature content
+
+New kinds of fields may be added in later versions of git.
+
+Ident strings
+~~~~~~~~~~~~~
+Ident strings record who's responsible of doing something at what
+time. For a commit, the ident string in "author" line records who is
+the author of the associated changes and when the changes are
+made. The ident string in "committer" line records who commits the
+changes to the repository and at what time.
+
+An ident string consists of an email address and a timestamp. More
+precisely:
+
+1. Optionally, a name
+2. An email address wrapped around by `<` and `>`, followed by one
+ space (ASCII SP)
+3. The number of seconds since Epoch (00:00:00 UTC, January 1, 1970)
+ followed by a space (ASCII SP)
+4. Timezone: either plus or minus sign, followed by 4 decimal digits
+
+Name and email are encoded in UTF-8 and must must not contain ASCII
+NUL characters.
+
+Commit encoding
+~~~~~~~~~~~~~~~
+Encoding field describes that encoding that the commit message is
+encoded in. Encoding names must be recognized by iconv(3). By default,
+commit message is in UTF-8. It's discouraged to use encodings that can
+generate ASCII NUL characters.
+
+TAG OBJECTS
+-----------
+Tag object payload contains an object, object type, tag name, the name
+of the person ("tagger") who created the tag, and a message, which may
+contain a signature.
+
+------------------------------------------------
+$ git cat-file tag v1.5.0
+object 437b1b20df4b356c9342dac8d38849f24ef44f27
+type commit
+tag v1.5.0
+tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
+
+GIT 1.5.0
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
+nLE/L9aUXdWeTFPron96DLA=
+=2E+0
+-----END PGP SIGNATURE-----
+------------------------------------------------
+
+Tag object format resembles commit format. A tag commit may have the
+following fields in listed order:
+
+1. one "object" field with 40-character textual object name of the
+ tagged object
+2. one "type" field with type of the tagged object ("commit", "tag",
+ "blob", or "tree")
+3. one "tag" field with the name of the tag
+4. one "tagger" with an ident string
+
+New kinds of fields may be added in later versions of git.
+
+Any remaining text after the header forms the tag message. Tag message
+has no specified encoding. Anything that does not contain ASCII NUL
+characters are accepted.
+
+The object field must point to a valid object of type indicated by the
+type field. The tag name can be an arbitrary string without NUL bytes
+or embedded newlines; in practice it usually follows the restrictions
+described in linkgit:git-check-ref-format[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: [PATCH] git-svn: enable platform-specific authentication
From: Nikolaus Demmel @ 2012-02-19 4:06 UTC (permalink / raw)
To: git
In-Reply-To: <20120103204403.GI17548@login.drsnuggles.stderr.nl>
Matthijs Kooijman wrote
>
> I sent the below patch a few months ago, and not having it applied in
> git-svn bit me again just now. Did any of you get a chance to have a
> look at it?
>
> I'm still not 100% sure if this patch is correct for all the corner
> cases, but it works like a charm in the regular case.
>
> Perhaps it should just be included as is?
>
Hi,
is this patch also meant to deal with / fix the handling the keychain as an
authentication handler on OS X?
Is there anything I could do to help getting this moving forward? I could
try test it on OS X, if noone else can.
Cheers,
Nikolaus
--
View this message in context: http://git.661346.n2.nabble.com/PATCH-git-svn-enable-platform-specific-authentication-tp6376961p7298038.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Nikolaus Demmel @ 2012-02-19 4:03 UTC (permalink / raw)
To: git
In-Reply-To: <m3zkcgqt0g.fsf@localhost.localdomain>
Jakub Narebski wrote
>
> Igor <mrigor83@> writes:
>
>> I'm running into an issue where I have to enter my pem certificate
>> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
>> uses OS X KeyChain and remembers my password just fine. Is there a
>> known solution for this?
>
> I don't know if it is svn that has to remember password, or git that
> has to remember password. Git 1.7.9 learned "credentials API" that
> allows integration with platform native keychain mechanisms, and I
> think OS X Keychain is one of examples / supported platforms (but it
> might not made it into core git)... though I am not sure if it affects
> git-svn, or only HTTP(S) transport.
>
Wow, I just signed up to the mainling list to post about this, but it turns
out the latest message is exactly what I wanted to ask.
Like Eric wrote, I'm pretty sure it is svn that is meant to store the
password here and the perl bindings or the git-svn part fails to deal with
the os x keychain right. With pure svn the keychain authentication works
just fine. If I set up plaintext password storage in the svn configs, then
git svn is also able to store passwords.
There is also this macports ticket [1] that has been around for a while. But
that can only be fixed by an upstream fix here.
I would love to help to get this working, but I'm not sure how I can.
Cheers,
Nikolaus
[1] https://trac.macports.org/ticket/28329
--
View this message in context: http://git.661346.n2.nabble.com/git-svn-won-t-remember-pem-password-tp7295962p7298035.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Eric Wong @ 2012-02-19 1:30 UTC (permalink / raw)
To: Igor; +Cc: Matthijs Kooijman, Gustav Munkby, Edward Rudd, Carsten Bormann,
git
In-Reply-To: <E56535F6-2C9B-4D14-A88F-2471E34D2769@gmail.com>
Igor <mrigor83@gmail.com> wrote:
> I'm running into an issue where I have to enter my pem certificate
> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
> uses OS X KeyChain and remembers my password just fine. Is there a
> known solution for this? Other users have ran into same issue as
> described here:
> http://stackoverflow.com/questions/605519/does-git-svn-store-svn-passwords.
> However, that solution of removing .subversion folder did not work for
> me.
Hi Igor, this issue seems related to the platform specific auth
providers patches. There have been bugs in the SVN bindings in
previous releases and uncertainty about how everything works.
I haven't been interested enough to follow along closely[1], but maybe
some other folks Cc:-ed can finally push this through.
http://mid.gmane.org/20120103204403.GI17548@login.drsnuggles.stderr.nl
Basically I'm waiting for a patch that we can be certain won't break the
majority of existing use cases (especially no triggering of segfaults
and other nastiness in released versions of SVN bindings).
[1] - I barely use git-svn anymore, and wouldn't touch GNOME or OSX
with a 10-foot pole...
^ permalink raw reply
* git clean is not removing a submodule added to a branch when switching branches
From: Adrian Cornish @ 2012-02-18 21:27 UTC (permalink / raw)
To: git
If I add a submodule to a branch and then switch branches, git
checkout warns it cannot
remove the submodule. If I then issue a git clean - it says it removes
the submodule but
in fact does nothing at all. Is this a bug or expected behaviour.
TIA
Adrian
Below are cut&paste steps to reproduce.
git --version
#git version 1.7.8.4
git init submod
cd submod
echo "This is a submodule" > README.txt
git add .
git commit -m "Initial commit"
cd ..
git init prog
cd prog
echo "This is a program" > README.txt
git add .
git commit -a -m "Initial commit"
git checkout -b topic1
git submodule add ../submod
git commit -m "Added submodule"
git checkout master
#warning: unable to rmdir submod: Directory not empty
#Switched to branch 'master'
git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# submod/
#nothing added to commit but untracked files present (use "git add" to track)
git clean -fd
#Removing submod/
git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# submod/
#nothing added to commit but untracked files present (use "git add" to track)
^ permalink raw reply
* [PATCH] cherry-pick -x: always insert an empty line
From: Beat Bolli @ 2012-02-18 21:14 UTC (permalink / raw)
To: git; +Cc: Beat Bolli, Eric Raible
When cherry-picking a commit that has only a summary, the -x option
creates an invalid commit message because it puts the hash of the commit
being picked on the second line which should be left empty.
This patch fixes this buglet by always inserting an empty line before
the added line.
Aside from that, even with a non-trivial commit the generated note
"(cherry picked from commit 555c9864971744abb558796aea28e12a1ac20839)"
seems abrupt when appended directly.
Cc: Eric Raible <raible@nextest.com>
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
---
sequencer.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 5fcbcb8..63fd589 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -382,7 +382,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
}
if (opts->record_origin) {
- strbuf_addstr(&msgbuf, "(cherry picked from commit ");
+ strbuf_addstr(&msgbuf, "\n(cherry picked from commit ");
strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
strbuf_addstr(&msgbuf, ")\n");
}
--
1.7.9
^ permalink raw reply related
* [PATCH 0/1] Make libintl in libc detection more robust
From: John Szakmeister @ 2012-02-18 19:38 UTC (permalink / raw)
To: git; +Cc: John Szakmeister
When building the latest release, I noticed that pthreads support
was disabled. It turns out that the libintl in libc support is
adding "-lintl" to LIBS, even though I don't have that library on my
Mac. This patch fixes the issue by moving the check for libintl.h
closer to the checks for libintl in libc, and only adding "-lintl"
when NO_GETTEXT is empty.
This is my first time submitting a patch to git. I hope I've done
things correctly!
John Szakmeister (1):
Don't append -lintl when there is no gettext support
configure.ac | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
--
1.7.9.1
^ permalink raw reply
* [PATCH 1/1] Don't append -lintl when there is no gettext support
From: John Szakmeister @ 2012-02-18 19:38 UTC (permalink / raw)
To: git; +Cc: John Szakmeister
In-Reply-To: <1329593884-9999-1-git-send-email-john@szakmeister.net>
The check for libintl in a C library incorrectly assumes that if it's
not builtin then it must exist externally. Instead, let's check for
the existence of libintl.h first. If libintl.h exists, and libintl is
not in libc, then we append the library.
Signed-off-by: John Szakmeister <john@szakmeister.net>
---
configure.ac | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 630dbdd..8471f5c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -640,7 +640,18 @@ AC_CHECK_LIB([c], [gettext],
[LIBC_CONTAINS_LIBINTL=YesPlease],
[LIBC_CONTAINS_LIBINTL=])
AC_SUBST(LIBC_CONTAINS_LIBINTL)
-test -n "$LIBC_CONTAINS_LIBINTL" || LIBS="$LIBS -lintl"
+
+#
+# Define NO_GETTEXT if you don't want Git output to be translated.
+# A translated Git requires GNU libintl or another gettext implementation
+AC_CHECK_HEADER([libintl.h],
+[NO_GETTEXT=],
+[NO_GETTEXT=YesPlease])
+AC_SUBST(NO_GETTEXT)
+
+if test -z "$NO_GETTEXT"; then
+ test -n "$LIBC_CONTAINS_LIBINTL" || LIBS="$LIBS -lintl"
+fi
## Checks for header files.
AC_MSG_NOTICE([CHECKS for header files])
@@ -824,13 +835,6 @@ AC_CHECK_HEADER([paths.h],
[HAVE_PATHS_H=])
AC_SUBST(HAVE_PATHS_H)
#
-# Define NO_GETTEXT if you don't want Git output to be translated.
-# A translated Git requires GNU libintl or another gettext implementation
-AC_CHECK_HEADER([libintl.h],
-[NO_GETTEXT=],
-[NO_GETTEXT=YesPlease])
-AC_SUBST(NO_GETTEXT)
-#
# Define HAVE_LIBCHARSET_H if have libcharset.h
AC_CHECK_HEADER([libcharset.h],
[HAVE_LIBCHARSET_H=YesPlease],
--
1.7.9.1
^ permalink raw reply related
* Re: Does pack v4 do anything to commits?
From: Nicolas Pitre @ 2012-02-18 15:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <CACsJy8CZPG3b3LBF-EFO_kOv6i157jy5414+bHcqiwOKyC+8VA@mail.gmail.com>
On Sat, 18 Feb 2012, Nguyen Thai Ngoc Duy wrote:
> Hi Nico,
>
> I had an experiment on speeding up "rev-list --all". If I cache sha-1
> of tree and parent, and committer date of single-parent commits, in
> binary form, rev-list can be sped up significantly. On linux-2.6.git,
> it goes from 14s to 4s (2s to 0.8 for git.git). Profiling shows that
> commit parsing (get_sha1_hex, parse_commit_date) dominates rev-list
> time.
>
> >From what I remember, pack v4 is mainly about changing tree
> representation so that we can traverse object DAG as fast as possible.
> Do you do anything to commit representation too? Maybe it's worth
> storing the above info along with the compressed commit objects in
> pack to shave some more seconds.
Both the tree and commit object representations are completely changed
to evacuate SHA1 parsing and searching entirely. The SHA1 references
are uncompressed, and replaced by indices into the pack for direct
lookup without any binary search. And the commit dates are stored in
binary form. All path names as well as author/committer names are
factored out into a table as well. This should make history traversal
operations almost as fast as walking a linked list in memory, while
making the actual pack size smaller at the same time.
> By the way, is latest packv4 code available somewhere to fetch?
Well, not yet. Incidentally, I'm going in the Caribbeans for a week in
a week, with no kids and only my wife who is going to be busy with scuba
diving activities. Like I did last year, I'm going to take some time to
pursue my work on Pack v4 during that time. And I intend to publish it
when I come back, whatever state it is in, so someone else can complete
the work eventually (I have too much to do to spend significant time on
Git these days).
Nicolas
^ permalink raw reply
* [PATCH] completion: remote set-* <name> and <branch>
From: Philip Jägenstedt @ 2012-02-18 13:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Philip Jägenstedt
Complete <name> only for set-url. For set-branches and
set-head, complete <name> and <branch> over the network,
like e.g. git pull already does.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
---
contrib/completion/git-completion.bash | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1505cff..8e7abb6 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -738,6 +738,9 @@ __git_complete_remote_or_refspec ()
{
local cur_="$cur" cmd="${words[1]}"
local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
+ if [ "$cmd" = "remote" ]; then
+ c=$((++c))
+ fi
while [ $c -lt $cword ]; do
i="${words[c]}"
case "$i" in
@@ -788,7 +791,7 @@ __git_complete_remote_or_refspec ()
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
fi
;;
- pull)
+ pull|remote)
if [ $lhs = 1 ]; then
__gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
else
@@ -2289,7 +2292,7 @@ _git_config ()
_git_remote ()
{
- local subcommands="add rename rm show prune update set-head"
+ local subcommands="add rename rm set-head set-branches set-url show prune update"
local subcommand="$(__git_find_on_cmdline "$subcommands")"
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
@@ -2297,9 +2300,12 @@ _git_remote ()
fi
case "$subcommand" in
- rename|rm|show|prune)
+ rename|rm|set-url|show|prune)
__gitcomp_nl "$(__git_remotes)"
;;
+ set-head|set-branches)
+ __git_complete_remote_or_refspec
+ ;;
update)
local i c='' IFS=$'\n'
for i in $(git --git-dir="$(__gitdir)" config --get-regexp "remotes\..*" 2>/dev/null); do
--
1.7.9.1.245.g4cbe6
^ permalink raw reply related
* Re: [PATCH] remote: align set-branches builtin usage and documentation
From: Philip Jägenstedt @ 2012-02-18 13:11 UTC (permalink / raw)
To: git
In-Reply-To: <1329563867-13283-1-git-send-email-philip@foolip.org>
On Sat, Feb 18, 2012 at 12:17, Philip Jägenstedt
<philip.jagenstedt@gmail.com> wrote:
> The order of [--add] <name> <branch>... was inconsistent
> between builtin remote usage messages and git-remote.txt.
To clarify, it's the order of "git remote set-branches" that is
inconsistent with the two instances the patch touches:
usage: git remote set-branches <name> <branch>...
or: git remote set-branches --add <name> <branch>...
--
Philip Jägenstedt
^ permalink raw reply
* Re: Gitk local language issue
From: Pat Thoyts @ 2012-02-18 13:09 UTC (permalink / raw)
To: shyamal; +Cc: git
In-Reply-To: <1329467459691-7293532.post@n2.nabble.com>
shyamal <shyamal2005@gmail.com> writes:
>Hi,
>
>I am working in Japan now on a windows environment.
>I installed GIT on my machine.When I run the application,The menus are in
>Japanese.To get the English menu I added
>@set LANG=en
>at the beginning of git.cmd file.This worked like a magic :-)
>But when I click the Visualize master' history from the repository menu of
>Git Gui, a new interface (Gitk:Websites) opens where all the menus are still
>in Japanese.Any idea how to change the menu to English in Gitk too?
>
>Thanks in advance
>
>Regards,
>Shyamal.
If I modify the git.cmd file here on my English system to include
@set LANG=fr just after the @set PLINK_PROTOCOL=ssh command, then git
gui runs with French menus and selecting the view history menu item
launches gitk with French menus.
This is because git-gui executes a new tcl interpreter subprocess passing
in the known gitk script location. So the gitk process inherits the
git-gui environment (including this LANG setting). It doesn't call the
gitk.cmd script on Windows.
Possibly your interpreter is picking up some other locale setting. The
msgcat script will use LC_ALL, LC_MESSAGES or LANG (in that order) and
only makes use of the first one it sees. So perhaps you have an LC_ALL
set someplace - however, I would assume that would force the git-gui
script to use that locale too.
One quick hack would be to modify bin/gitk and after the msgcat
initialization force the locale using:
msgcat::mclocale en
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: git-svn won't remember pem password
From: Jakub Narebski @ 2012-02-18 11:30 UTC (permalink / raw)
To: Igor; +Cc: git, Eric Wong
In-Reply-To: <E56535F6-2C9B-4D14-A88F-2471E34D2769@gmail.com>
Igor <mrigor83@gmail.com> writes:
> I'm running into an issue where I have to enter my pem certificate
> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
> uses OS X KeyChain and remembers my password just fine. Is there a
> known solution for this? Other users have ran into same issue as
> described here:
>
> http://stackoverflow.com/questions/605519/does-git-svn-store-svn-passwords
> However, that solution of removing .subversion folder did not work
> for me.
I don't know if it is svn that has to remember password, or git that
has to remember password. Git 1.7.9 learned "credentials API" that
allows integration with platform native keychain mechanisms, and I
think OS X Keychain is one of examples / supported platforms (but it
might not made it into core git)... though I am not sure if it affects
git-svn, or only HTTP(S) transport.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] remote: align set-branches builtin usage and documentation
From: Philip Jägenstedt @ 2012-02-18 11:17 UTC (permalink / raw)
To: git; +Cc: Philip Jägenstedt
The order of [--add] <name> <branch>... was inconsistent
between builtin remote usage messages and git-remote.txt.
Align it closer to the order used in set-url.
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
---
Documentation/git-remote.txt | 2 +-
builtin/remote.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 5a8c506..d376d19 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -14,7 +14,7 @@ SYNOPSIS
'git remote rename' <old> <new>
'git remote rm' <name>
'git remote set-head' <name> (-a | -d | <branch>)
-'git remote set-branches' <name> [--add] <branch>...
+'git remote set-branches' [--add] <name> <branch>...
'git remote set-url' [--push] <name> <newurl> [<oldurl>]
'git remote set-url --add' [--push] <name> <newurl>
'git remote set-url --delete' [--push] <name> <url>
diff --git a/builtin/remote.c b/builtin/remote.c
index f54a89a..fec92bc 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -16,7 +16,7 @@ static const char * const builtin_remote_usage[] = {
"git remote [-v | --verbose] show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
"git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)...]",
- "git remote set-branches <name> [--add] <branch>...",
+ "git remote set-branches [--add] <name> <branch>...",
"git remote set-url <name> <newurl> [<oldurl>]",
"git remote set-url --add <name> <newurl>",
"git remote set-url --delete <name> <url>",
--
1.7.9.1.246.g77c8c.dirty
^ permalink raw reply related
* Re: SIGPIPE handling (Re: [PATCH v3 0/3])
From: Jeff King @ 2012-02-18 10:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Thomas Rast, Jehan Bing, git
In-Reply-To: <20120218100517.GA8998@burratino>
On Sat, Feb 18, 2012 at 04:06:07AM -0600, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Less robust than that is to just ignore SIGPIPE in most git programs
> > (which don't benefit from it, and where it is only a liability), but
> > then manually enable it for the few that care
>
> This seems backwards. Aren't the only places where it is just a
> liability places where git is writing to a pipe that git has created?
Yes. But the problem is that those spots are buried deep within library
code, and are an implementation detail that the caller shouldn't need to
know about.
But more importantly, I see SIGPIPE as an optimization. The program on
the generating side of a pipe _could_ keep making output and dumping it
nowhere. So the optimization is about telling it early that it can stop
bothering. But that optimization is affecting correctness in some cases.
And in cases of correctness versus optimization, it's nice if we can be
correct by default and then optimize in places where it matters most and
where we've verified that correctness isn't harmed.
I also think it's simply easier to list the places that benefit from
SIGPIPE than those that are harmed by it. But if we wanted to go the
other way (allow by default and turn it off in a few programs), at the
very least all of the network programs (receive-pack. upload-pack, etc)
should start ignoring it completely.
> We could keep the benefits of SIGPIPE (including simpler error
> handling and lack of distracting EPIPE message) in most code, and only
> switch to SIGPIPE-ignored semantics where the signal has a chance to
> cause harm. Maybe run_command should automatically ignore SIGPIPE
> when creating a pipe for the launched command's standard input (with a
> flag to ask not to), as a rough heuristic.
That's a reasonable heuristic, but not foolproof. If I have a
long-running subprocess with a pipe, then SIGPIPE will be off for a long
time, meaning the code you thought was protected by it is not. In
practice, I think it would work OK with our current code-base, as we
tend to have short-lived subprocesses. You'd have to special case the
starting of the pager, of course, but that's not too hard.
> There's a subtlety I'm glossing over here, which is that for commands
> that produce a lot of output (think: "git fetch --all"), output may
> still not the primary goal. I think even they should not block
> SIGPIPE, to follow the principle of least surprise in the following
> interaction:
>
> git fetch --all 2>&1 | less
> ... one page later, get bored ...
> q (to quit)
>
> Most Unix programs would be killed by SIGPIPE after such a sequence,
> so I would expect git to be, too.
But it's quite non-deterministic whether or when git-fetch will be
killed. It may have written all data to the pipe. You may quit, but
fetch still runs for a while before producing output. If you want it
killed, you are much better off to do so by sending it SIGINT.
-Peff
^ permalink raw reply
* Re: SIGPIPE handling (Re: [PATCH v3 0/3])
From: Jonathan Nieder @ 2012-02-18 10:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Rast, Jehan Bing, git
In-Reply-To: <20120218100517.GA8998@burratino>
Jonathan Nieder wrote:
> There's a subtlety I'm glossing over here, which is that for commands
> that produce a lot of output (think: "git fetch --all"), output may
> still not the primary goal.
Gah. The output that goes to the terminal may not be the primary
goal, I mean (missing "be").
Sorry for the noise.
Jonathan
^ permalink raw reply
* SIGPIPE handling (Re: [PATCH v3 0/3])
From: Jonathan Nieder @ 2012-02-18 10:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Rast, Jehan Bing, git
In-Reply-To: <20120218085221.GA13922@sigill.intra.peff.net>
Hi,
Jeff King wrote:
> Less robust than that is to just ignore SIGPIPE in most git programs
> (which don't benefit from it, and where it is only a liability), but
> then manually enable it for the few that care
This seems backwards. Aren't the only places where it is just a
liability places where git is writing to a pipe that git has created?
We could keep the benefits of SIGPIPE (including simpler error
handling and lack of distracting EPIPE message) in most code, and only
switch to SIGPIPE-ignored semantics where the signal has a chance to
cause harm. Maybe run_command should automatically ignore SIGPIPE
when creating a pipe for the launched command's standard input (with a
flag to ask not to), as a rough heuristic.
There's a subtlety I'm glossing over here, which is that for commands
that produce a lot of output (think: "git fetch --all"), output may
still not the primary goal. I think even they should not block
SIGPIPE, to follow the principle of least surprise in the following
interaction:
git fetch --all 2>&1 | less
... one page later, get bored ...
q (to quit)
Most Unix programs would be killed by SIGPIPE after such a sequence,
so I would expect git to be, too.
Just my two cents,
Jonathan
^ permalink raw reply
* Re: [PATCH v3 0/3]
From: Jeff King @ 2012-02-18 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jehan Bing, git
In-Reply-To: <7v8vk0r481.fsf@alter.siamese.dyndns.org>
On Fri, Feb 17, 2012 at 11:27:26PM -0800, Junio C Hamano wrote:
> > I'd be happy if we just ignored SIGPIPE everywhere, but turned it on for
> > the log family.
>
> Hmmmm, now you confused me... What is special about the log family? Do
> you mean "when we use pager"? But then we are writing into the pager,
> which the user can make it exit, which in turn causes us to write into the
> pipe, so I would expect that we would want to ignore SIGPIPE --- ah, then
> we explicitly catch error in xwrite() and say die() which we do not want.
Sort of. I mentioned the log family because those are the commands that
tend to generate large amounts of input, and which are likely to hit
SIGPIPE. But let me elaborate on my thinking a bit.
There are basically three types of writing callsites in git:
1. Careful calls to write() or fwrite().
These are the majority of calls. In these, we check the return
value of write() and die, return the error code, or whatever is
appropriate for the callsite. SIGPIPE kills the program before the
careful code gets the chance to make a decision about what to do.
At best, this is a nuisance; even if the program is going to die(),
it's likely that the custom code could produce a useful error
message. At worst it causes bugs. For example, we may write to a
subprocess that only needs part of our input to make a decision
(e.g., some hooks and credential helpers). With SIGPIPE, we end up
dying even though no error has occurred. Worse, these are often
annoying heisenbugs that depend on the timing of write() and
close() between the two processes.
2. Non-careful calls of small, fixed-size output.
Things like "git remote" will write some output to stdout via
printf and not bother checking the return code. As the main purpose
of the program is to create output, it's OK to be killed by
SIGPIPE if it happens due to a write to stdout. But respecting
SIGPIPE doesn't buy as all that much. It might save us from making
a few write() calls that will go to nowhere, but most of the work
has already been done by the time we are outputting.
And it has a cost to the other careful write calls in the same
program, because respecting SIGPIPE is a per-process thing. So for
something like "git remote show foo", while we would like SIGPIPE
to kick in for output to stdout, we would not want it for a pipe we
opened to talk to ls-remote.
3. Non-careful calls of large, streaming data.
Commands like "git log" will non-carefully output to stdout, as
well, but they will generate tons of data, consuming possibly
minutes of CPU time (e.g., "git log -p"). If whoever is reading the
output stops doing so, we really want to kill the program to avoid
wasting CPU time. In this instance, SIGPIPE is a big win.
It still has the downside that careful calls in the same program
will be subject to using SIGPIPE. For "log" and friends, this is
probably OK with the current code, as we don't make a lot of pipes.
But that is somewhat of an implementation detail. E.g., "git log
-p" with external diff or textconv writes to a tempfile, and then
runs a subprocess with the tempfile as input. But we could just as
easily have used pipes, and may choose to do so in the future. You
may even be able to trigger a convert_to_git filter in the current
code, which does use pipes.
So basically, I find SIGPIPE to be a simplistic too-heavy hammer that
ends up affecting all writes to pipes, when in reality we are only
interested in affecting ones to some "main" output (usually stdout).
That works OK for small Unix-y programs like "head", but is overly
simplistic for something as big as git.
In an ideal world, we could set a per-descriptor version of SIGPIPE, and
just turn it on for stdout (or somehow find out which descriptor caused
the SIGPIPE after the fact). But that's not possible.
So our next best thing would be to actually check the results of
these non-careful writes. Unfortunately, this means either:
a. wrapping every printf with a function that will appropriately die
on error. This makes the code more cumbersome.
or
b. occasionally checking ferror(stdout) while doing long streams
(e.g., checking it after each commit is written in git log, and
aborting if we saw a write error). This is less cumbersome, but it
does mean that errno may or may not still be accurate by the time
we notice the error. So it's hard to reliably differentiate EPIPE
from other errors. It would be nice, for example, to have git log
exit silently on EPIPE, but properly print an error for something
like ENOSPC. But perhaps that isn't a big deal, as I believe right
now that we would silently ignore something like ENOSPC.
Less robust than that is to just ignore SIGPIPE in most git programs
(which don't benefit from it, and where it is only a liability), but
then manually enable it for the few that care (the log family, and
perhaps diff. Maybe things like "git tag -l", though that output tends
to be pretty small). But I think it would work OK in practice, because
those commands don't tend to make pipes other than the "main" output.
And it's quite easy to implement.
> So you want to let SIGPIPE silently kill us when the pager is in use; is
> that it?
That's an OK heuristic, as the pager being in use is a good sign that we
will generate long, streaming output. It has two downsides, though. One
is that it suffers from the too-heavy hammer of the preceding paragraph.
The other is that it only catches when _we_ create the pipe. You would
also want to catch something like:
git rev-list | head
and stop the traversal. So I think it is less about whether a pager is
in use and more about whether we are creating long output that would
benefit from being cut off early. The pager is an indicator of that, but
it's not a perfect one; I think we'd do better to mark those spots
manually (i.e., by re-enabling SIGPIPE in commands that we deem
appropriate).
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/3]
From: Junio C Hamano @ 2012-02-18 7:27 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Jehan Bing, git
In-Reply-To: <20120218005148.GA1940@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'd be happy if we just ignored SIGPIPE everywhere, but turned it on for
> the log family.
Hmmmm, now you confused me... What is special about the log family? Do
you mean "when we use pager"? But then we are writing into the pager,
which the user can make it exit, which in turn causes us to write into the
pipe, so I would expect that we would want to ignore SIGPIPE --- ah, then
we explicitly catch error in xwrite() and say die() which we do not want.
So you want to let SIGPIPE silently kill us when the pager is in use; is
that it?
^ permalink raw reply
* Re: [PATCH v2] Add a setting to require a filter to be successful
From: Junio C Hamano @ 2012-02-18 7:27 UTC (permalink / raw)
To: Jehan Bing; +Cc: git, Johannes Sixt
In-Reply-To: <4F3EF43D.2040102@orb.com>
Jehan Bing <jehan@orb.com> writes:
> If I understand what you're saying, current version of git already
> have the problem: if a filter fails without reading anything, git will
> die instead of using the unfiltered content. My patch has only made
> the issue apparent by testing with a failing filter.
> Am I understanding correctly?
Yes.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox