summaryrefslogtreecommitdiff
path: root/builtin/for-each-ref.c
AgeCommit message (Collapse)AuthorFilesLines
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-5/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08for-each-ref: add split message parts to %(contents:*).Libravatar Michał Górny1-6/+26
The %(body) placeholder returns the whole body of a tag or commit, including the signature. However, callers may want to get just the body without signature, or just the signature. Rather than change the meaning of %(body), which might break some scripts, this patch introduces a new set of placeholders which break down the %(contents) placeholder into its constituent parts. [jk: initial patch by mg, rebased on top of my refactoring and with tests by me] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08for-each-ref: handle multiline subjects like --prettyLibravatar Jeff King1-5/+24
Generally the format of a git tag or commit message is: subject body body body body body body However, we occasionally see multiline subjects like: subject with multiple lines body body body body body body The rest of git treats these multiline subjects as something to be concatenated and shown as a single line (e.g., "git log --pretty=format:%s" will do so since f53bd74). For consistency, for-each-ref should do the same with its "%(subject)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08for-each-ref: refactor subject and body placeholder parsingLibravatar Jeff King1-25/+29
The find_subpos function was a little hard to use, as well as to read. It would sometimes write into the subject and body pointers, and sometimes not. The body pointer sometimes could be compared to subject, and sometimes not. When actually duplicating the subject, the caller was forced to figure out again how long the subject is (which is not too big a deal when the subject is a single line, but hard to extend). The refactoring makes the function more straightforward, both to read and to use. We will always put something into the subject and body pointers, and we return explicit lengths for them, too. This lays the groundwork both for more complex subject parsing (e.g., multiline), as well as splitting the body into subparts (like the text versus the signature). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-26for-each-ref: fix objectname:short bugLibravatar Jay Soffian1-1/+2
When objectname:short was introduced, it forgot to copy the result of find_unique_abbrev. Because the result of find_unique_abbrev is a pointer to static buffer, this resulted in the same value being substituted in for each ref. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-07Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: Change C99 comments to old-style C comments
2010-06-07Change C99 comments to old-style C commentsLibravatar Tor Arntsen1-2/+2
Signed-off-by: Tor Arntsen <tor@spacetec.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-18for-each-ref: Field with abbreviated objectnameLibravatar Michael J Gruber1-0/+3
Introduce a :short modifier to objectname which outputs the abbreviated object name. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-10Merge branch 'lt/deepen-builtin-source'Libravatar Junio C Hamano1-0/+996
* lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+955
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>