summaryrefslogtreecommitdiff
path: root/wt-status.c
AgeCommit message (Collapse)AuthorFilesLines
2013-04-12Merge branch 'tb/document-status-u-tradeoff' into maintLibravatar Junio C Hamano1-8/+4
* tb/document-status-u-tradeoff: i18n: make the translation of -u advice in one go
2013-04-12i18n: make the translation of -u advice in one goLibravatar Jiang Xin1-8/+4
The advice (consider use of -u when read_directory takes too long) is separated into 3 different status_printf_ln() calls, and which brings trouble for translators. Since status_vprintf() called by status_printf_ln() can handle eol in buffer, we could simply join these lines into one paragraph. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'tb/document-status-u-tradeoff' into maintLibravatar Junio C Hamano1-0/+25
* tb/document-status-u-tradeoff: status: advise to consider use of -u when read_directory takes too long git status: document trade-offs in choosing parameters to the -u option
2013-03-21wt-status: fix possible use of uninitialized variableLibravatar Jeff King1-1/+4
In wt_status_print_change_data, we accept a change_type flag that is meant to be either WT_STATUS_UPDATED or WT_STATUS_CHANGED. We then switch() on this value to set the local variable "status" for each case, but do not provide a fallback "default" label to the switch statement. As a result, the compiler realizes that "status" might be unset, and complains with a warning. To silence this warning, we use the "int status = status" trick. This is correct with the current code, as all callers provide one of the two expected change_type flags. However, it's also a maintenance trap, as there is nothing to prevent future callers from passing another flag, nor to document this assumption. Instead of using the "x = x" hack, let's handle the default case in the switch() statement with a die("BUG"). That tells the compiler and any readers of the code exactly what the function's input assumptions are. We could also convert the flag to an enum, which would provide a compile-time check on the function input. However, since these flags are part of a larger enum, that would make the code unnecessarily complex (we would have to make a new enum with just the two flags, and then convert it to the old enum for passing to sub-functions). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16status: advise to consider use of -u when read_directory takes too longLibravatar Nguyễn Thái Ngọc Duy1-0/+25
Introduce advice.statusUoption to suggest considering use of -u to strike different trade-off when it took more than 2 seconds to enumerate untracked/ignored files. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-14Merge branch 'nd/status-show-in-progress'Libravatar Junio C Hamano1-6/+88
* nd/status-show-in-progress: status: show the branch name if possible in in-progress info
2013-02-05status: show the branch name if possible in in-progress infoLibravatar Nguyễn Thái Ngọc Duy1-6/+88
The typical use-case is starting a rebase, do something else, come back the day after, run "git status" or make a new commit and wonder what in the world's going on. Which branch is being rebased is probably the most useful tidbit to help, but the target may help too. Ideally, I would have loved to see "rebasing master on origin/master", but the target ref name is not stored during rebase, so this patch writes "rebasing master on a78c8c98b" as a half-measure to remind future users of that potential improvement. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'jc/custom-comment-char'Libravatar Junio C Hamano1-4/+6
Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
2013-01-16Allow custom "comment char"Libravatar Junio C Hamano1-4/+6
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'ap/status-ignored-in-ignored-directory'Libravatar Junio C Hamano1-1/+3
Output from "git status --ignored" showed an unexpected interaction with "--untracked". * ap/status-ignored-in-ignored-directory: status: always report ignored tracked directories git-status: Test --ignored behavior dir.c: Make git-status --ignored more consistent
2013-01-01dir.c: Make git-status --ignored more consistentLibravatar Antoine Pelisse1-1/+3
The current behavior of git-status is inconsistent and misleading. Especially when used with --untracked-files=all option: - files ignored in untracked directories will be missing from status output. - untracked files in committed yet ignored directories are also missing. - with --untracked-files=normal, untracked directories that contains only ignored files are dropped too. Make the behavior more consistent across all possible use cases: - "--ignored --untracked-files=normal" doesn't show each specific files but top directory. It instead shows untracked directories that only contains ignored files, and ignored tracked directories with untracked files. - "--ignored --untracked-files=all" shows all ignored files, either because it's in an ignored directory (tracked or untracked), or because the file is explicitly ignored. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15wt-status.c: mark a private file-scope symbol as staticLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06status: remove i18n legosLibravatar Nguyễn Thái Ngọc Duy1-20/+28
"%s files" gives no sense what "%s" might be. Give translators full phrases. "blah blah blah%s\n" where %s is another sentence does not show the real length of full line. As a result, l10n messages may exceed 80 columns unintentionally. Make it two sentences. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-16status: color in-progress message like other header messagesLibravatar Jeff King1-2/+1
The "status" command recently learned to describe the in-progress operation in its long output format (e.g., rebasing, am, etc). This message gets its own slot in the color table, even though it is not configurable. As a result, if the user has set color.status.header to a non-default value, this message will not match (and cannot be made to match, as there is no config option). It is probably more sane to just color it like the rest of the text (i.e., just use color.status.header). This would not allow users to customize the color of this message independently, but they cannot do that with the current code anyway, and if somebody wants to build customizable colorization later, this patch does not make it much harder to do so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-14status: better advices when splitting a commit (during rebase -i)Libravatar Lucien Kong1-0/+52
Add new informative help messages at the output of 'git status' when the user is splitting a commit. The code figures this state by comparing the contents of the following files in the .git/ directory: - HEAD - ORIG_HEAD - rebase-merge/amend - rebase-merge/orig-head Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-14status: don't suggest "git rm" or "git add" if not appropriateLibravatar Lucien Kong1-1/+36
The display of the advice '(use git add/rm [...])' (when there are unmerged files) after running 'git status' is now depending of the mark, whether it's 'both deleted', 'deleted by us/them' or others. For instance, when there is just one file that's marked as 'both deleted', 'git status' shows '(use git rm [...])' and if there are two files, one as 'both deleted' and the other as 'added by them', the advice is '(use git add/rm [...])'. The previous tests in t7512-status-help.sh are updated. Test about the case of only 'both deleted' is added in t7060-wtstatus.sh Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-14wt-status.*: better advices for git status addedLibravatar Lucien Kong1-0/+156
This patch provides new informative help messages in the display of 'git status' (at the top) during conflicts, rebase, am, bisect or cherry-pick process. The new messages are not shown when using options such as -s or --porcelain. The messages about the current situation of the user are always displayed but the advices on what the user needs to do in order to resume a rebase/bisect/am/commit after resolving conflicts can be hidden by setting advice.statushints to 'false' in the config file. Thus, information about the updated advice.statushints key are added in Documentation/config.txt. Also, the test t7060-wt-status.sh is now working with the new help messages. Tests about suggestions of "git rm" are also added. Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-08Merge branch 'jk/maint-status-porcelain-z-b' into HEADLibravatar Jeff King1-17/+18
* jk/maint-status-porcelain-z-b: status: respect "-b" for porcelain format status: fix null termination with "-b" status: refactor null_termination option commit: refactor option parsing Conflicts: wt-status.h
2012-05-08status: respect "-b" for porcelain formatLibravatar Jeff King1-3/+3
There is no reason not to, as the user has to explicitly ask for it, so we are not breaking compatibility by doing so. We can do this simply by moving the "show_branch" flag into the wt_status struct. As a bonus, this saves us from passing it explicitly, simplifying the code. Signed-off-by: Jeff King <peff@peff.net>
2012-05-08status: fix null termination with "-b"Libravatar Jeff King1-3/+4
When the "-z" option is given to status, we are supposed to NUL-terminate each record. However, the "-b" code to show the tracking branch did not respect this, and always ended with a newline. Signed-off-by: Jeff King <peff@peff.net>
2012-05-08status: refactor null_termination optionLibravatar Jeff King1-13/+13
This option is passed separately to the wt_status printing functions, whereas every other formatting option is contained in the wt_status struct itself. Let's do the same here, so we can avoid passing it around through the call stack. Signed-off-by: Jeff King <peff@peff.net>
2012-04-27status: add --columnLibravatar Nguyễn Thái Ngọc Duy1-2/+26
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-3/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-23Merge branch 'maint-1.7.3' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.7.3: Reindent closing bracket using tab instead of spaces
2011-10-23Reindent closing bracket using tab instead of spacesLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'jk/color-and-pager'Libravatar Junio C Hamano1-2/+4
* 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-19color: delay auto-color decision until point of useLibravatar Jeff King1-1/+3
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18diff: refactor COLOR_DIFF from a flag into an intLibravatar Jeff King1-1/+1
This lets us store more than just a bit flag for whether we want color; we can also store whether we want automatic colors. This can be useful for making the automatic-color decision closer to the point of use. This mostly just involves replacing DIFF_OPT_* calls with manipulations of the flag. The biggest exception is that calls to DIFF_OPT_TST must check for "o->use_color > 0", which lets an "unknown" value (i.e., the default) stay at "no color". In the previous code, a value of "-1" was not propagated at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-29Merge branch 'jk/maint-1.7.2-status-ignored'Libravatar Junio C Hamano1-1/+1
* jk/maint-1.7.2-status-ignored: git status --ignored: tests and docs status: fix bug with missing --ignore files Conflicts: Documentation/git-status.txt t/t7508-status.sh
2011-06-02status: fix bug with missing --ignore filesLibravatar Jeff King1-1/+1
Commit 1b908b6 (wt-status: rename and restructure status-print-untracked, 2010-04-10) converted the wt_status_print_untracked function into wt_status_print_other, taking a string_list of either untracked or ignored items to print. However, the "nothing to show" early return still checked the wt_status->untracked list instead of the passed-in list. That meant that if we had ignored items to show, but no untracked items, we would erroneously exit early and fail to show the ignored items. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-58/+58
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-19Merge branch 'jn/status-translatable'Libravatar Junio C Hamano1-43/+117
* jn/status-translatable: commit, status: use status_printf{,_ln,_more} helpers commit: refer to commit template as s->fp wt-status: add helpers for printing wt-status lines Conflicts: builtin/commit.c
2011-03-09i18n: git-status "renamed: " messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "renamed: %s -> %s" message which appears as part of git-status(1) output. Two tests in t4001-diff-rename.sh explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status "Initial commit" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "# Initial commit" message. A test in t7501-commit.sh explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status "Changes to be committed" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "# Changes to be committed:" messages. Several tests explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Since these tests didn't check for the rest of the git-status(1) output this change has been split up from the "git-status basic messages" patch. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status shortstatus messagesLibravatar Ævar Arnfjörð Bjarmason1-6/+6
Make the messages added in v1.7.2-rc0~54^2~1 translatable. Some of these could use the to be implemented plural support in the gettext library. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status "nothing to commit" messagesLibravatar Ævar Arnfjörð Bjarmason1-6/+6
Gettextize the "nothing to commit" messages. Many tests explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-status basic messagesLibravatar Ævar Arnfjörð Bjarmason1-43/+43
Gettextize the most common git-status messages. Many tests checked for these explicitly. Change them to skip under GETTEXT_POISON=YesPlease. Some of the tests in t7508-status.sh needed to be split up when I added C_LOCALE_OUTPUT to them, since parts of them affected later tests (some of which aren't being skipped) indirectly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09Merge branch 'js/cherry-pick-usability'Libravatar Junio C Hamano1-2/+2
* js/cherry-pick-usability: Teach commit about CHERRY_PICK_HEAD bash: teach __git_ps1 about CHERRY_PICK_HEAD Introduce CHERRY_PICK_HEAD t3507: introduce pristine-detach helper
2011-03-08commit, status: use status_printf{,_ln,_more} helpersLibravatar Jonathan Nieder1-43/+43
wt-status code is used to provide a reminder of changes included and not included for the commit message template opened in the operator's text editor by "git commit". Therefore each line of its output begins with the comment character "#": # Please enter the commit message for your changes. Lines starting Use the new status_printf{,_ln,_more} functions to take care of adding "#" to the beginning of such status lines automatically. Using these will have two advantages over the current code: - The obvious one is to force separation of the "#" from the translatable part of the message when git learns to translate its output. - Another advantage is that this makes it easier for us to drop "#" prefix in "git status" output in later versions of git if we want to. Explained-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08wt-status: add helpers for printing wt-status linesLibravatar Jonathan Nieder1-0/+74
Introduce status_printf{,_ln,_more} wrapper functions around color_vfprintf() which take care of adding "#" to the beginning of status lines automatically. The semantics: - status_printf() is just like color_fprintf() but it adds a "# " at the beginning of each line of output; - status_printf_ln() is a convenience function that additionally adds "\n" at the end; - status_printf_more() is a variant of status_printf() used to continue lines that have already started. It suppresses the "#" at the beginning of the first line. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08commit, status: use status_printf{,_ln,_more} helpersLibravatar Jonathan Nieder1-43/+43
wt-status code is used to provide a reminder of changes included and not included for the commit message template opened in the operator's text editor by "git commit". Therefore each line of its output begins with the comment character "#": # Please enter the commit message for your changes. Lines starting Use the new status_printf{,_ln,_more} functions to take care of adding "#" to the beginning of such status lines automatically. Using these will have two advantages over the current code: - The obvious one is to force separation of the "#" from the translatable part of the message when git learns to translate its output. - Another advantage is that this makes it easier for us to drop "#" prefix in "git status" output in later versions of git if we want to. Explained-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08wt-status: add helpers for printing wt-status linesLibravatar Jonathan Nieder1-0/+74
Introduce status_printf{,_ln,_more} wrapper functions around color_vfprintf() which take care of adding "#" to the beginning of status lines automatically. The semantics: - status_printf() is just like color_fprintf() but it adds a "# " at the beginning of each line of output; - status_printf_ln() is a convenience function that additionally adds "\n" at the end; - status_printf_more() is a variant of status_printf() used to continue lines that have already started. It suppresses the "#" at the beginning of the first line. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21Teach commit about CHERRY_PICK_HEADLibravatar Jay Soffian1-2/+2
Previously the user was advised to use commit -c CHERRY_PICK_HEAD after a conflicting cherry-pick. While this would preserve the original commit's authorship, it would sadly discard cherry-pick's carefully crafted MERGE_MSG (which contains the list of conflicts as well as the original commit-id in the case of cherry-pick -x). On the other hand, if a bare 'commit' were performed, it would preserve the MERGE_MSG while resetting the authorship. In other words, there was no way to simultaneously take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. This change fixes that situation. A bare 'commit' will now take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. If the user wishes to reset authorship, that must now be done explicitly via --reset-author. A side-benefit of passing commit authorship along this way is that we can eliminate redundant authorship parsing code from revert.c. (Also removed an unused include from revert.c) Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03Convert ce_path_match() to use struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-1/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03struct rev_info: convert prune_data to struct pathspecLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-16Merge branch 'aa/status-hilite-branch'Libravatar Junio C Hamano1-4/+10
* aa/status-hilite-branch: default color.status.branch to "same as header" status: show branchname with a configurable color
2010-12-10default color.status.branch to "same as header"Libravatar Jeff King1-2/+5
This gives it the same behavior as we had prior to 1d28232 (status: show branchname with a configurable color). To do this we need the concept of a "NIL" color, which is provided by color.[ch]. The implementation is very simple; in particular, there are no precautions taken against code accidentally printing the NIL. This should be fine in practice because: 1. You can't input a NIL color in the config, so it must come from the in-code defaults. Which means it is up the client code to handle the NILs it defines. 2. If we do ever print a NIL, it will be obvious what the problem is, and the bug can be fixed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-03Merge branch 'kb/maint-status-cquote'Libravatar Junio C Hamano1-0/+10
* kb/maint-status-cquote: status: Quote paths with spaces in short format
2010-11-29status: show branchname with a configurable colorLibravatar Aleksi Aalto1-3/+6
You can tell "git status" to paint the name of the current branch in its output (the line that says "On branch ...") by setting the configuration variable color.status.branch; it is by default turned off. Signed-off-by: Aleksi Aalto <aga@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>