summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2010-03-20checkout -m --conflict=diff3: add a label for ancestorLibravatar Jonathan Nieder1-0/+1
git checkout --merge --conflict=diff3 can be used to present conflict hunks including text from the common ancestor. The added information is helpful for resolving a merge by hand, and merge tools tend to understand it because it is very similar to what ‘diff3 -m’ produces. Unlike current git, diff3 -m includes a label for the merge base on the ||||||| line, and unfortunately, some tools cannot parse the conflict hunks without it. Humans can benefit from a cue when learning to interpreting the format, too. Mark the start of the text from the old branch with a label based on the branch’s name. git rerere does not have trouble parsing this output and its preimage ids are unchanged since it includes its own code for recreating conflict hunks. No other code in git tries to parse conflict hunks. Requested-by: Stefan Monnier <monnier@iro.umontreal.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20checkout --conflict=diff3: add a label for ancestorLibravatar Jonathan Nieder1-1/+1
git checkout --conflict=diff3 can be used to present conflicts hunks including text from the common ancestor: <<<<<<< ours ourside ||||||| original ======= theirside >>>>>>> theirs The added information is helpful for resolving a merge by hand, and merge tools can usually understand it without trouble because it looks like output from ‘diff3 -m’. diff3 includes a label for the merge base on the ||||||| line, and it seems some tools (for example, Emacs 22’s smerge-mode) cannot parse conflict hunks without such a label. Humans could use help in interpreting the output, too. So change the marker for the start of the text from the common ancestor to include the label “base”. git rerere’s conflict identifiers are not affected: to parse conflict hunks, rerere looks for whitespace after the ||||||| marker rather than a newline, and to compute preimage ids, rerere has its own code for creating conflict hunks. No other code in git tries to parse conflict hunks. Requested-by: Stefan Monnier <monnier@iro.umontreal.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20ll_merge(): add ancestor label parameter for diff3-style outputLibravatar Jonathan Nieder1-1/+1
Commands using the ll_merge() function will present conflict hunks imitating ‘diff3 -m’ output if the merge.conflictstyle configuration option is set appropriately. Unlike ‘diff3 -m’, the output does not include a label for the merge base on the ||||||| line of the output, and some tools misparse the conflict hunks without that. Add a new ancestor_label parameter to ll_merge() to give callers the power to rectify this situation. If ancestor_label is NULL, the output format is unchanged. All callers pass NULL for now. Requested-by: Stefan Monnier <monnier@iro.umontreal.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-10Merge branch 'lt/deepen-builtin-source'Libravatar Junio C Hamano1-0/+835
* lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+853
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>