kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Ævar Arnfjörð Bjarmason	ef7a8e3b95	notes: Initialize variable to appease Sun Studio Sun Studio 12 Update 1 thinks that *t could be uninitialized, ostensibly because it doesn't take rewrite_cmd into account in its static analysis. builtin/notes.c: In function `notes_copy_from_stdin': builtin/notes.c:419: warning: 't' might be used uninitialized in this function Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tor Arntsen	2543d9b609	Change C99 comments to old-style C comments Signed-off-by: Tor Arntsen <tor@spacetec.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	bd7440fe1b	show-branch: use DEFAULT_ABBREV instead of 7 Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jeff King	87a074df24	handle "git --bare init <dir>" properly If we know we are creating a bare repository, we use setenv to set the GIT_DIR directory to the current directory (either where we already were, or one we created and chdir'd into with "git init --bare <dir>"). However, with "git --bare init <dir>" (note the --bare as a git wrapper option), the setup code actually sets GIT_DIR for us, but it uses the wrong, original cwd when a directory is given. Because our setenv does not use the overwrite flag, it is ignored. We need to set the overwrite flag, but only when we are given a directory on the command line. That still allows: GIT_DIR=foo.git git init --bare to work. The behavior is changed for: GIT_DIR=foo.git git init --bare bar.git which used to create the repository in foo.git, but now will use bar.git. This is more sane, as command line options should generally override the environment. Noticed by Oliver Hoffmann. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Pete Harlan	921eabde9d	clone: reword messages to match the end-user perception When cloning into a non-bare repository, e.g. "git clone $URL mine", we used to report that we are cloning into "mine/.git". Reword the report to say "Cloning into mine" instead, as that matches what the end-user asked for closer. Make the message for "git clone --bare $URL mine" to say "Cloning into bare repository mine" do make the distinction between this case and the above stand out a bit more prominently. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Pete Harlan <pgit@pcharlan.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	43acff34b9	cherry-pick: do not dump core when iconv fails When cherry-picking, usually the new and old commit encodings are both UTF-8. Most old iconv implementations do not support this trivial conversion, so on old platforms, out->message remains NULL, and later attempts to read it segfault. Fix this by noticing the input and output encodings match and skipping the iconv step, like the other reencode_string() call sites already do. Also stop segfaulting on other iconv failures: if iconv fails for some other reason, the best we can do is to pass the old message through. This fixes a regression introduced in v1.7.1-rc0~15^2~2 (revert: clarify label on conflict hunks, 2010-03-20). Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	fb7749e4e4	commit --amend: cope with missing display name Though I have not seen this in the wild, it has been said that there are likely to be git repositories converted from other version control systems with an invalid ident line like this one: author <user@example.com> 18746342 +0000 Because there is no space between the (empty) user name and the email address, commit --amend chokes. When searching for a space-left-bracket sequence on the ident line, it finds it in the committer line, ending up utterly confused. Better for commit --amend to treat this like a valid ident line with empty username and complain. The tests remove the questionable commit objects after use so there is no chance for them to confuse later tests. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	28ba96ab27	clone: quell the progress report from init and report on clone Currently, a local git clone reports only initializing an empty git dir, which is potentially confusing. Instead, report that cloning is in progress and when it is done (unless -q) is given, and suppress the init report. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	a6ccbbdb66	tag -v: use RUN_GIT_CMD to run verify-tag This is the preferred way to run a git command. The only obvious observable effects I can think of are that the exec is properly reported in GIT_TRACE output and that verifying signed tags will still work if the git-verify-tag hard link in gitexecdir goes missing. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Johannes Gilger	5b16360330	pretty: Initialize notes if %N is used When using git log --pretty='%N' without an explicit --show-notes, git would segfault. This patches fixes this behaviour by loading the needed notes datastructures if --pretty is used and the format contains %N. When --pretty='%N' is used together with --no-notes, %N won't be expanded. This is an extension to a proposed patch by Jeff King. Signed-off-by: Johannes Gilger <heipei@hackvalue.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	9974e290e7	Teach mailinfo %< as an alternative scissors mark Handle perforations found “in the wild” more robustly by recognizing “%<” as an alternative scissors mark. This feature is only meant to support old habits. Discourage new use of the percent-based version by only documenting the 8< symbol so new users’ perforations can still be recognized by old versions of Git. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Markus Heidelberg	4bb6644d03	git status: refresh the index if possible This was already the case before commit `9e4b7ab6` (git status: not "commit --dry-run" anymore, 2009-08-15) with the difference that it died at failure. It got lost during the new implementation of "git status", which was meant to only change behaviour when invoked with arguments. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Markus Heidelberg	1f2362a944	builtin/commit: remove unnecessary variable definition The file descriptor is already defined at the beginning of the function. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Markus Heidelberg	7327623526	builtin/commit: fix duplicated sentence in a comment Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Peter Collingbourne	80d706afed	Introduce remove_or_warn function This patch introduces the remove_or_warn function which is a generalised version of the {unlink,rmdir}_or_warn functions. It takes an additional parameter indicating the mode of the file to be removed. The patch also modifies certain functions to use remove_or_warn where appropriate, and adds a test case for a bug fixed by the use of remove_or_warn. Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	63e6715087	fmt-merge-msg: hide summary option The --summary command line option has been deprecated in favor of --log. Hide the option from the help message to further discourage the use of this option. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	fcb243f7db	fmt-merge-msg: remove custom string_list implementation This command uses a custom version of string list when it could just as easily use the string_list API. Convert it to use string_list and reduce the code size a bit. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	15cb500786	fmt-merge-msg: use pretty.c routines This command duplicates functionality of the '%s' pretty format. Simplify the code a bit by using the pretty printing routine instead of open-coding it here. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	419fe5bc86	fmt-merge-msg: be quiet if nothing to merge When FETCH_HEAD contains only 'not-for-merge' entries fmt-merge-msg still outputs "Merge" (and if the branch isn't master " into <branch>"). In this case fmt-merge-msg is outputting junk and should really just be quiet. Fix it. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Erik Faye-Lund	531e758d9c	ls: remove redundant logic find_unique_abbrev() already returns the full SHA-1 if abbrev = 0, so we can remove the logic that avoids the call. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Erik Faye-Lund	28a53178fc	cherry: support --abbrev option Switch to parse-options API while we're at it. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	bf975d379d	cherry-pick, revert: add a label for ancestor When writing conflict hunks in ‘diff3 -m’ format, also add a label to the common ancestor. Especially in a cherry-pick, it is not immediately obvious without such a label what the common ancestor represents. git rerere does not have trouble parsing the new output and its preimage ids are unchanged since it includes its own code for recreating conflict hunks. No other code in git parses 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>	15 years ago
Jonathan Nieder	d68565402a	revert: clarify label on conflict hunks When reverting a commit, the commit being merged is not the commit to revert itself but its parent. Add “parent of” to the conflict hunk label to make this more clear. The conflict hunk labels are all pieces of a single string written in the new get_message() function. Avoid some complication by using mempcpy to advance a pointer as the result is written. Also free the corresponding temporary buffer (it was leaked before). This is not important because it is a small one-time allocation. It would become a memory leak if unnoticed when libifying revert. This patch uses calls to strlen() instead of integer constants in some places. GCC will compute the length at compile time; I am not sure about other compilers, but this is not performance-critical anyway. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	c4151629e7	checkout -m --conflict=diff3: add a label for ancestor 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>	15 years ago
Jonathan Nieder	f0531a2937	checkout --conflict=diff3: add a label for ancestor 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>	15 years ago
Jonathan Nieder	f01de62e45	ll_merge(): add ancestor label parameter for diff3-style output 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>	15 years ago
Jonathan Nieder	4bb0936206	merge-file --diff3: add a label for ancestor git merge-file --diff3 can be used to present conflicts hunks including text from the common ancestor. The added information is helpful for resolving a merge by hand, and merge tools can usually grok it because it looks like output from diff3 -m. However, ‘diff3’ includes a label for the merge base on the \|\|\|\|\|\|\| line and some tools cannot parse conflict hunks without such a label. Write the base-name as passed in a -L option (or the name of the ancestor file by default) on that line. git rerere will not have trouble parsing this output, since instead of looking for a newline, it looks for whitespace after the \|\|\|\|\|\|\| marker. Since rerere includes its own code for recreating conflict hunks, conflict identifiers are unaffected. 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>	15 years ago
Jonathan Nieder	a4b5e91c49	xdl_merge(): move file1 and file2 labels to xmparam structure The labels for the three participants in a potential conflict are all optional arguments for the xdiff merge routine; if they are NULL, then xdl_merge() can cope by omitting the labels from its output. Move them to the xmparam structure to allow new callers to save some keystrokes where they are not needed. This also has the virtue of making the xdiff merge interface more similar to merge_trees, which might make it easier to learn. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
René Scharfe	431d6e7bc8	grep: enable threading for context line printing If context lines are to be printed, grep separates them with hunk marks ("--\n"). These marks are printed between matches from different files, too. They are not printed before the first file, though. Threading was disabled when context line printing was enabled because avoiding to print the mark before the first line was an unsolved synchronisation problem. This patch separates the code for printing hunk marks for the threaded and the unthreaded case, allowing threading to be turned on together with the common -ABC options. ->show_hunk_mark, which controls printing of hunk marks between files in show_line(), is now set in grep_buffer_1(), but only if some results have already been printed and threading is disabled. The threaded case is handled in work_done(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Linus Torvalds	81b50f3ce4	Move 'builtin-' into a 'builtin/' subdirectory 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>	15 years ago

1 2

72 Commits (958ff4a5973c9858c36c405c2f593cf5172e5e1c)