summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2010-08-06ll-merge: let caller decide whether to renormalizeLibravatar Jonathan Nieder1-0/+4
Add a “renormalize” bit to the ll-merge options word so callers can decide on a case-by-case basis whether the merge is likely to have overlapped with a change in smudge/clean rules. This reveals a few commands that have not been taking that situation into account, though it does not fix them. No functional change intended. Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'gv/portable'Libravatar Junio C Hamano1-1/+2
* gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
2010-06-12log_ref_setup: don't return stack-allocated arrayLibravatar Thomas Rast1-2/+2
859c301 (refs: split log_ref_write logic into log_ref_setup, 2010-05-21) refactors the stack allocation of the log_file array into the new log_ref_setup() function, but passes it back to the caller. Since the original intent seems to have been to split the work between log_ref_setup and log_ref_write, make it the caller's responsibility to allocate the buffer. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-03checkout --orphan: respect -l option alwaysLibravatar Erick Mattos1-3/+28
Added changes to satisfy a corner case: creating reflogs by using -l when core.logAllRefUpdates is set to false. Signed-off-by: Erick Mattos <erick.mattos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31Rewrite dynamic structure initializations to runtime assignmentLibravatar Gary V. Vaughan1-1/+2
Unfortunately, there are still plenty of production systems with vendor compilers that choke unless all compound declarations can be determined statically at compile time, for example hpux10.20 (I can provide a comprehensive list of our supported platforms that exhibit this problem if necessary). This patch simply breaks apart any compound declarations with dynamic initialisation expressions, and moves the initialisation until after the last declaration in the same block, in all the places necessary to have the offending compilers accept the code. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'em/checkout-orphan'Libravatar Junio C Hamano1-2/+13
* em/checkout-orphan: git checkout: create unparented branch by --orphan
2010-03-21git checkout: create unparented branch by --orphanLibravatar Erick Mattos1-2/+13
Similar to -b, --orphan creates a new branch, but it starts without any commit. After running "git checkout --orphan newbranch", you are on a new branch "newbranch", and the first commit you create from this state will start a new history without any ancestry. "git checkout --orphan" keeps the index and the working tree files intact in order to make it convenient for creating a new history whose trees resemble the ones from the original branch. When creating a branch whose trees have no resemblance to the ones from the original branch, it may be easier to start work on the new branch by untracking and removing all working tree files that came from the original branch, by running a 'git rm -rf .' immediately after running "checkout --orphan". Signed-off-by: Erick Mattos <erick.mattos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>