summaryrefslogtreecommitdiff
path: root/builtin/commit.c
AgeCommit message (Collapse)AuthorFilesLines
2017-05-18interpret-trailers: honor the cut lineLibravatar Brian Malehorn1-1/+1
If a commit message is edited with the "verbose" option, the buffer will have a cut line and diff after the log message, like so: my subject # ------------------------ >8 ------------------------ # Do not touch the line above. # Everything below will be removed. diff --git a/foo.txt b/foo.txt index 5716ca5..7601807 100644 --- a/foo.txt +++ b/foo.txt @@ -1 +1 @@ -bar +baz "git interpret-trailers" is unaware of the cut line, and assumes the trailer block would be at the end of the whole thing. This can easily be seen with: $ GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \ git commit --amend -v Teach "git interpret-trailers" to notice the cut-line and ignore the remainder of the input when looking for a place to add new trailer block. This makes it consistent with how "git commit -v -s" inserts a new Signed-off-by: line. This can be done by the same logic as the existing helper function, wt_status_truncate_message_at_cut_line(), uses, but it wants the caller to pass a strbuf to it. Because the function ignore_non_trailer() used by the command takes a <pointer, length> pair, not a strbuf, steal the logic from wt_status_truncate_message_at_cut_line() to create a new wt_status_locate_end() helper function that takes <pointer, length> pair, and make ignore_non_trailer() call it to help "interpret-trailers". Since there is only one caller of wt_status_truncate_message_at_cut_line() in cmd_commit(), rewrite it to call wt_status_locate_end() helper instead and remove the old helper that no longer has any caller. Signed-off-by: Brian Malehorn <bmalehorn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-26Merge branch 'jk/war-on-git-path'Libravatar Junio C Hamano1-3/+3
While handy, "git_path()" is a dangerous function to use as a callsite that uses it safely one day can be broken by changes to other code that calls it. Reduction of its use continues. * jk/war-on-git-path: am: drop "dir" parameter from am_state_init replace strbuf_addstr(git_path()) with git_path_buf() replace xstrdup(git_path(...)) with git_pathdup(...) use git_path_* helper functions branch: add edit_description() helper bisect: add git_path_bisect_terms helper
2017-04-23Merge branch 'nd/conditional-config-include'Libravatar Junio C Hamano1-1/+1
$GIT_DIR may in some cases be normalized with all symlinks resolved while "gitdir" path expansion in the pattern does not receive the same treatment, leading to incorrect mismatch. This has been fixed. * nd/conditional-config-include: config: resolve symlinks in conditional include's patterns path.c: and an option to call real_path() in expand_user_path()
2017-04-20use git_path_* helper functionsLibravatar Jeff King1-3/+3
Long ago we added functions like git_path_merge_msg() to replace the more dangerous git_path("MERGE_MSG"). Over time some new calls to the latter have crept it. Let's convert them to use the safer form. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-14path.c: and an option to call real_path() in expand_user_path()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
In the next patch we need the ability to expand '~' to real_path($HOME). But we can't do that from outside because '~' is part of a pattern, not a true path. Add an option to expand_user_path() to do so. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20builtin/commit: convert to struct object_idLibravatar brian m. carlson1-23/+23
Convert most leaf functions to use struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31builtin/commit.c: switch to strbuf, instead of snprintf()Libravatar Elia Pinto1-6/+4
Switch to dynamic allocation with strbuf, so we can avoid dealing with magic numbers in the code and reduce the cognitive burden from the programmers. The original code is correct, but programmers no longer have to count bytes needed for static allocation to know that. As a side effect of this change, we also reduce the snprintf() calls, that may silently truncate results if the programmer is not careful. Helped-by: René Scharfe <l.s.r@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13builtin/commit.c: remove the PATH_MAX limitation via dynamic allocationLibravatar Elia Pinto1-11/+10
Remove the PATH_MAX limitation from the environment setting that points to a filename by switching to dynamic allocation. As a side effect of this change, we also reduce the snprintf() calls, that may silently truncate results if the programmer is not careful. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'jc/lock-report-on-error'Libravatar Junio C Hamano1-4/+4
Git 2.11 had a minor regression in "merge --ff-only" that competed with another process that simultanously attempted to update the index. We used to explain what went wrong with an error message, but the new code silently failed. The error message has been resurrected. * jc/lock-report-on-error: lockfile: LOCK_REPORT_ON_ERROR hold_locked_index(): align error handling with hold_lockfile_for_update() wt-status: implement opportunisitc index update correctly
2016-12-19Merge branch 'ak/commit-only-allow-empty'Libravatar Junio C Hamano1-3/+1
"git commit --allow-empty --only" (no pathspec) with dirty index ought to be an acceptable way to create a new commit that does not change any paths, but it was forbidden, perhaps because nobody needed it so far. * ak/commit-only-allow-empty: commit: remove 'Clever' message for --only --amend commit: make --only --allow-empty work without paths
2016-12-09commit: remove 'Clever' message for --only --amendLibravatar Andreas Krey1-2/+0
The behavior is now documented; more importantly, rewarding the user with a "Wow, you are clever" praise afterwards is not an effective way to advertise the feature--at that point the user already knows. Signed-off-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-07hold_locked_index(): align error handling with hold_lockfile_for_update()Libravatar Junio C Hamano1-4/+4
Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.
2016-12-05commit: make --only --allow-empty work without pathsLibravatar Andreas Krey1-1/+1
--only is implied when paths are present, and required them unless --amend. But with --allow-empty it should be allowed as well - it is the only way to create an empty commit in the presence of staged changes. Signed-off-by: Andreas Krey <a.krey@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29commit: make ignore_non_trailer take buf/lenLibravatar Jonathan Tan1-1/+1
Make ignore_non_trailer take a buf/len pair instead of struct strbuf. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-31Merge branch 'rs/commit-pptr-simplify'Libravatar Junio C Hamano1-8/+6
Code simplification. * rs/commit-pptr-simplify: commit: simplify building parents list
2016-10-30commit: simplify building parents listLibravatar René Scharfe1-8/+6
Push pptr down into the FROM_MERGE branch of the if/else statement, where it's actually used, and call commit_list_append() for appending elements instead of playing tricks with commit_list_insert(). Call copy_commit_list() in the amend branch instead of open-coding it. Don't bother setting pptr in the final branch as it's not used thereafter. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-27Merge branch 'nd/ita-empty-commit'Libravatar Junio C Hamano1-4/+9
When new paths were added by "git add -N" to the index, it was enough to circumvent the check by "git commit" to refrain from making an empty commit without "--allow-empty". The same logic prevented "git status" to show such a path as "new file" in the "Changes not staged for commit" section. * nd/ita-empty-commit: commit: don't be fooled by ita entries when creating initial commit commit: fix empty commit creation when there's no changes but ita entries diff: add --ita-[in]visible-in-index diff-lib: allow ita entries treated as "not yet exist in index"
2016-10-24commit: don't be fooled by ita entries when creating initial commitLibravatar Nguyễn Thái Ngọc Duy1-3/+8
ita entries are dropped at tree generation phase. If the entire index consists of just ita entries, the result would be a a commit with no entries, which should be caught unless --allow-empty is specified. The test "!!active_nr" is not sufficient to catch this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24commit: fix empty commit creation when there's no changes but ita entriesLibravatar Nguyễn Thái Ngọc Duy1-1/+1
If i-t-a entries are present and there is no change between the index and HEAD i-t-a entries, index_differs_from() still returns "dirty, new entries" (aka, the resulting commit is not empty), but cache-tree will skip i-t-a entries and produce the exact same tree of current commit. index_differs_from() is supposed to catch this so we can abort git-commit (unless --no-empty is specified). Update it to optionally ignore i-t-a entries when doing a diff between the index and HEAD so that it would return "no change" in this case and abort commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17sequencer: use memoized sequencer directory pathLibravatar Johannes Schindelin1-1/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'tg/add-chmod+x-fix'Libravatar Junio C Hamano1-1/+1
"git add --chmod=+x <pathspec>" added recently only toggled the executable bit for paths that are either new or modified. This has been corrected to flip the executable bit for all paths that match the given pathspec. * tg/add-chmod+x-fix: t3700-add: do not check working tree file mode without POSIXPERM t3700-add: create subdirectory gently add: modify already added files when --chmod is given read-cache: introduce chmod_index_entry update-index: add test for chmod flags
2016-09-15add: modify already added files when --chmod is givenLibravatar Thomas Gummerer1-1/+1
When the chmod option was added to git add, it was hooked up to the diff machinery, meaning that it only works when the version in the index differs from the version on disk. As the option was supposed to mirror the chmod option in update-index, which always changes the mode in the index, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-08Merge branch 'jh/status-v2-porcelain'Libravatar Junio C Hamano1-44/+34
Enhance "git status --porcelain" output by collecting more data on the state of the index and the working tree files, which may further be used to teach git-prompt (in contrib/) to make fewer calls to git. * jh/status-v2-porcelain: status: unit tests for --porcelain=v2 test-lib-functions.sh: add lf_to_nul helper git-status.txt: describe --porcelain=v2 format status: print branch info with --porcelain=v2 --branch status: print per-file porcelain v2 status data status: collect per-file data for --porcelain=v2 status: support --porcelain[=<version>] status: cleanup API to wt_status_print status: rename long-format print routines
2016-08-11status: print branch info with --porcelain=v2 --branchLibravatar Jeff Hostetler1-0/+5
Expand porcelain v2 output to include branch and tracking branch information. This includes the commit id, the branch, the upstream branch, and the ahead and behind counts. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11status: collect per-file data for --porcelain=v2Libravatar Jeff Hostetler1-0/+3
Collect extra per-file data for porcelain V2 format. The output of `git status --porcelain` leaves out many details about the current status that clients might like to have. This can force them to be less efficient as they may need to launch secondary commands (and try to match the logic within git) to accumulate this extra information. For example, a GUI IDE might want the file mode to display the correct icon for a changed item (without having to stat it afterwards). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10Merge branch 'os/no-verify-skips-commit-msg-too' into maintLibravatar Junio C Hamano1-1/+1
"git commit --help" said "--no-verify" is only about skipping the pre-commit hook, and failed to say that it also skipped the commit-msg hook. * os/no-verify-skips-commit-msg-too: commit: describe that --no-verify skips the commit-msg hook in the help text
2016-08-08Merge branch 'pb/commit-editmsg-path' into maintLibravatar Junio C Hamano1-7/+8
Code clean-up. * pb/commit-editmsg-path: builtin/commit.c: memoize git-path for COMMIT_EDITMSG
2016-08-05status: support --porcelain[=<version>]Libravatar Jeff Hostetler1-3/+18
Update --porcelain argument to take optional version parameter to allow multiple porcelain formats to be supported in the future. The token "v1" is the default value and indicates the traditional porcelain format. (The token "1" is an alias for that.) Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05status: cleanup API to wt_status_printLibravatar Jeff Hostetler1-42/+9
Refactor the API between builtin/commit.c and wt-status.[ch]. Hide the details of the various wt_*status_print() routines inside wt-status.c behind a single (new) wt_status_print() routine. Eliminate the switch statements from builtin/commit.c. Allow details of new status formats to be isolated within wt-status.c Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05status: rename long-format print routinesLibravatar Jeff Hostetler1-2/+2
Rename the various wt_status_print*() routines to be wt_longstatus_print*() to make it clear that these routines are only concerned with the normal/long status output and reduce developer confusion as other status formats are added in the future. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-03Merge branch 'os/no-verify-skips-commit-msg-too'Libravatar Junio C Hamano1-1/+1
"git commit --help" said "--no-verify" is only about skipping the pre-commit hook, and failed to say that it also skipped the commit-msg hook. * os/no-verify-skips-commit-msg-too: commit: describe that --no-verify skips the commit-msg hook in the help text
2016-07-28Merge branch 'js/find-commit-subject-ignore-leading-blanks' into maintLibravatar Junio C Hamano1-1/+1
A helper function that takes the contents of a commit object and finds its subject line did not ignore leading blank lines, as is commonly done by other codepaths. Make it ignore leading blank lines to match. * js/find-commit-subject-ignore-leading-blanks: reset --hard: skip blank lines when reporting the commit subject sequencer: use skip_blank_lines() to find the commit subject commit -C: skip blank lines at the beginning of the message commit.c: make find_commit_subject() more robust pretty: make the skip_blank_lines() function public
2016-07-26commit: describe that --no-verify skips the commit-msg hook in the help textLibravatar Orgad Shaneh1-1/+1
This brings the short help in line with the documentation. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11Merge branch 'js/find-commit-subject-ignore-leading-blanks'Libravatar Junio C Hamano1-1/+1
A helper function that takes the contents of a commit object and finds its subject line did not ignore leading blank lines, as is commonly done by other codepaths. Make it ignore leading blank lines to match. * js/find-commit-subject-ignore-leading-blanks: reset --hard: skip blank lines when reporting the commit subject sequencer: use skip_blank_lines() to find the commit subject commit -C: skip blank lines at the beginning of the message commit.c: make find_commit_subject() more robust pretty: make the skip_blank_lines() function public
2016-07-06Merge branch 'pb/commit-editmsg-path'Libravatar Junio C Hamano1-7/+8
Code clean-up. * pb/commit-editmsg-path: builtin/commit.c: memoize git-path for COMMIT_EDITMSG
2016-06-29commit -C: skip blank lines at the beginning of the messageLibravatar Johannes Schindelin1-1/+1
Consistent with the pretty-printing machinery, we skip leading blank lines (if any) of existing commit messages. While Git itself only produces commit objects with a single empty line between commit header and commit message, it is legal to have more than one blank line (i.e. lines containing only white space, or no characters) at the beginning of the commit message, and the pretty-printing code already handles that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-09builtin/commit.c: memoize git-path for COMMIT_EDITMSGLibravatar Pranit Bauva1-7/+8
This is a follow up commit for f932729c (memoize common git-path "constant" files, 10-Aug-2015). The many function calls to git_path() are replaced by git_path_commit_editmsg() and which thus eliminates the need to repeatedly compute the location of "COMMIT_EDITMSG". Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-07add: add --chmod=+x / --chmod=-x optionsLibravatar Edward Thomson1-1/+1
The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-23Merge branch 'pb/commit-verbose-config'Libravatar Junio C Hamano1-0/+10
"git commit" learned to pay attention to "commit.verbose" configuration variable and act as if "--verbose" option was given from the command line. * pb/commit-verbose-config: commit: add a commit.verbose config variable t7507-commit-verbose: improve test coverage by testing number of diffs parse-options.c: make OPTION_COUNTUP respect "unspecified" values t/t7507: improve test coverage t0040-parse-options: improve test coverage test-parse-options: print quiet as integer t0040-test-parse-options.sh: fix style issues
2016-05-10commit: add a commit.verbose config variableLibravatar Pranit Bauva1-0/+10
Add commit.verbose configuration variable as a convenience for those who always prefer --verbose. Add tests to check the behavior introduced by this commit and also to verify that behavior of status doesn't break because of this commit. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-02Merge branch 'ad/commit-have-m-option' into maintLibravatar Junio C Hamano1-3/+3
"git commit" misbehaved in a few minor ways when an empty message is given via -m '', all of which has been corrected. * ad/commit-have-m-option: commit: do not ignore an empty message given by -m '' commit: --amend -m '' silently fails to wipe message
2016-04-22Merge branch 'ad/commit-have-m-option'Libravatar Junio C Hamano1-3/+3
"git commit" misbehaved in a few minor ways when an empty message is given via -m '', all of which has been corrected. * ad/commit-have-m-option: commit: do not ignore an empty message given by -m '' commit: --amend -m '' silently fails to wipe message
2016-04-14Merge branch 'ss/commit-squash-msg' into maintLibravatar Junio C Hamano1-1/+10
When "git merge --squash" stopped due to conflict, the concluding "git commit" failed to read in the SQUASH_MSG that shows the log messages from all the squashed commits. * ss/commit-squash-msg: commit: do not lose SQUASH_MSG contents
2016-04-07commit: do not ignore an empty message given by -m ''Libravatar Jeff King1-3/+3
When f9568530 (builtin-commit: resurrect behavior for multiple -m options, 2007-11-11) converted a "char *message" to "struct strbuf message" to hold the messages given with the "-m" option, it incorrectly changed the checks "did we get a message with the -m option?" to "is message.len 0?". Later, we noticed one breakage from this change and corrected it with 25206778 (commit: don't start editor if empty message is given with -m, 2013-05-25). However, "we got a message with -m, even though an empty one, so we shouldn't be launching an editor" was not the only breakage. * "git commit --amend -m '' --allow-empty", even though it looks strange, is a valid request to amend the commit to have no message at all. Due to the misdetection of the presence of -m on the command line, we ended up keeping the log messsage from the original commit. * "git commit -m "$msg" -F file" should be rejected whether $msg is an empty string or not, but due to the same bug, was not rejected when $msg is empty. * "git -c template=file -m "$msg"" should ignore the template even when $msg is empty, but it didn't and instead used the contents from the template file. Correct these by checking have_option_m, which the earlier 25206778 introduced to fix the same bug. Reported-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Merge branch 'ss/commit-squash-msg'Libravatar Junio C Hamano1-1/+10
When "git merge --squash" stopped due to conflict, the concluding "git commit" failed to read in the SQUASH_MSG that shows the log messages from all the squashed commits. * ss/commit-squash-msg: commit: do not lose SQUASH_MSG contents
2016-03-21commit: do not lose SQUASH_MSG contentsLibravatar Sven Strickroth1-1/+10
When concluding a conflicted "git merge --squash", the command failed to read SQUASH_MSG that was prepared by "git merge", and showed only the "# Conflicts:" list of conflicted paths. Place the contents from SQUASH_MSG at the beginning, just like we show the commit log skeleton first when concluding a normal merge, and then show the "# Conflicts:" list, to help the user write the log message for the resulting commit. Test by Junio C Hamano <gitster@pobox.com>. Signed-off-by: Sven Strickroth <sven@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25diff: activate diff.renames by defaultLibravatar Matthieu Moy1-0/+1
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28Merge branch 'jc/strbuf-getline'Libravatar Junio C Hamano1-1/+1
The preliminary clean-up for jc/peace-with-crlf topic. * jc/strbuf-getline: strbuf: give strbuf_getline() to the "most text friendly" variant checkout-index: there are only two possible line terminations update-index: there are only two possible line terminations check-ignore: there are only two possible line terminations check-attr: there are only two possible line terminations mktree: there are only two possible line terminations strbuf: introduce strbuf_getline_{lf,nul}() strbuf: make strbuf_getline_crlf() global strbuf: miniscule style fix
2016-01-20Merge branch 'js/fopen-harder'Libravatar Junio C Hamano1-1/+1
Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR (e.g. COMMIT_EDITMSG) that is meant to be left after the command is done. This however did not work well if the repository is set to be shared with core.sharedRepository and the umask of the previous user is tighter. They have been made to work better by calling unlink(2) and retrying after fopen(3) fails with EPERM. * js/fopen-harder: Handle more file writes correctly in shared repos commit: allow editing the commit message even in shared repos
2016-01-15strbuf: introduce strbuf_getline_{lf,nul}()Libravatar Junio C Hamano1-1/+1
The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano <gitster@pobox.com>