git/builtin, branch v1.8.2.2

Merge branch 'jk/receive-pack-deadlocks-with-early-failure' into maint

2013-04-26T18:12:17Z

* jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors

Merge branch 'jk/chopped-ident' into maint

2013-04-26T18:11:51Z

* jk/chopped-ident: blame: handle broken commit headers gracefully pretty: handle broken commit headers gracefully cat-file: print tags raw for "cat-file -p"

Merge branch 'rt/commentchar-fmt-merge-msg' into maint

2013-04-26T18:10:47Z

* rt/commentchar-fmt-merge-msg: t6200: avoid path mangling issue on Windows fmt-merge-msg: use core.commentchar in tag signatures completely fmt-merge-msg: respect core.commentchar in people credits

Merge branch 'jc/merge-tag-object' into maint

2013-04-24T23:14:06Z

"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. Make the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit

cherry-pick/revert: make usage say '...'

2013-04-24T16:48:01Z

The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey Signed-off-by: Junio C Hamano

Merge branch 'jk/show-branch-strbuf' into maint

2013-04-22T18:26:57Z

* jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer

Merge branch 'jc/apply-ws-fix-tab-in-indent' into maint

2013-04-22T18:26:56Z

* jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer

receive-pack: close sideband fd on early pack errors

2013-04-19T21:43:24Z

Since commit a22e6f8 (receive-pack: send pack-processing stderr over sideband, 2012-09-21), receive-pack will start an async sideband thread to copy the stderr from our index-pack or unpack-objects child to the client. We hand the thread's input descriptor to unpack(), which puts it in the "err" member of the "struct child_process". After unpack() returns, we use finish_async() to reap the sideband thread. The thread is only ready to die when it gets EOF on its pipe, which is connected to the err descriptor. So we expect all of the write ends of that pipe to be closed as part of unpack(). Normally, this works fine. After start_command forks, it closes the parent copy of the descriptor. Then once the child exits (whether it was successful or not), that closes the only remaining writer. However, there is one code-path in unpack() that does not handle this. Before we decide which of unpack-objects or index-pack to use, we read the pack header ourselves to see how many objects it contains. If there is an error here, we exit without running either sub-command, the pipe descriptor remains open, and we are in a deadlock, waiting for the sideband thread to die (which is in turn waiting for us to close the pipe). We can fix this by making sure that unpack() always closes the pipe before returning. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

blame: handle broken commit headers gracefully

2013-04-17T21:50:45Z

split_ident_line() can leave us with the pointers date_begin, date_end, tz_begin and tz_end all set to NULL. Check them before use and supply the same fallback values as in the case of a negative return code from split_ident_line(). The "(unknown)" is not actually shown in the output, though, because it will be converted to a number (zero) eventually. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

cat-file: print tags raw for "cat-file -p"

2013-04-17T21:48:45Z

When "cat-file -p" prints commits, it shows them in their raw format, since git's format is already human-readable. For tags, however, we print the whole thing raw except for one thing: we convert the timestamp on the tagger line into a human-readable date. This dates all the way back to a0f15fa (Pretty-print tagger dates, 2006-03-01). At that time there was no other way to pretty-print a tag. These days, however, neither of those matters much. The normal way to pretty-print a tag is with "git show", which is much more flexible than "cat-file -p". Commit a0f15fa also built "verify-tag --verbose" (and subsequently "tag -v") around the "cat-file -p" output. However, that behavior was lost in commit 62e09ce (Make git tag a builtin, 2007-07-20), and we went back to printing the raw tag contents. Nobody seems to have noticed the bug since then (and it is arguably a saner behavior anyway, as it shows the actual bytes for which we verified the signature). Let's drop the tagger-date formatting for "cat-file -p". It makes us more consistent with cat-file's commit pretty-printer, and as a bonus, we can drop the hand-rolled tag parsing code in cat-file (which happened to behave inconsistently with the tag pretty-printing code elsewhere). This is a change of output format, so it's possible that some callers could considered this a regression. However, the original behavior was arguably a bug (due to the inconsistency with commits), likely nobody was relying on it (even we do not use it ourselves these days), and anyone relying on the "-p" pretty-printer should be able to expect a change in the output format (i.e., while "cat-file" is plumbing, the output format of "-p" was never guaranteed to be stable). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano