aboutsummaryrefslogtreecommitdiff
path: root/combine-diff.c
Commit message (Collapse)AuthorAge
* diff-files: -c and --cc options.Junio C Hamano2006-01-28
| | | | | | | | | | This ports the "combined diff" to diff-files so that differences to the working tree files since stage 2 and stage 3 are shown the same way as combined diff output from diff-tree for the merge commit would be shown if the current working tree files are committed. Signed-off-by: Junio C Hamano <junkio@cox.net>
* combine-diff: better hunk splitting.Junio C Hamano2006-01-28
| | | | | | | | It considered an otherwise unchanged line that had line removals in front of it an interesting line, which caused hunks to have one extra the trailing context line. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diff-tree --cc: squelch header generation on empty patch.Junio C Hamano2006-01-28
| | | | | | | | | | | Earlier round showed the commit log header and "diff --combined" header even for paths that had no interesting hunk under --cc flag. Move the header display logic around to squelch them. With this, a merge that does not have any interesting merges will not be shown with --cc option, unless -m is used at the same time. Signed-off-by: Junio C Hamano <junkio@cox.net>
* combine-diff: extend --cc logic to Octopus.Junio C Hamano2006-01-28
| | | | | | | | | | | Santi Bejar points out that a hunk that changes from all the same common parents except one is uninteresting. The earlier round marked changes from only one parent uninteresting, but this also marks hunks that have the same change from all but one parent uninteresting, which is a natural extension of the original idea to Octopus merges. Signed-off-by: Junio C Hamano <junkio@cox.net>
* combine-diff: minor output changes.Junio C Hamano2006-01-28
| | | | | | | | | | Remove extra whitespace between the change indicators and the body text. That is more in line with the uncombined unified diff output (pointed out by Santi Bejar). When showing --cc, say so instead of saying just --combined. Signed-off-by: Junio C Hamano <junkio@cox.net>
* combine-diff: fix appending at the tail of a list.Junio C Hamano2006-01-28
| | | | | | | | ... and use the established pattern of tail initialized to point at the head pointer for an empty list, and updated to point at the next pointer field of the item at the tail when appending. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diff-tree --cc: denser combined diff output for a merge commit.Junio C Hamano2006-01-28
| | | | | | | | Building on the previous '-c' (combined) option, '--cc' option squelches the output further by omitting hunks that consist of difference with solely one parent. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diff-tree -c: show a merge commit a bit more sensibly.Junio C Hamano2006-01-28
A new option '-c' to diff-tree changes the way a merge commit is displayed when generating a patch output. It shows a "combined diff" (hence the option letter 'c'), which looks like this: $ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18 diff-tree fec9ebf... (from parents) Merge: 0620db3... 8a263ae... Author: Junio C Hamano <junkio@cox.net> Date: Sun Jan 15 22:25:35 2006 -0800 Merge fixes up to GIT 1.1.3 diff --combined describe.c @@@ +98,7 @@@ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; } - static void describe(char *arg) - static void describe(struct commit *cmit, int last_one) ++ static void describe(char *arg, int last_one) { + unsigned char sha1[20]; + struct commit *cmit; There are a few things to note about this feature: - The '-c' option implies '-p'. It also implies '-m' halfway in the sense that "interesting" merges are shown, but not all merges. - When a blob matches one of the parents, we do not show a diff for that path at all. For a merge commit, this option shows paths with real file-level merge (aka "interesting things"). - As a concequence of the above, an "uninteresting" merge is not shown at all. You can use '-m' in addition to '-c' to show the commit log for such a merge, but there will be no combined diff output. - Unlike "gitk", the output is monochrome. A '-' character in the nth column means the line is from the nth parent and does not appear in the merge result (i.e. removed from that parent's version). A '+' character in the nth column means the line appears in the merge result, and the nth parent does not have that line (i.e. added by the merge itself or inherited from another parent). The above example output shows that the function signature was changed from either parents (hence two "-" lines and a "++" line), and "unsigned char sha1[20]", prefixed by a " +", was inherited from the first parent. The code as sent to the list was buggy in few corner cases, which I have fixed since then. It does not bother to keep track of and show the line numbers from parent commits, which it probably should. Signed-off-by: Junio C Hamano <junkio@cox.net>