git/log-tree.c, branch v1.6.3

log-tree: fix patch filename computation in "git format-patch"

2009-03-27T08:10:27Z

When using "git format-patch", "get_patch_filename" in "log-tree.c" calls "strbuf_splice" that could die with the following message: "`pos + len' is too far after the end of the buffer" if you have: buf->len < start_len + FORMAT_PATCH_NAME_MAX but: buf->len + suffix_len > start_len + FORMAT_PATCH_NAME_MAX This patch tries to get rid of that bug. [jc: w/ simplified logic] Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

format-patch: --attach/inline uses filename instead of SHA1

2009-03-23T04:45:19Z

Currently when format-patch is used with --attach or --inline the patch attachment has the SHA1 of the commit for its filename. This replaces the SHA1 with the filename used by format-patch when outputting to files. Fix tests relying on the SHA1 output and add a test showing how the --suffix option affects the attachment filename output. Signed-off-by: Stephen Boyd Signed-off-by: Junio C Hamano

format-patch: move get_patch_filename() into log-tree

2009-03-23T04:42:05Z

Signed-off-by: Stephen Boyd Signed-off-by: Junio C Hamano

Merge branch 'tr/format-patch-thread'

2009-03-11T20:48:07Z

* tr/format-patch-thread: format-patch: support deep threading format-patch: thread as reply to cover letter even with in-reply-to format-patch: track several references format-patch: threading test reactivation Conflicts: builtin-log.c

Move local variables to narrower scopes

2009-03-08T04:52:23Z

These weren't used outside and can be safely moved Signed-off-by: Benjamin Kramer Signed-off-by: Junio C Hamano

format-patch: track several references

2009-02-22T04:26:03Z

Currently, format-patch can only track a single reference (the In-Reply-To:) for each mail. To ensure proper threading, we should list all known references for every mail. Change the rev_info.ref_message_id field to a string_list, so that we can append references at will, and change the output formatting routines to print all of them in the References: header. The last entry in the list is implicitly assumed to be the In-Reply-To:, which gives output consistent with RFC 2822: The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). Note that this is just preparatory work; nothing uses it yet, so all "References:" fields in the output are still only one deep. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

log: do not print ellipses with --abbrev-commit

2009-02-14T01:18:22Z

'git log --abbrev-commit' added an ellipsis to all commit names that were abbreviated. This was particularly annoying if you wanted to cut&paste the sha1 from the terminal, since selecting by word would pick up '...' too. So use find_unique_abbrev() instead of diff_unique_abbrev() in all log-related commit sha1 printing routines, and also change the formatting of the 'Merge: parent1 parent2' line output via pretty_print_commit(). Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

Fix machine-parseability of 'git log --source'

2008-11-16T08:24:41Z

The space between the commit and the source attribute is not easily machine-parseable: if we combine --source with --parents and give a SHA1 as a starting point, it's unnecessarily hard to see where the list of parents ends and the source decoration begins. Example: git show --parents --source $(git rev-list HEAD) which is admittedly contrived, but can easily happen in scripting. So use a instead of a space as the source separator. The other decorations didn't have this issue, because they were surrounded by parenthesis, so it's obvious that they aren't parent SHA1's. It so happens that _visually_ this makes no difference for "git log --source", since "commit <40-char SHA1>" is 47 characters, so both a space and a will end up showing as a single commit. Of course, with '--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the difference. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

Make '--decorate' set an explicit 'show_decorations' flag

2008-11-04T08:08:19Z

We will want to add decorations without necessarily showing them, so add an explicit revisions info flag as to whether we're showing decorations or not. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

Add a 'source' decorator for commits

2008-11-04T08:08:03Z

We already support decorating commits by tags or branches that point to them, but especially when we are looking at multiple branches together, we sometimes want to see _how_ we reached a particular commit. We can abuse the '->util' field in the commit to keep track of that as we walk the commit lists, and get a reasonably useful view into which branch or tag first reaches that commit. Of course, if the commit is reachable through multiple sources (which is common), our particular choice of "first" reachable is entirely random and depends on the particular path we happened to follow. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano