summaryrefslogtreecommitdiff
path: root/builtin/merge.c
AgeCommit message (Collapse)AuthorFilesLines
2012-02-23merge: do not trust fstat(2) too much when checking interactivenessLibravatar Junio C Hamano1-1/+1
The heuristic used by "git merge" to decide if it automatically gives an editor upon clean automerge is to see if the standard input and the standard output is the same device and is a tty, we are in an interactive session. "The same device" test was done by comparing fstat(2) result on the two file descriptors (and they must match), and we asked isatty() only for the standard input (we insist that they are the same device and there is no point asking tty-ness of the standard output). The stat(2) emulation in the Windows port however does not give a usable value in the st_ino field, so even if the standard output is connected to something different from the standard input, "The same device" test may incorrectly return true. To accomodate it, add another isatty() check for the standard output stream as well. Reported-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-12Merge branch 'jn/merge-no-edit-fix'Libravatar Junio C Hamano1-1/+2
* jn/merge-no-edit-fix: merge: do not launch an editor on "--no-edit $tag" Conflicts: builtin/merge.c
2012-02-10Merge branch 'jc/merge-ff-only-stronger-than-signed-merge'Libravatar Junio C Hamano1-1/+2
* jc/merge-ff-only-stronger-than-signed-merge: merge: do not create a signed tag merge under --ff-only option
2012-02-09merge: do not launch an editor on "--no-edit $tag"Libravatar Junio C Hamano1-3/+7
When the user explicitly asked us not to, don't launch an editor. But do everything else the same way as the "edit" case, i.e. leave the comment with verification result in the log template and record the mergesig in the resulting merge commit for later inspection. Based on initiail analysis by Jonathan Nieder. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05merge: do not create a signed tag merge under --ff-only optionLibravatar Junio C Hamano1-1/+2
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-31Merge branch 'tr/merge-edit-guidance'Libravatar Junio C Hamano1-0/+10
* tr/merge-edit-guidance: merge: add instructions to the commit message when editing
2012-01-31Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-4/+34
* jc/pull-signed-tag: merge: use editor by default in interactive sessions Conflicts: Documentation/merge-options.txt
2012-01-31merge: add instructions to the commit message when editingLibravatar Thomas Rast1-0/+10
Before f824628 (merge: use editor by default in interactive sessions, 2012-01-10), git-merge only started an editor if the user explicitly asked for it with --edit. Thus it seemed unlikely that the user would need extra guidance. After f824628 the _normal_ thing is to start an editor. Give at least an indication of why we are doing it. The sentence about justification is one of the few things about standard git that are not agnostic to the workflow that the user chose. However, f824628 was proposed by Linus specifically to discourage users from merging unrelated upstream progress into topic branches. So we may as well take another step in the same direction. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23merge: use editor by default in interactive sessionsLibravatar Junio C Hamano1-4/+34
Traditionally, a cleanly resolved merge was committed by "git merge" using the auto-generated merge commit log message without invoking the editor. After 5 years of use in the field, it turns out that people perform too many unjustified merges of the upstream history into their topic branches. These merges are not just useless, but they are often not explained well, and making the end result unreadable when it gets time for merging their history back to their upstream. Earlier we added the "--edit" option to the command, so that people can edit the log message to explain and justify their merge commits. Let's take it one step further and spawn the editor by default when we are in an interactive session (i.e. the standard input and the standard output are pointing at the same tty device). There may be existing scripts that leave the standard input and the standard output of the "git merge" connected to whatever environment the scripts were started, and such invocation might trigger the above "interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable can be set to "no" at the beginning of such scripts to use the historical behaviour while the script runs. Note that this backward compatibility is meant only for scripts, and we deliberately do *not* support "merge.edit = yes/no/auto" configuration option to allow people to keep the historical behaviour. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jc/show-sig'Libravatar Junio C Hamano1-2/+12
* jc/show-sig: log --show-signature: reword the common two-head merge case log-tree: show mergetag in log --show-signature output log-tree.c: small refactor in show_signature() commit --amend -S: strip existing gpgsig headers verify_signed_buffer: fix stale comment gpg-interface: allow use of a custom GPG binary pretty: %G[?GS] placeholders test "commit -S" and "log --show-signature" log: --show-signature commit: teach --gpg-sign option Conflicts: builtin/commit-tree.c builtin/commit.c builtin/merge.c notes-cache.c pretty.c
2011-12-22Merge branch 'jk/maint-strbuf-missing-init'Libravatar Junio C Hamano1-1/+1
* jk/maint-strbuf-missing-init: commit, merge: initialize static strbuf Conflicts: builtin/merge.c
2011-12-22Merge branch 'nd/war-on-nul-in-commit'Libravatar Junio C Hamano1-2/+4
* nd/war-on-nul-in-commit: commit_tree(): refuse commit messages that contain NULs Convert commit_tree() to take strbuf as message merge: abort if fails to commit Conflicts: builtin/commit.c commit.c commit.h
2011-12-19Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-7/+5
* nd/resolve-ref: Rename resolve_ref() to resolve_ref_unsafe() Convert resolve_ref+xstrdup to new resolve_refdup function revert: convert resolve_ref() to read_ref_full()
2011-12-18Update jk/maint-strbuf-missing-init to builtin/ renameLibravatar Junio C Hamano1-0/+1292
2011-12-15Convert commit_tree() to take strbuf as messageLibravatar Nguyễn Thái Ngọc Duy1-2/+2
There wan't a way for commit_tree() to notice if the message the caller prepared contained a NUL byte, as it did not take the length of the message as a parameter. Use a pointer to a strbuf instead, so that we can either choose to allow low-level plumbing commands to make commits that contain NUL byte in its message, or forbid NUL everywhere by adding the check in commit_tree(), in later patches. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15merge: abort if fails to commitLibravatar Nguyễn Thái Ngọc Duy1-2/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'nd/ignore-might-be-precious'Libravatar Junio C Hamano1-4/+8
* nd/ignore-might-be-precious: checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-7/+5
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-24/+41
* nd/resolve-ref: Copy resolve_ref() return value for longer use Convert many resolve_ref() calls to read_ref*() and ref_exists() Conflicts: builtin/fmt-merge-msg.c builtin/merge.c refs.c
2011-12-09Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-45/+50
* jc/pull-signed-tag: commit-tree: teach -m/-F options to read logs from elsewhere commit-tree: update the command line parsing commit: teach --amend to carry forward extra headers merge: force edit and no-ff mode when merging a tag object commit: copy merged signed tags to headers of merge commit merge: record tag objects without peeling in MERGE_HEAD merge: make usage of commit->util more extensible fmt-merge-msg: Add contents of merged tag in the merge message fmt-merge-msg: package options into a structure fmt-merge-msg: avoid early returns refs DWIMmery: use the same rule for both "git fetch" and others fetch: allow "git fetch $there v1.0" to fetch a tag merge: notice local merging of tags and keep it unwrapped fetch: do not store peeled tag object names in FETCH_HEAD Split GPG interface into its own helper library Conflicts: builtin/fmt-merge-msg.c builtin/merge.c
2011-12-09Merge branch 'jc/request-pull-show-head-4'Libravatar Junio C Hamano1-10/+10
* jc/request-pull-show-head-4: request-pull: use the annotated tag contents fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error environment.c: Fix an sparse "symbol not declared" warning builtin/log.c: Fix an "Using plain integer as NULL pointer" warning fmt-merge-msg: use branch.$name.description request-pull: use the branch description request-pull: state what commit to expect request-pull: modernize style branch: teach --edit-description option format-patch: use branch description in cover letter branch: add read_branch_desc() helper function Conflicts: builtin/branch.c
2011-12-05Copy resolve_ref() return value for longer useLibravatar Nguyễn Thái Ngọc Duy1-22/+40
resolve_ref() may return a pointer to a static buffer. Callers that use this value longer than a couple of statements should copy the value to avoid some hidden resolve_ref() call that may change the static buffer's value. The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c demonstrates this. The first call is in cmd_merge() branch = resolve_ref("HEAD", head_sha1, 0, &flag); Then deep in lookup_commit_or_die() a few lines after, resolve_ref() may be called again and destroy "branch". lookup_commit_or_die lookup_commit_reference lookup_commit_reference_gently parse_object lookup_replace_object do_lookup_replace_object prepare_replace_object for_each_replace_ref do_for_each_ref get_loose_refs get_ref_dir get_ref_dir resolve_ref All call sites are checked and made sure that xstrdup() is called if the value should be saved. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Merge branch 'nd/maint-ignore-exclude'Libravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-12-05Merge branch 'vr/git-merge-default-to-upstream'Libravatar Junio C Hamano1-3/+6
* vr/git-merge-default-to-upstream: Show error for 'git merge' with unset merge.defaultToUpstream
2011-11-28checkout,merge: disallow overwriting ignored files with --no-overwrite-ignoreLibravatar Nguyễn Thái Ngọc Duy1-4/+8
Ignored files usually are generated files (e.g. .o files) and can be safely discarded. However sometimes users may have important files in working directory, but still want a clean "git status", so they mark them as ignored files. But in this case, these files should not be overwritten without asking first. Enable this use case with --no-overwrite-ignore, where git only sees tracked and untracked files, no ignored files. Those who mix discardable ignored files with important ones may have to sort it out themselves. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-preciousLibravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-11-28checkout,merge: loosen overwriting untracked file check based on info/excludeLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Back in 1127148 (Loosen "working file will be lost" check in Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly overwrite ignored files. Howver the code only took .gitignore files into account. Standard ignored files include all specified in .gitignore files in working directory _and_ $GIT_DIR/info/exclude. This patch makes sure ignored files in info/exclude can also be overwritten automatically in the spirit of the original patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-21Show error for 'git merge' with unset merge.defaultToUpstreamLibravatar Vincent van Ravesteijn1-3/+6
'git merge' can be called without any arguments if merge.defaultToUpstream is set. However, when merge.defaultToUpstream is not set, the user will be presented the usage information as if he entered a command with a wrong syntaxis. Ironically, the usage information confirms that no arguments are mandatory. This adds a proper error message telling the user why the command failed. As a side-effect this can help the user in discovering the possibility to merge with the upstream branch by setting merge.defaultToUpstream. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-17do not let git_path clobber errno when reporting errorsLibravatar Jonathan Nieder1-20/+29
Because git_path() calls vsnprintf(), code like fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666); die_errno(_("Could not write to '%s'"), git_path("SQUASH_MSG")); can end up printing an error indicator from vsnprintf() instead of open() by mistake. Store the path we are trying to write to in a temporary variable and pass _that_ to die_errno(), so the messages written by git cherry-pick/revert and git merge can avoid this source of confusion. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-13Convert many resolve_ref() calls to read_ref*() and ref_exists()Libravatar Nguyễn Thái Ngọc Duy1-2/+2
resolve_ref() may return a pointer to a static buffer, which is not safe for long-term use because if another resolve_ref() call happens, the buffer may be changed. Many call sites though do not care about this buffer. They simply check if the return value is NULL or not. Convert all these call sites to new wrappers to reduce resolve_ref() calls from 57 to 34. If we change resolve_ref() prototype later on to avoid passing static buffer out, this helps reduce changes. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12commit: teach --gpg-sign optionLibravatar Junio C Hamano1-2/+14
This uses the gpg-interface.[ch] to allow signing the commit, i.e. $ git commit --gpg-sign -m foo You need a passphrase to unlock the secret key for user: "Junio C Hamano <gitster@pobox.com>" 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7) [master 8457d13] foo 1 files changed, 1 insertions(+), 0 deletions(-) The lines of GPG detached signature are placed in a new multi-line header field, instead of tucking the signature block at the end of the commit log message text (similar to how signed tag is done), for multiple reasons: - The signature won't clutter output from "git log" and friends if it is in the extra header. If we place it at the end of the log message, we would need to teach "git log" and friends to strip the signature block with an option. - Teaching new versions of "git log" and "gitk" to optionally verify and show signatures is cleaner if we structurally know where the signature block is (instead of scanning in the commit log message). - The signature needs to be stripped upon various commit rewriting operations, e.g. rebase, filter-branch, etc. They all already ignore unknown headers, but if we place signature in the log message, all of these tools (and third-party tools) also need to learn how a signature block would look like. - When we added the optional encoding header, all the tools (both in tree and third-party) that acts on the raw commit object should have been fixed to ignore headers they do not understand, so it is not like that new header would be more likely to break than extra text in the commit. A commit made with the above sample sequence would look like this: $ git cat-file commit HEAD tree 3cd71d90e3db4136e5260ab54599791c4f883b9d parent b87755351a47b09cb27d6913e6e0e17e6254a4d4 author Junio C Hamano <gitster@pobox.com> 1317862251 -0700 committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG ... =dt98 -----END PGP SIGNATURE----- foo but "git log" (unless you ask for it with --pretty=raw) output is not cluttered with the signature information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-09merge: force edit and no-ff mode when merging a tag objectLibravatar Junio C Hamano1-0/+6
Now that we allow pulling a tag from the remote site to validate the authenticity, we should give the user the final chance to verify and edit the merge message. The integrator is expected to leave a meaningful merge commit log in the history. Disallow fast-forwarding in such a case to ensure that a merge commit is always recorded. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: record tag objects without peeling in MERGE_HEADLibravatar Junio C Hamano1-3/+10
Otherwise, "git commit" wouldn't have a way to tell that we were in the middle of merging an annotated or signed tag, not a plain commit, after "git merge" stops to ask the user to resolve conflicts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: make usage of commit->util more extensibleLibravatar Junio C Hamano1-40/+23
The merge-recursive code uses the commit->util field directly to annotate the commit objects given from the command line, i.e. the remote heads to be merged, with a single string to be used to describe it in its trace messages and conflict markers. Correct this short-signtedness by redefining the field to be a pointer to a structure "struct merge_remote_desc" that later enhancements can add more information. Store the original objects we were told to merge in a field "obj" in this struct, so that we can recover the tag we were told to merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07fmt-merge-msg: package options into a structureLibravatar Junio C Hamano1-2/+6
This way new features can be added more easily Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07merge: notice local merging of tags and keep it unwrappedLibravatar Junio C Hamano1-0/+5
This also updates the autogenerated merge title message from "merge commit X" to "merge tag X", and its effect can be seen in the changes to the test suite. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'nd/maint-autofix-tag-in-head' into maintLibravatar Junio C Hamano1-56/+61
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c
2011-10-19Merge branch 'js/merge-edit-option'Libravatar Junio C Hamano1-39/+70
* js/merge-edit-option: Teach merge the '[-e|--edit]' option Conflicts: builtin/merge.c
2011-10-13Merge branch 'nd/maint-autofix-tag-in-head'Libravatar Junio C Hamano1-56/+61
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c
2011-10-12Teach merge the '[-e|--edit]' optionLibravatar Jay Soffian1-39/+70
Implemented internally instead of as "git merge --no-commit && git commit" so that "merge --edit" is otherwise consistent (hooks, etc) with "merge". Note: the edit message does not include the status information that one gets with "commit --status" and it is cleaned up after editing like one gets with "commit --cleanup=default". A later patch could add the status information if desired. Note: previously we were not calling stripspace() after running the prepare-commit-msg hook. Now we are, stripping comments and leading/trailing whitespace lines if --edit is given, otherwise only stripping leading/trailing whitespace lines if not given --edit. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fmt-merge-msg: use branch.$name.descriptionLibravatar Junio C Hamano1-10/+10
This teaches "merge --log" and fmt-merge-msg to use branch description information when merging a local topic branch into the mainline. The description goes between the branch name label and the list of commit titles. The refactoring to share the common configuration parsing between merge and fmt-merge-msg needs to be made into a separate patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'jc/want-commit'Libravatar Junio C Hamano1-5/+14
* jc/want-commit: Allow git merge ":/<pattern>"
2011-09-18Accept tags in HEAD or MERGE_HEADLibravatar Nguyễn Thái Ngọc Duy1-5/+2
HEAD and MERGE_HEAD (among other branch tips) should never hold a tag. That can only be caused by broken tools and is cumbersome to fix by an end user with: $ git update-ref HEAD $(git rev-parse HEAD^{commit}) which may look like a magic to a new person. Be easy, warn users (so broken tools can be fixed if they bother to report) and move on. Be robust, if the given SHA-1 cannot be resolved to a commit object, die (therefore return value is always valid). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-18merge: remove global variable head[]Libravatar Nguyễn Thái Ngọc Duy1-44/+53
Also kill head_invalid in favor of "head_commit == NULL". Local variable "head" in cmd_merge() is renamed to "head_sha1" to make sure I don't miss any access because this variable should not be used after head_commit is set (use head_commit->object.sha1 instead). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-18merge: use return value of resolve_ref() to determine if HEAD is invalidLibravatar Nguyễn Thái Ngọc Duy1-1/+1
resolve_ref() only updates "head" when it returns non NULL value (it may update "head" even when returning NULL, but not in all cases). Because "head" is not initialized before the call, is_null_sha1() is not enough. Check also resolve_ref() return value. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-15Allow git merge ":/<pattern>"Libravatar Junio C Hamano1-5/+14
It probably is not such a good idea to use ":/<pattern>" to specify which commit to merge, as ":/<pattern>" can often hit unexpected commits, but somebody tried it and got a nonsense error message: fatal: ':/Foo bar' does not point to a commit So here is a for-the-sake-of-consistency update that is fairly useless that allows users to carefully try not shooting in the foot. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'jk/color-and-pager'Libravatar Junio C Hamano1-6/+0
* jk/color-and-pager: want_color: automatically fallback to color.ui diff: don't load color config in plumbing config: refactor get_colorbool function color: delay auto-color decision until point of use git_config_colorbool: refactor stdout_is_tty handling diff: refactor COLOR_DIFF from a flag into an int setup_pager: set GIT_PAGER_IN_USE t7006: use test_config helpers test-lib: add helper functions for config t7006: modernize calls to unset Conflicts: builtin/commit.c parse-options.c
2011-08-26merge: keep stash[] a local variableLibravatar Nguyễn Thái Ngọc Duy1-17/+16
A stash is created by save_state() and used by restore_state(). Pass SHA-1 explicitly for clarity and keep stash[] to cmd_merge(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-25Merge branch 'jc/merge-reword'Libravatar Junio C Hamano1-1/+1
* jc/merge-reword: merge: reword the final message
2011-08-19want_color: automatically fallback to color.uiLibravatar Jeff King1-4/+0
All of the "do we want color" flags default to -1 to indicate that we don't have any color configured. This value is handled in one of two ways: 1. In porcelain, we check early on whether the value is still -1 after reading the config, and set it to the value of color.ui (which defaults to 0). 2. In plumbing, it stays untouched as -1, and want_color defaults it to off. This works fine, but means that every porcelain has to check and reassign its color flag. Now that want_color gives us a place to put this check in a single spot, we can do that, simplifying the calling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>