summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-06-26git-clean: add ask each interactive actionLibravatar Jiang Xin1-0/+36
Add a new action for interactive git-clean: ask each. It's just like the "rm -i" command, that the user must confirm one by one for each file or directory to be cleaned. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: add select by numbers interactive actionLibravatar Jiang Xin1-0/+39
Draw a multiple choice menu using `list_and_choose` to select items to be deleted by numbers. User can input: * 1,5-7 : select 1,5,6,7 items to be deleted * * : select all items to be deleted * -* : unselect all, nothing will be deleted * : (empty) finish selecting, and return back to main menu Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: add filter by pattern interactive actionLibravatar Jiang Xin1-0/+68
Add a new action for interactive git-clean: filter by pattern. When the user chooses this action, user can input space-separated patterns (the same syntax as gitignore), and each clean candidate that matches with one of the patterns will be excluded from cleaning. When the user feels it's OK, presses ENTER and backs to the confirmation dialog. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: use a git-add-interactive compatible UILibravatar Jiang Xin1-29/+427
Rewrite menu using a new method `list_and_choose`, which is borrowed from `git-add--interactive.perl`. We will use this framework to add new actions for interactive git-clean later. Please NOTE: * Method `list_and_choose` return an array of integers, and * it is up to you to free the allocated memory of the array. * The array ends with EOF. * If user pressed CTRL-D (i.e. EOF), no selection returned. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: add colors to interactive git-cleanLibravatar Jiang Xin1-1/+72
Show header, help, error messages, and prompt in colors for interactive git-clean. Re-use config variables, such as "color.interactive" and "color.interactive.<slot>" for command `git-add--interactive`. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Comments-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: show items of del_list in columnsLibravatar Jiang Xin1-9/+40
When there are lots of items to be cleaned, it is hard to see them all in one screen. Show them in columns will solve this problem. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Comments-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: add support for -i/--interactiveLibravatar Jiang Xin1-5/+52
Show what would be done and the user must confirm before actually cleaning. Would remove ... Would remove ... Would remove ... Remove [y/n]? Press "y" to start cleaning, and press "n" if you want to abort. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26git-clean: refactor git-clean into two phasesLibravatar Jiang Xin1-19/+45
Before introducing interactive git-clean, refactor git-clean operations into two phases: * hold cleaning items in del_list, * and remove them in a separate loop at the end. We will introduce interactive git-clean between the two phases. The interactive git-clean will show what would be done and must confirm before do real cleaning. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26write_name{_quoted_relative,}(): remove redundant parametersLibravatar Jiang Xin1-9/+8
After substitute path_relative() in quote.c with relative_path() from path.c, parameters (such as len and prefix_len) are redundant in function write_name() and write_name_quoted_relative(). The callers have already been audited that the strings they pass are properly NUL terminated and the length they give are the length of the string (or -1 that asks the length to be counted by the callee). Remove these now-redundant parameters. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26quote_path_relative(): remove redundant parameterLibravatar Jiang Xin3-13/+12
quote_path_relative() used to take a counted string as its parameter (the string to be quoted). With an earlier change, it now uses relative_path() that does not take a counted string, and we have been passing only the pointer to the string since then. Remove the length parameter from quote_path_relative() to show that this parameter was redundant. All the changed lines show that the caller passed either -1 (to ask the function run strlen() on the string), or the length of the string, so the earlier conversion was safe. All the callers of quote_path_relative() that used to take counted string have been audited to make sure that they are passing length of the actual string (or -1 to ask the callee run strlen()) Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26quote.c: substitute path_relative with relative_pathLibravatar Jiang Xin1-2/+7
Substitute the function path_relative in quote.c with the function relative_path. Function relative_path can be treated as an enhanced and more robust version of path_relative. Outputs of path_relative and it's replacement (relative_path) are the same for the following cases: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b/ c/ c/ /a/b/c /a/b/ c c /a/ /a/b/ ../ ../ / /a/b/ ../../ ../../ /a/c /a/b/ ../c ../c /x/y /a/b/ ../../x/y ../../x/y a/b/c/ a/b/ c/ c/ a/ a/b/ ../ ../ x/y a/b/ ../../x/y ../../x/y /a/b (empty) /a/b /a/b /a/b (null) /a/b /a/b a/b (empty) a/b a/b a/b (null) a/b a/b But if both of the path and the prefix are the same, or the returned relative path should be the current directory, the outputs of both functions are different. Function relative_path returns "./", while function path_relative returns empty string. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/ /a/b/ (empty) ./ a/b/ a/b/ (empty) ./ (empty) (null) (empty) ./ (empty) (empty) (empty) ./ But the callers of path_relative can handle such cases, or never encounter this issue at all, because: * In function quote_path_relative, if the output of path_relative is empty, append "./" to it, like: if (!out->len) strbuf_addstr(out, "./"); * Another caller is write_name_quoted_relative, which is only used by builtin/ls-files.c. git-ls-files only show files, so path of files will never be identical with the prefix of a directory. The following differences show that path_relative does not handle extra slashes properly: path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a//b//c/ //a/b// ../../../../a//b//c/ c/ a/b//c a//b ../b//c c And if prefix has no trailing slash, path_relative does not work properly either. But since prefix always has a trailing slash, it's not a problem. path prefix output of path_relative output of relative_path ======== ========= ======================= ======================= /a/b/c/ /a/b b/c/ c/ /a/b /a/b b ./ /a/b/ /a/b b/ ./ /a /a/b/ ../../a ../ a/b/c/ a/b b/c/ c/ a/b/ a/b b/ ./ a a/b ../a ../ x/y a/b/ ../x/y ../../x/y a/c a/b c ../c /a/ /a/b (empty) ../ (empty) /a/b ../../ ./ One tricky part in this conversion is write_name() function in ls-files.c. It takes a counted string, <name, len>, that is to be made relative to <prefix, prefix_len> and then quoted. Because write_name_quoted_relative() still takes these two parameters as counted string, but ignores the count and treat these two as NUL-terminated strings, this conversion needs to be audited for its callers: - For <name, len>, all three callers of write_name() passes a NUL-terminated string and its true length, so this patch makes "len" unused. - For <prefix, prefix_len>, prefix could be a string that is longer than empty while prefix_len could be 0 when "--full-name" option is used. This is fixed by checking prefix_len in write_name() and calling write_name_quoted_relative() with NULL when prefix_len is set to 0. Again, this makes "prefix_len" given to write_name_quoted_relative() unused, without introducing a bug. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-06Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+5
* jk/merge-tree-added-identically: merge-tree: handle directory/empty conflict correctly
2013-05-06merge-tree: handle directory/empty conflict correctlyLibravatar John Keeping1-1/+5
git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this by setting the entries bit in the directory mask when the entry is missing or when it is a directory, only performing the file comparison when we know that a file entry exists. Reported-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: John Keeping <john@keeping.me.uk> Tested-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01Merge branch 'tr/remote-tighten-commandline-parsing'Libravatar Junio C Hamano1-1/+1
* tr/remote-tighten-commandline-parsing: remote: 'show' and 'prune' can take more than one remote remote: check for superfluous arguments in 'git remote add' remote: add a test for extra arguments, according to docs
2013-04-28Merge branch 'jk/check-corrupt-objects-carefully'Libravatar Junio C Hamano1-1/+1
* jk/check-corrupt-objects-carefully: clone: Make the 'junk_mode' symbol a file static
2013-04-28clone: Make the 'junk_mode' symbol a file staticLibravatar Ramsay Jones1-1/+1
Sparse issues an "'junk_mode' not declared. Should it be static?" warning. In order to suppress the warning, since this symbol does not need more than file visibility, we simply add the static modifier to its declaration. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+1
off-by-one fix. * jk/merge-tree-added-identically: merge-tree: fix typo in "both changed identically"
2013-04-28merge-tree: fix typo in "both changed identically"Libravatar John Keeping1-1/+1
Commit aacecc3 (merge-tree: don't print entries that match "local" - 2013-04-07) had a typo causing the "same in both" check to be incorrect and check if both the base and "their" versions are removed instead of checking that both the "our" and "their" versions are removed. Fix this. Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-26Merge branch 'rr/shortlog-doc'Libravatar Junio C Hamano2-4/+2
Update documentation for "log" and "shortlog". * rr/shortlog-doc: builtin/shortlog.c: make usage string consistent with log builtin/log.c: make usage string consistent with doc git-shortlog.txt: make SYNOPSIS match log, update OPTIONS git-log.txt: rewrite note on why "--" may be required git-log.txt: generalize <since>..<until> git-log.txt: order OPTIONS properly; move <since>..<until> revisions.txt: clarify the .. and ... syntax git-shortlog.txt: remove (-h|--help) from OPTIONS
2013-04-26Merge branch 'jc/add-ignore-removal'Libravatar Junio C Hamano1-6/+17
Introduce "--ignore-removal" as a synonym to "--no-all" for "git add", and improve the 2.0 migration warning with it. * jc/add-ignore-removal: git add: rephrase -A/--no-all warning git add: --ignore-removal is a better named --no-all
2013-04-26Merge branch 'jc/warn-pathless-add-finishing-touches'Libravatar Junio C Hamano1-0/+2
* jc/warn-pathless-add-finishing-touches: git add: avoid "-u/-A without pathspec" warning on stat-dirty paths
2013-04-26git add: avoid "-u/-A without pathspec" warning on stat-dirty pathsLibravatar Junio C Hamano1-0/+2
In preparation for Git 2.0, "git add -u/-A" without pathspec checks all the working tree (not limited to the current directory) and issues a warning when it finds any path that we might add in Git 2.0, because that would mean the users' fingers need to be trained to explicitly say "." if they want to keep the current behaviour. However, the check was incomplete, because "git add" usually does not refresh the index, considers a path that is stat-dirty but has contents that is otherwise up-to-date in the index as "we might add", and relies on that it is a no-op to add the same thing again via the add_file_to_index() API (which also knows not to say "added" in verbose mode when this happens). We do not want to trigger the warning for a path that is outside the current directory is merely stat-dirty, as it won't be added in Git 2.0, either. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
2013-04-24Merge branch 'jk/remote-helper-with-signed-tags'Libravatar Junio C Hamano1-1/+7
Allows remote-helpers to declare they can handle signed tags, and issue a warning when using those that don't. * jk/remote-helper-with-signed-tags: transport-helper: add 'signed-tags' capability transport-helper: pass --signed-tags=warn-strip to fast-export fast-export: add --signed-tags=warn-strip mode
2013-04-24Sync with maintLibravatar Junio C Hamano1-2/+2
* maint: Update draft release notes to 1.8.2.2 completion: remove duplicate block for "git commit -c" cherry-pick/revert: make usage say '<commit-ish>...'
2013-04-24Merge branch 'jc/merge-tag-object' into maintLibravatar Junio C Hamano1-0/+13
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. Make the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-04-24remote: check for superfluous arguments in 'git remote add'Libravatar Thomas Rast1-1/+1
The 'git remote add' subcommand did not check for superfluous command line arguments. Make it so. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24cherry-pick/revert: make usage say '<commit-ish>...'Libravatar Kevin Bracey1-2/+2
The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-23Merge branch 'nd/pretty-formats'Libravatar Junio C Hamano2-2/+2
pretty-printing body of the commit that is stored in non UTF-8 encoding did not work well. The early part of this series fixes it. And then it adds %C(auto) specifier that turns the coloring on when we are emitting to the terminal, and adds column-aligning format directives. * nd/pretty-formats: pretty: support %>> that steal trailing spaces pretty: support truncating in %>, %< and %>< pretty: support padding placeholders, %< %> and %>< pretty: add %C(auto) for auto-coloring pretty: split color parsing into a separate function pretty: two phase conversion for non utf-8 commits utf8.c: add reencode_string_len() that can handle NULs in string utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences utf8.c: move display_mode_esc_sequence_len() for use by other functions pretty: share code between format_decoration and show_decorations pretty-formats.txt: wrap long lines pretty: get the correct encoding for --pretty:format=%e pretty: save commit encoding from logmsg_reencode if the caller needs it
2013-04-23Merge branch 'kb/status-ignored-optim-2'Libravatar Junio C Hamano3-21/+6
Fixes a handful of issues in the code to traverse working tree to find untracked and/or ignored files, cleans up and optimizes the codepath in general. * kb/status-ignored-optim-2: dir.c: git-status --ignored: don't scan the work tree twice dir.c: git-status --ignored: don't scan the work tree three times dir.c: git-status: avoid is_excluded checks for tracked files dir.c: replace is_path_excluded with now equivalent is_excluded API dir.c: unify is_excluded and is_path_excluded APIs dir.c: move prep_exclude dir.c: factor out parts of last_exclude_matching for later reuse dir.c: git-clean -d -X: don't delete tracked directories dir.c: make 'git-status --ignored' work within leading directories dir.c: git-status --ignored: don't list empty directories as ignored dir.c: git-ls-files --directories: don't hide empty directories dir.c: git-status --ignored: don't list empty ignored directories dir.c: git-status --ignored: don't list files in ignored directories dir.c: git-status --ignored: don't drop ignored directories
2013-04-23Merge branch 'jk/receive-pack-deadlocks-with-early-failure'Libravatar Junio C Hamano1-1/+4
When receive-pack detects error in the pack header it received in order to decide which of unpack-objects or index-pack to run, it returned without closing the error stream, which led to a hang sideband thread. * jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors
2013-04-22git add: rephrase -A/--no-all warningLibravatar Junio C Hamano1-6/+6
Now we have a synonym --ignore-removal for --no-all, we can rephrase the Git 2.0 transition warning message in a more natural way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22git add: --ignore-removal is a better named --no-allLibravatar Junio C Hamano1-0/+11
In the historical context of "git add --all ." that pays attention to "all kinds of changes" (implying "without ignoring removals"), the option to countermand it "--no-all" may have made sense, but because we will be making "--all" the default when a pathspec is given, it makes more sense to rename the option to a more explicit "--ignore-removal". The "--all" option naturally becomes its negation, "--no-ignore-removal". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22Merge branch 'jk/show-branch-strbuf' into maintLibravatar Junio C Hamano1-9/+8
* jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-22Merge branch 'jc/apply-ws-fix-tab-in-indent' into maintLibravatar Junio C Hamano1-6/+10
* jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer
2013-04-22Merge branch 'as/clone-reference-with-gitfile'Libravatar Junio C Hamano1-3/+13
"git clone" did not work if a repository pointed at by the "--reference" option is a gitfile that points at another place. * as/clone-reference-with-gitfile: clone: Allow repo using gitfile as a reference clone: Fix error message for reference repository
2013-04-22Merge branch 'jc/add-2.0-delete-default' (early part)Libravatar Junio C Hamano1-28/+87
Preparatory steps to make "git add <pathspec>" take notice of removed paths that match <pathspec> by default in Git 2.0. * 'jc/add-2.0-delete-default' (early part): git add: rephrase the "removal will cease to be ignored" warning git add: rework the logic to warn "git add <pathspec>..." default change git add: start preparing for "git add <pathspec>..." to default to "-A" builtin/add.c: simplify boolean variables
2013-04-22Merge branch 'nd/checkout-keep-sparse'Libravatar Junio C Hamano1-0/+5
Make the initial "sparse" selection of the paths more sticky across "git checkout". * nd/checkout-keep-sparse: checkout: add --ignore-skip-worktree-bits in sparse checkout mode
2013-04-22Merge branch 'jk/chopped-ident'Libravatar Junio C Hamano2-74/+8
A commit object whose author or committer ident are malformed crashed some code that trusted that a name, an email and an timestamp can always be found in it. * jk/chopped-ident: blame: handle broken commit headers gracefully pretty: handle broken commit headers gracefully cat-file: print tags raw for "cat-file -p"
2013-04-22builtin/shortlog.c: make usage string consistent with logLibravatar Ramkumar Ramachandra1-3/+1
"--" is used to separate pathspecs from the rev specs, and not rev specs from the options, as the shortlog_usage string currently indicates. In correcting this usage string, make it consistent with the log_usage string. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22builtin/log.c: make usage string consistent with docLibravatar Ramkumar Ramachandra1-1/+1
Replace '<since>..<until>' with '<revision range>', in accordance with the documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21git add: rephrase the "removal will cease to be ignored" warningLibravatar Junio C Hamano1-7/+14
Now the logic to decide when to warn has been tightened, we know the user is in a situation where the current and future behaviours will be different. Spell out what happens with these two versions and how to explicitly ask for the behaviour, and suggest "git status" as a way to inspect the current status. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19receive-pack: close sideband fd on early pack errorsLibravatar Jeff King1-1/+4
Since commit a22e6f8 (receive-pack: send pack-processing stderr over sideband, 2012-09-21), receive-pack will start an async sideband thread to copy the stderr from our index-pack or unpack-objects child to the client. We hand the thread's input descriptor to unpack(), which puts it in the "err" member of the "struct child_process". After unpack() returns, we use finish_async() to reap the sideband thread. The thread is only ready to die when it gets EOF on its pipe, which is connected to the err descriptor. So we expect all of the write ends of that pipe to be closed as part of unpack(). Normally, this works fine. After start_command forks, it closes the parent copy of the descriptor. Then once the child exits (whether it was successful or not), that closes the only remaining writer. However, there is one code-path in unpack() that does not handle this. Before we decide which of unpack-objects or index-pack to use, we read the pack header ourselves to see how many objects it contains. If there is an error here, we exit without running either sub-command, the pipe descriptor remains open, and we are in a deadlock, waiting for the sideband thread to die (which is in turn waiting for us to close the pipe). We can fix this by making sure that unpack() always closes the pipe before returning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19Merge branch 'jn/add-2.0-u-A-sans-pathspec' (early part)Libravatar Junio C Hamano1-40/+94
In Git 2.0, "git add -u" and "git add -A" without any pathspec will update the index for all paths, including those outside the current directory, making it more consistent with "commit -a". To help the migration pain, a warning is issued when the differences between the current behaviour and the upcoming behaviour matters, i.e. when the user has local changes outside the current directory. * 'jn/add-2.0-u-A-sans-pathspec' (early part): add -A: only show pathless 'add -A' warning when changes exist outside cwd add -u: only show pathless 'add -u' warning when changes exist outside cwd add: make warn_pathless_add() a no-op after first call add: add a blank line at the end of pathless 'add [-u|-A]' warning add: make pathless 'add [-u|-A]' warning a file-global function
2013-04-19Merge branch 'ap/strbuf-humanize'Libravatar Junio C Hamano1-8/+36
Teach "--human-readable" aka "-H" option to "git count-objects" to show various large numbers in Ki/Mi/GiB scaled as necessary. * ap/strbuf-humanize: count-objects: add -H option to humanize sizes strbuf: create strbuf_humanise_bytes() to show byte sizes
2013-04-19Merge branch 'fc/branch-upstream-color'Libravatar Junio C Hamano1-8/+28
Add more colors to "git branch -vv" output. * fc/branch-upstream-color: branch: colour upstream branches
2013-04-18pretty: save commit encoding from logmsg_reencode if the caller needs itLibravatar Nguyễn Thái Ngọc Duy2-2/+2
The commit encoding is parsed by logmsg_reencode, there's no need for the caller to re-parse it again. The reencoded message now has the new encoding, not the original one. The caller would need to read commit object again before parsing. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-13/+13
The resolution of some corner cases by "git merge-tree" were inconsistent between top-of-the-tree and in a subdirectory. * jk/merge-tree-added-identically: merge-tree: don't print entries that match "local"
2013-04-18Merge branch 'fc/send-email-annotate'Libravatar Junio C Hamano1-81/+85
Allows format-patch --cover-letter to be configurable; the most notable is the "auto" mode to create cover-letter only for multi patch series. * fc/send-email-annotate: rebase-am: explicitly disable cover-letter format-patch: trivial cleanups format-patch: add format.coverLetter configuration variable log: update to OPT_BOOL format-patch: refactor branch name calculation format-patch: improve head calculation for cover-letter send-email: make annotate configurable
2013-04-18Merge branch 'kb/co-orphan-suggestion-short-sha1'Libravatar Junio C Hamano1-1/+1
Update the informational message when "git checkout" leaves the detached head state. * kb/co-orphan-suggestion-short-sha1: checkout: abbreviate hash in suggest_reattach
2013-04-17git add: rework the logic to warn "git add <pathspec>..." default changeLibravatar Junio C Hamano1-26/+38
The earlier logic to warn against "git add subdir" that is run without "-A" or "--no-all" was only to check any <pathspec> given exactly spells a directory name that (still) exists on the filesystem. This had number of problems: * "git add '*dir'" (note that the wildcard is hidden from the shell) would not trigger the warning. * "git add '*.py'" would behave differently between the current version of Git and Git 2.0 for the same reason as "subdir", but would not trigger the warning. * "git add dir" for a submodule "dir" would just update the index entry for the submodule "dir" without ever recursing into it, and use of "-A" or "--no-all" would matter. But the logic only checks the directory-ness of "dir" and gives an unnecessary warning. Rework the logic to detect the case where the behaviour will be different in Git 2.0, and issue a warning only when it matters. Even with the code before this warning, "git add subdir" will have to traverse the directory in order to find _new_ files the index does not know about _anyway_, so we can do this check without adding an extra pass to find if <pathspec> matches any removed file. This essentially updates the "add_files_to_cache()" public API to "update_files_in_cache()" API that is internal to "git add", because with the "--all" option, the function is no longer about "adding" paths to the cache, but is also used to remove them. There are other callers of the former from "checkout" (used when "checkout -m" prepares the temporary tree that represents the local modifications to be merged) and "commit" ("commit --include" that picks up local changes in addition to what is in the index). Since ADD_CACHE_IGNORE_ERRORS (aka "--no-all") is not used by either of them, once dust settles after Git 2.0 and the warning becomes unnecessary, we may want to unify these two functions again. Signed-off-by: Junio C Hamano <gitster@pobox.com>