summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2012-06-15fix pager.diff with diff --no-indexLibravatar Jeff King1-7/+17
git-diff does not rely on the git wrapper to setup its pager; instead, it sets it up on its own after seeing whether --quiet or --exit-code has been specified. After diff_no_index was split off from cmd_diff, commit b3fde6c (git diff --no-index: default to page like other diff frontends, 2008-05-26) duplicated the one-liner from cmd_diff to turn on the pager. Later, commit 8f0359f (Allow pager of diff command be enabled/disabled, 2008-07-21) taught the the version in cmd_diff to respect the pager.diff config, but the version in diff_no_index was left behind. This meant that git -c pager.diff=0 diff a b would not use a pager, but git -c pager.diff=0 diff --no-index a b would. Let's fix it by factoring out a common function. While we're there, let's update the antiquated comment, which claims that the pager interferes with propagating the exit code; this has not been the case since ea27a18 (spawn pager via run_command interface, 2008-07-22). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Merge branch 'rs/maint-grep-F' into maintLibravatar Junio C Hamano1-5/+2
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should. By René Scharfe * rs/maint-grep-F: grep: stop leaking line strings with -f grep: support newline separated pattern list grep: factor out do_append_grep_pat() grep: factor out create_grep_pat()
2012-06-01Merge branch 'ap/checkout-no-progress-for-non-tty' into maintLibravatar Junio C Hamano1-2/+2
"git checkout" gave progress display even when the standard error stream was not connected to the tty, which made little sense. By Avery Pennarun * ap/checkout-no-progress-for-non-tty: checkout: no progress messages if !isatty(2).
2012-05-25fmt-merge-message: add empty line between tag and signature verificationLibravatar Linus Torvalds1-3/+5
When adding the information from a tag, put an empty line between the message of the tag and the commented-out signature verification information. At least for the kernel workflow, I often end up re-formatting the message that people send me in the tag data. In that situation, putting the tag message and the tag signature verification back-to-back then means that normal editor "reflow parapgraph" command will get confused and think that the signature is a continuation of the last message paragraph. So I always end up having to first add an empty line, and then go back and reflow the last paragraph. Let's just do it in git directly. The extra vertical space also makes the verification visually stand out more from the user-supplied message, so it looks a bit more readable to me too, but that may be just an odd personal preference. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-24Merge branch 'jk/maint-status-porcelain-z-b' into maintLibravatar Junio C Hamano1-68/+67
"git status --porcelain" ignored "--branch" option by mistake. The output for "git status --branch -z" was also incorrect and did not terminate the record for the current branch name with NUL as asked. By Jeff King * 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
2012-05-24checkout: no progress messages if !isatty(2).Libravatar Avery Pennarun1-2/+2
If stderr isn't a tty, we shouldn't be printing incremental progress messages. In particular, this affects 'git checkout -f . >&logfile' unless you provided -q. And git-new-workdir has no way to provide -q. It would probably be better to have progress.c check isatty(2) all the time, but that wouldn't allow things like 'git push --progress' to force progress reporting to on, so I won't try to solve the general case right now. Actual fix suggested by Jeff King. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-21grep: stop leaking line strings with -fLibravatar René Scharfe1-5/+2
When reading patterns from a file, we pass the lines as allocated string buffers to append_grep_pat() and never free them. That's not a problem because they are needed until the program ends anyway. However, now that the function duplicates the pattern string, we can reuse the strbuf after calling that function. This simplifies the code a bit and plugs a minor memory leak. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-14Merge branch 'jk/maint-reflog-walk-count-vs-time' into maintLibravatar Junio C Hamano1-0/+1
Gives a better DWIM behaviour for --pretty=format:%gd, "stash list", and "log -g", depending on how the starting point ("master" vs "master@{0}" vs "master@{now}") and date formatting options (e.g. "--date=iso") are given on the command line. By Jeff King (4) and Junio C Hamano (1) * jk/maint-reflog-walk-count-vs-time: reflog-walk: tell explicit --date=default from not having --date at all reflog-walk: always make HEAD@{0} show indexed selectors reflog-walk: clean up "flag" field of commit_reflog struct log: respect date_mode_explicit with --format:%gd t1411: add more selector index/date tests
2012-05-14Merge branch 'ef/checkout-empty' into maintLibravatar Junio C Hamano1-1/+1
Running "git checkout" on an unborn branch used to corrupt HEAD (regression in 1.7.10); this makes it error out. By Erik Faye-Lund * ef/checkout-empty: checkout: do not corrupt HEAD on empty repo
2012-05-14Merge branch 'js/checkout-detach-count' into maintLibravatar Junio C Hamano1-6/+7
When checking out another commit from an already detached state, we used to report all commits that are not reachable from any of the refs as lossage, but some of them might be reachable from the new HEAD, and there is no need to warn about them. By Johannes Sixt * js/checkout-detach-count: checkout (detached): truncate list of orphaned commits at the new HEAD t2020-checkout-detach: check for the number of orphaned commits
2012-05-14Merge branch 'ef/maint-clone-progress-fix' into maintLibravatar Junio C Hamano1-1/+1
Some time ago, "git clone" lost the progress output for its "checkout" phase; when run without any "--quiet" option, it should give progress to the lengthy operation. By Erik Faye-Lund * ef/maint-clone-progress-fix: clone: fix progress-regression
2012-05-11Merge branch 'ct/advise-push-default' into maintLibravatar Junio C Hamano1-5/+55
The cases "git push" fails due to non-ff can be broken into three categories; each case is given a separate advise message. By Christopher Tiwald (2) and Jeff King (1) * ct/advise-push-default: Fix httpd tests that broke when non-ff push advice changed clean up struct ref's nonfastforward field push: Provide situational hints for non-fast-forward errors
2012-05-11Merge branch 'jk/repack-no-explode-objects-from-old-pack' into maintLibravatar Junio C Hamano2-49/+65
"git repack" used to write out unreachable objects as loose objects when repacking, even if such loose objects will immediately pruned due to its age. By Jeff King * jk/repack-no-explode-objects-from-old-pack: gc: use argv-array for sub-commands argv-array: add a new "pushl" method argv-array: refactor empty_argv initialization gc: do not explode objects which will be immediately pruned
2012-05-11Merge branch 'rl/show-empty-prefix' into maintLibravatar Junio C Hamano1-0/+2
Unlike "git rev-parse --show-cdup", "--show-prefix" did not give an empty line when run at the top of the working tree. By Ross Lagerwall * rl/show-empty-prefix: rev-parse --show-prefix: add in trailing newline
2012-05-10Merge branch 'cc/fix-missing-va-end-in-revert' into maintLibravatar Junio C Hamano1-0/+1
By Christian Couder * cc/fix-missing-va-end-in-revert: revert: add missing va_end
2012-05-10Merge branch 'jk/maint-push-progress' into maintLibravatar Junio C Hamano1-0/+13
"git push" over smart-http lost progress output a few releases ago. By Jeff King * jk/maint-push-progress: t5541: test more combinations of --progress teach send-pack about --[no-]progress send-pack: show progress when isatty(2)
2012-05-08checkout: do not corrupt HEAD on empty repoLibravatar Erik Faye-Lund1-1/+1
In abe1998 ("git checkout -b: allow switching out of an unborn branch"), a code-path overly-optimisticly assumed that a branch-name was specified. This is not always the case, and as a result a NULL-pointer was attempted printed to .git/HEAD. This could lead to at least two different failure modes: 1) vsnprintf formated the NULL-string as something useful (e.g "(null)") 2) vsnprintf crashed Neither were very convenient for formatting a new HEAD-reference. To fix this, reintroduce some strictness so we only take this new codepath if a banch-name was specified. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-08status: respect "-b" for porcelain formatLibravatar Jeff King1-5/+4
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: refactor null_termination optionLibravatar Jeff King1-9/+8
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-05-08commit: refactor option parsingLibravatar Jeff King1-58/+59
The options are declared as a static global, but really they need only be accessible from cmd_commit. Additionally, declare the "struct wt_status" in cmd_commit and cmd_status as static at the top of each function; this will let the options lists reference them directly, which will facilitate further cleanups. Signed-off-by: Jeff King <peff@peff.net>
2012-05-07Merge branch 'ef/maint-1.7.6-clone-progress-fix' into ↵Libravatar Junio C Hamano1-1/+1
ef/maint-clone-progress-fix By Erik Faye-Lund * ef/maint-1.7.6-clone-progress-fix: clone: fix progress-regression
2012-05-07clone: fix progress-regressionLibravatar Erik Faye-Lund1-1/+1
In 5bd631b3 ("clone: support multiple levels of verbosity"), the default behavior to show progress of the implicit checkout in the clone-command regressed so that progress was only shown if the verbose-option was specified. Fix this by making option_verbosity == 0 output progress as well. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04checkout (detached): truncate list of orphaned commits at the new HEADLibravatar Johannes Sixt1-6/+7
When git checkout switches from a detached HEAD to any other commit, then all orphaned commits were listed in a warning: Warning: you are leaving 2 commits behind...: a5e5396 another fixup 6aa1af6 fixup foo But if the new commit is actually one from this list (6aa1af6 in this example), then the list in the warning can be truncated at the new HEAD, because history beginning at HEAD is not "left behind". This makes it so. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04log: respect date_mode_explicit with --format:%gdLibravatar Jeff King1-0/+1
When we show a reflog selector (e.g., via "git log -g"), we perform some DWIM magic: while we normally show the entry's index (e.g., HEAD@{1}), if the user has given us a date with "--date", then we show a date-based select (e.g., HEAD@{yesterday}). However, we don't want to trigger this magic if the alternate date format we got was from the "log.date" configuration; that is not sufficiently strong context for us to invoke this particular magic. To fix this, commit f4ea32f (improve reflog date/number heuristic, 2009-09-24) introduced a "date_mode_explicit" flag in rev_info. This flag is set only when we see a "--date" option on the command line, and we a vanilla date to the reflog code if the date was not explicit. Later, commit 8f8f547 (Introduce new pretty formats %g[sdD] for reflog information, 2009-10-19) added another way to show selectors, and it did not respect the date_mode_explicit flag from f4ea32f. This patch propagates the date_mode_explicit flag to the pretty-print code, which can then use it to pass the appropriate date field to the reflog code. This brings the behavior of "%gd" in line with the other formats, and means that its output is independent of any user configuration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-03Merge branch 'jc/merge-reduce-parents-early' into maintLibravatar Junio C Hamano2-63/+207
Octopus merge strategy did not reduce heads that are recorded in the final commit correctly. By Junio C Hamano (4) and Michał Kiedrowicz (1) * jc/merge-reduce-parents-early: fmt-merge-msg: discard needless merge parents builtin/merge.c: reduce parents early builtin/merge.c: collect other parents early builtin/merge.c: remove "remoteheads" global variable merge tests: octopus with redundant parents
2012-05-03Merge branch 'cb/cherry-pick-rev-path-confusion' into maintLibravatar Junio C Hamano1-1/+4
The command line parser choked "git cherry-pick $name" when $name can be both revision name and a pathname, even though $name can never be a path in the context of the command. By Clemens Buchacher * cb/cherry-pick-rev-path-confusion: cherry-pick: do not expect file arguments
2012-05-03Merge branch 'mb/fetch-call-a-non-branch-a-ref' into maintLibravatar Junio C Hamano1-4/+13
The report from "git fetch" said "new branch" even for a non branch ref. By Marc Branchaud * mb/fetch-call-a-non-branch-a-ref: fetch: describe new refs based on where it came from fetch: Give remote_ref to update_local_ref() as well
2012-05-01Merge branch 'it/fetch-pack-many-refs' into maintLibravatar Junio C Hamano1-1/+41
When "git fetch" encounters repositories with too many references, the command line of "fetch-pack" that is run by a helper e.g. remote-curl, may fail to hold all of them. Now such an internal invocation can feed the references through the standard input of "fetch-pack". By Ivan Todoroski * it/fetch-pack-many-refs: remote-curl: main test case for the OS command line overflow fetch-pack: test cases for the new --stdin option remote-curl: send the refs to fetch-pack on stdin fetch-pack: new --stdin option to read refs from stdin Conflicts: t/t5500-fetch-pack.sh
2012-05-01Merge branch 'jl/maint-submodule-recurse-fetch' into maintLibravatar Junio C Hamano1-3/+3
"git fetch" that recurses into submodules on demand did not check if it needs to go into submodules when non branches (most notably, tags) are fetched. By Jens Lehmann * jl/maint-submodule-recurse-fetch: submodules: recursive fetch also checks new tags for submodule commits
2012-05-01Merge branch 'jc/maint-blame-minimal' into maintLibravatar Junio C Hamano1-0/+1
"git blame" started missing quite a few changes from the origin since we stopped using the diff minimalization by default in v1.7.2 era. Teach "--minimal" option to "git blame" to work around this regression. * jc/maint-blame-minimal: blame: accept --need-minimal
2012-05-01teach send-pack about --[no-]progressLibravatar Jeff King1-2/+12
The send_pack function gets a "progress" flag saying "yes, definitely show progress" or "no, definitely do not show progress". This gets set properly by transport_push when send_pack is called directly. However, when the send-pack command is executed separately (as it is for the remote-curl helper), there is no way to tell it "definitely do this". As a result, we do not properly respect "git push --no-progress" for smart-http remotes; you will still get progress if stderr is a tty. This patch teaches send-pack --progress and --no-progress, and teaches remote-curl to pass the appropriate option to override send-pack's isatty check. This fixes the --no-progress case above, and as a bonus, also makes "git push --progress" work when stderr is not a tty. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-01send-pack: show progress when isatty(2)Libravatar Jeff King1-0/+3
The send_pack_args struct has two verbosity flags: "quiet" and "progress". Originally, if "quiet" was set, we would tell pack-objects explicitly to be quiet, and if "progress" was set, we would tell it to show progress. Otherwise, we told it neither, and it relied on isatty(2) to make the decision itself. However, commit 01fdc21 changed the meaning of these variables. Now both "quiet" and "!progress" instruct us to tell pack-objects to be quiet (and a non-zero "progress" means the same as before). This works well for transports which call send_pack directly, as the transport code copies transport->progress into send_pack_args->progress, and they both have the same meaning. However, the code path of calling "git send-pack" was left behind. It always sets "progress" to 0, and thus always tells pack-objects to be quiet. We can work around this by checking isatty(2) ourselves in the cmd_send_pack code path, restoring the original behavior of the send-pack command. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26Merge branch 'jc/push-upstream-sanity' into maintLibravatar Junio C Hamano1-8/+18
The 'push to upstream' implementation was broken in some corner cases. "git push $there" without refspec, when the current branch is set to push to a remote different from $there, used to push to $there using the upstream information to a remote unreleated to $there. * jc/push-upstream-sanity: push: error out when the "upstream" semantics does not make sense
2012-04-26Merge branch 'jk/diff-no-rename-empty' into maintLibravatar Junio C Hamano1-1/+1
Rename detection logic used to match two empty files as renames during merge-recursive, leading unnatural mismerges. By Jeff King * jk/diff-no-rename-empty: merge-recursive: don't detect renames of empty files teach diffcore-rename to optionally ignore empty content make is_empty_blob_sha1 available everywhere drop casts from users EMPTY_TREE_SHA1_BIN
2012-04-26Merge branch 'jc/commit-unedited-template' into maintLibravatar Junio C Hamano1-19/+43
When "git commit --template F" errors out because the user did not touch the message, it claimed that it aborts due to "empty message", which was utterly wrong. By Junio C Hamano (4) and Adam Monsen (1) * jc/commit-unedited-template: Documentation/git-commit: rephrase the "initial-ness" of templates git-commit.txt: clarify -t requires editing message commit: rephrase the error when user did not touch templated log message commit: do not trigger bogus "has templated message edited" check t7501: test the right kind of breakage
2012-04-26Merge branch 'jc/commit-hook-authorship' into maintLibravatar Junio C Hamano1-3/+19
"git commit --author=$name" did not tell the name that was being recorded in the resulting commit to hooks, even though it does do so when the end user overrode the authorship via the "GIT_AUTHOR_NAME" environment variable. * jc/commit-hook-authorship: commit: pass author/committer info to hooks t7503: does pre-commit-hook learn authorship? ident.c: add split_ident_line() to parse formatted ident line
2012-04-21revert: add missing va_endLibravatar Christian Couder1-0/+1
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-18fmt-merge-msg: discard needless merge parentsLibravatar Junio C Hamano1-9/+119
This is used by "git pull" to construct a merge message from list of remote refs. When pulling redundant set of refs, however, it did not filter them even though the merge itself discards them as unnecessary. Teach the command to do the same for consistency. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-18gc: use argv-array for sub-commandsLibravatar Jeff King1-45/+33
git-gc executes many sub-commands. The argument list for some of these is constant, but for others we add more arguments at runtime. The latter is implemented by allocating a constant extra number of NULLs, and either using a custom append function, or just referencing unused slots by number. As of commit 7e52f56, which added two new arguments, it is possible to exceed the constant number of slots for "repack" by running "git gc --aggressive", causing "git gc" to die. This patch converts all of the static argv lists to use argv-array. In addition to fixing the overflow caused by 7e52f56, it has a few advantages: 1. We can drop the custom append function (which, incidentally, had an off-by-one error exacerbating the static limit). 2. We can drop the ugly magic numbers used when adding arguments to "prune". 3. Adding further arguments will be easier; you can just add new "push" calls without worrying about increasing any static limits. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17builtin/merge.c: reduce parents earlyLibravatar Junio C Hamano1-25/+40
Instead of waiting until we record the parents of resulting merge, reduce redundant parents (including our HEAD) immediately after reading them. The change to t7602 illustrates the essence of the effect of this change. The octopus merge strategy used to be fed with redundant commits only to discard them as "up-to-date", but we no longer feed such redundant commits to it and the affected test degenerates to a regular two-head merge. And obviously the known-to-be-broken test in t6028 is now fixed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17builtin/merge.c: collect other parents earlyLibravatar Junio C Hamano1-13/+27
Move the code around to populate remoteheads list early in the process before any decision regarding twohead vs octopus and fast-forwardness is made. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17builtin/merge.c: remove "remoteheads" global variableLibravatar Junio C Hamano1-23/+28
Instead pass it around starting from the toplevel cmd_merge() as an explicit parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17fetch: describe new refs based on where it came fromLibravatar Marc Branchaud1-3/+11
update_local_ref() used to say "[new branch]" when we stored a new ref outside refs/tags/ hierarchy, but the message is more about what we fetched, so use the refname at the origin to make that decision. Also, only call a new ref a "branch" if it's under refs/heads/. Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17fetch: Give remote_ref to update_local_ref() as wellLibravatar Marc Branchaud1-1/+2
This way, the function can look at the remote side to adjust the informational message it gives. Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15cherry-pick: do not expect file argumentsLibravatar Clemens Buchacher1-1/+4
If a commit-ish passed to cherry-pick or revert happens to have a file of the same name, git complains that the argument is ambiguous and advises to use '--'. To make things worse, the '--' argument is removed by parse_options, und so passing '--' has no effect. Instead, always interpret cherry-pick/revert arguments as revisions. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-14submodules: recursive fetch also checks new tags for submodule commitsLibravatar Jens Lehmann1-3/+3
Since 88a21979c (fetch/pull: recurse into submodules when necessary) all fetched commits are examined if they contain submodule changes (unless configuration or command line options inhibit that). If a newly recorded submodule commit is not present in the submodule, a fetch is run inside it to download that commit. Checking new refs was done in an else branch where it wasn't executed for tags. This normally isn't a problem because tags are only fetched with the branches they live on, then checking the new commits in the fetched branches for submodule commits will also process all tags. But when a specific tag is fetched (or the refspec contains refs/tags/) commits only reachable by tags won't be searched for submodule commits, which is a bug. Fix that by moving the code outside the if/else construct to handle new tags just like any other ref. The performance impact of adding tags that most of the time lie on a branch which is checked anyway for new submodule commit should be minimal, as since 6859de4 (fetch: avoid quadratic loop checking for updated submodules) all ref-tips are collected first and then fed to a single rev-list. Spotted-by: Jeff King <peff@peff.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11blame: accept --need-minimalLibravatar Junio C Hamano1-0/+1
Between v1.7.1 and v1.7.2, 582aa00bdffb switched the default "diff" invocation not to use XDF_NEED_MINIMAL, but this breaks "git blame" rather badly. Allow the command line option to ask for an extra careful matching. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11gc: do not explode objects which will be immediately prunedLibravatar Jeff King2-10/+38
When we pack everything into one big pack with "git repack -Ad", any unreferenced objects in to-be-deleted packs are exploded into loose objects, with the intent that they will be examined and possibly cleaned up by the next run of "git prune". Since the exploded objects will receive the mtime of the pack from which they come, if the source pack is old, those loose objects will end up pruned immediately. In that case, it is much more efficient to skip the exploding step entirely for these objects. This patch teaches pack-objects to receive the expiration information and avoid writing these objects out. It also teaches "git gc" to pass the value of gc.pruneexpire to repack (which in turn learns to pass it along to pack-objects) so that this optimization happens automatically during "git gc" and "git gc --auto". Signed-off-by: Jeff King <peff@peff.net> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-10rev-parse --show-prefix: add in trailing newlineLibravatar Ross Lagerwall1-0/+2
Print out a trailing newline when --show-prefix is run with cwd at the top level of the tree which results in an empty prefix. Behavior is now like --show-cdup. Fixes an expected failure in t1501. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-09Merge branch 'tr/cache-tree' into maint-1.7.8Libravatar Junio C Hamano2-4/+10
* tr/cache-tree: t0090: be prepared that 'wc -l' writes leading blanks reset: update cache-tree data when appropriate commit: write cache-tree data when writing index anyway Refactor cache_tree_update idiom from commit Test the current state of the cache-tree optimization Add test-scrap-cache-tree