summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2014-04-17i18n: only extract comments marked with "TRANSLATORS:"Libravatar Jiang Xin1-5/+3
When extract l10n messages, we use "--add-comments" option to keep comments right above the l10n messages for references. But sometimes irrelevant comments are also extracted. For example in the following code block, the comment in line 2 will be extracted as comment for the l10n message in line 3, but obviously it's wrong. { OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit, NULL /* takes no arguments */, N_("ignore paths removed in the working tree (same as --no-all)"), PARSE_OPT_NOARG, ignore_removal_cb }, Since almost all comments for l10n translators are marked with the same prefix (tag): "TRANSLATORS:", it's safe to only extract comments with this special tag. I.E. it's better to call xgettext as: xgettext --add-comments=TRANSLATORS: ... Also tweaks the multi-line comment in "init-db.c", to make it start with the proper tag, not "* TRANSLATORS:" (which has a star before the tag). Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jk/pack-bitmap'Libravatar Junio C Hamano1-1/+12
* jk/pack-bitmap: pack-objects: do not reuse packfiles without --delta-base-offset add `ignore_missing_links` mode to revwalk
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano6-8/+8
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-08Merge branch 'mh/update-ref-batch-create-fix'Libravatar Junio C Hamano1-0/+1
* mh/update-ref-batch-create-fix: update-ref: fail create operation over stdin if ref already exists
2014-04-08Merge branch 'jc/rev-parse-argh-dashed-multi-words'Libravatar Junio C Hamano7-9/+37
Make sure that the help text given to describe the "<param>" part of the "git cmd --option=<param>" does not contain SP or _, e.g. "--gpg-sign=<key-id>" option for "git commit" is not spelled as "--gpg-sign=<key id>". * jc/rev-parse-argh-dashed-multi-words: parse-options: make sure argh string does not have SP or _ update-index: teach --cacheinfo a new syntax "mode,sha1,path" parse-options: multi-word argh should use dash to separate words
2014-04-04pack-objects: do not reuse packfiles without --delta-base-offsetLibravatar Jeff King1-1/+12
When we are sending a packfile to a remote, we currently try to reuse a whole chunk of packfile without bothering to look at the individual objects. This can make things like initial clones much lighter on the server, as we can just dump the packfile bytes. However, it's possible that the other side cannot read our packfile verbatim. For example, we may have objects stored as OFS_DELTA, but the client is an antique version of git that only understands REF_DELTA. We negotiate this capability over the fetch protocol. A normal pack-objects run will convert OFS_DELTA into REF_DELTA on the fly, but the "reuse pack" code path never even looks at the objects. This patch disables packfile reuse if the other side is missing any capabilities that we might have used in the on-disk pack. Right now the only one is OFS_DELTA, but we may need to expand in the future (e.g., if packv4 introduces new object types). We could be more thorough and only disable reuse in this case when we actually have an OFS_DELTA to send, but: 1. We almost always will have one, since we prefer OFS_DELTA to REF_DELTA when possible. So this case would almost never come up. 2. Looking through the objects defeats the purpose of the optimization, which is to do as little work as possible to get the bytes to the remote. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-03Merge branch 'nd/gc-aggressive'Libravatar Junio C Hamano1-1/+7
Allow tweaking the maximum length of the delta-chain produced by "gc --aggressive". * nd/gc-aggressive: environment.c: fix constness for odb_pack_keep() gc --aggressive: make --depth configurable
2014-04-03Merge branch 'nd/log-show-linear-break'Libravatar Junio C Hamano1-1/+1
Attempts to show where a single-strand-of-pearls break in "git log" output. * nd/log-show-linear-break: log: add --show-linear-break to help see non-linear history object.h: centralize object flag allocation
2014-04-02update-ref: fail create operation over stdin if ref already existsLibravatar Aman Gupta1-0/+1
Signed-off-by: Aman Gupta <aman@tmm1.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'ib/rev-parse-parseopt-argh'Libravatar Junio C Hamano1-1/+12
Teaches the "rev-parse --parseopt" mechanism used by scripted Porcelains to parse command line options and give help text how to supply argv-help (the placeholder string for an option parameter, e.g. "key-id" in "--gpg-sign=<key-id>"). * ib/rev-parse-parseopt-argh: t1502: protect runs of SPs used in the indentation rev-parse --parseopt: option argument name hints
2014-03-31code and test: fix misuses of "nor"Libravatar Justin Lebar2-4/+4
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31comments: fix misuses of "nor"Libravatar Justin Lebar4-4/+4
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31gc --aggressive: make --depth configurableLibravatar Nguyễn Thái Ngọc Duy1-1/+7
When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06) made --depth=250 the default value, it didn't really explain the reason behind, especially the pros and cons of --depth=250. An old mail from Linus below explains it at length. Long story short, --depth=250 is a disk saver and a performance killer. Not everybody agrees on that aggressiveness. Let the user configure it. From: Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] gc --aggressive: make it really aggressive Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST) Message-ID: <alpine.LFD.0.9999.0712060803430.13796@woody.linux-foundation.org> Gmane-URL: http://article.gmane.org/gmane.comp.gcc.devel/94637 On Thu, 6 Dec 2007, Harvey Harrison wrote: > > 7:41:25elapsed 86%CPU Heh. And this is why you want to do it exactly *once*, and then just export the end result for others ;) > -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 pack-1d46...pack But yeah, especially if you allow longer delta chains, the end result can be much smaller (and what makes the one-time repack more expensive is the window size, not the delta chain - you could make the delta chains longer with no cost overhead at packing time) HOWEVER. The longer delta chains do make it potentially much more expensive to then use old history. So there's a trade-off. And quite frankly, a delta depth of 250 is likely going to cause overflows in the delta cache (which is only 256 entries in size *and* it's a hash, so it's going to start having hash conflicts long before hitting the 250 depth limit). So when I said "--depth=250 --window=250", I chose those numbers more as an example of extremely aggressive packing, and I'm not at all sure that the end result is necessarily wonderfully usable. It's going to save disk space (and network bandwidth - the delta's will be re-used for the network protocol too!), but there are definitely downsides too, and using long delta chains may simply not be worth it in practice. (And some of it might just want to have git tuning, ie if people think that long deltas are worth it, we could easily just expand on the delta hash, at the cost of some more memory used!) That said, the good news is that working with *new* history will not be affected negatively, and if you want to be _really_ sneaky, there are ways to say "create a pack that contains the history up to a version one year ago, and be very aggressive about those old versions that we still want to have around, but do a separate pack for newer stuff using less aggressive parameters" So this is something that can be tweaked, although we don't really have any really nice interfaces for stuff like that (ie the git delta cache size is hardcoded in the sources and cannot be set in the config file, and the "pack old history more aggressively" involves some manual scripting and knowing how "git pack-objects" works rather than any nice simple command line switch). So the thing to take away from this is: - git is certainly flexible as hell - .. but to get the full power you may need to tweak things - .. happily you really only need to have one person to do the tweaking, and the tweaked end results will be available to others that do not need to know/care. And whether the difference between 320MB and 500MB is worth any really involved tweaking (considering the potential downsides), I really don't know. Only testing will tell. Linus Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-28Merge branch 'bp/commit-p-editor'Libravatar Junio C Hamano5-17/+38
When it is not necessary to edit a commit log message (e.g. "git commit -m" is given a message without specifying "-e"), we used to disable the spawning of the editor by overriding GIT_EDITOR, but this means all the uses of the editor, other than to edit the commit log message, are also affected. * bp/commit-p-editor: run-command: mark run_hook_with_custom_index as deprecated merge hook tests: fix and update tests merge: fix GIT_EDITOR override for commit hook commit: fix patch hunk editing with "commit -p -m" test patch hunk editing with "commit -p -m" merge hook tests: use 'test_must_fail' instead of '!' merge hook tests: fix missing '&&' in test
2014-03-28Merge branch 'fr/add-interactive-argv-array'Libravatar Junio C Hamano1-11/+10
* fr/add-interactive-argv-array: add: use struct argv_array in run_add_interactive()
2014-03-28Merge branch 'jk/pack-bitmap-progress'Libravatar Junio C Hamano1-11/+19
The progress output while repacking and transferring objects showed an apparent large silence while writing the objects out of existing packfiles, when the reachability bitmap was in use. * jk/pack-bitmap-progress: pack-objects: show reused packfile objects in "Counting objects" pack-objects: show progress for reused packfiles
2014-03-28Merge branch 'jk/pack-bitmap'Libravatar Junio C Hamano1-1/+11
Instead of dying when asked to (re)pack with the reachability bitmap when a bitmap cannot be built, just (re)pack without producing a bitmap in such a case, with a warning. * jk/pack-bitmap: pack-objects: turn off bitmaps when skipping objects
2014-03-25object.h: centralize object flag allocationLibravatar Nguyễn Thái Ngọc Duy1-1/+1
While the field "flags" is mainly used by the revision walker, it is also used in many other places. Centralize the whole flag allocation to one place for a better overview (and easier to move flags if we have too). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-25Merge branch 'nd/index-pack-error-message'Libravatar Junio C Hamano1-2/+2
* nd/index-pack-error-message: index-pack: report error using the correct variable
2014-03-25Merge branch 'nd/commit-editor-cleanup'Libravatar Junio C Hamano1-3/+11
"git commit --cleanup=<mode>" learned a new mode, scissors. * nd/commit-editor-cleanup: commit: add --cleanup=scissors wt-status.c: move cut-line print code out to wt_status_add_cut_line wt-status.c: make cut_line[] const to shrink .data section a bit
2014-03-25Merge branch 'jk/warn-on-object-refname-ambiguity'Libravatar Junio C Hamano1-6/+9
* jk/warn-on-object-refname-ambiguity: rev-list: disable object/refname ambiguity check with --stdin cat-file: restore warn_on_object_refname_ambiguity flag cat-file: fix a minor memory leak in batch_objects cat-file: refactor error handling of batch_objects
2014-03-25Merge branch 'jk/mv-submodules-fix'Libravatar Junio C Hamano1-0/+9
"git mv" that moves a submodule forgot to adjust the array that uses to keep track of which submodules were to be moved to update its configuration. * jk/mv-submodules-fix: mv: prevent mismatched data when ignoring errors. builtin/mv: fix out of bounds write
2014-03-24update-index: teach --cacheinfo a new syntax "mode,sha1,path"Libravatar Junio C Hamano1-3/+31
The "--cacheinfo" option is unusual in that it takes three option parameters. An option with an optional parameter is bad enough. An option with multiple parameters is simply insane. Introduce a new syntax that takes these three things concatenated together with a comma, which makes the command line syntax more uniform across subcommands, while retaining the traditional syntax for backward compatiblity. If we were designing the "update-index" subcommand from scratch today, it may probably have made sense to make this option (and possibly others) a command mode option that does not take any option parameter (hence no need for arg-help). But we do not live in such an ideal world, and as far as I can tell, the command still supports (and must support) mixed command modes in a single invocation, e.g. $ git update-index path1 --add path2 \ --cacheinfo 100644 $(git hash-object --stdin -w <path3) path3 \ path4 must make sure path1 is already in the index and update all of these four paths. So this is probably as far as we can go to fix this issue without risking to break people's existing scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24parse-options: multi-word argh should use dash to separate wordsLibravatar Junio C Hamano6-6/+6
"When you need to use space, use dash" is a strange way to say that you must not use a space. Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places. Rephrase the documentation to avoid this strangeness. Fix a few existing multi-word argument help strings, i.e. - GPG key-ids given to -S/--gpg-sign are "key-id"; - Refs used for storing notes are "notes-ref"; and - Expiry timestamps given to --expire are "expiry-date". and update the corresponding documentation pages. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-23rev-parse --parseopt: option argument name hintsLibravatar Ilya Bobyr1-1/+12
Built-in commands can specify names for option arguments when usage text is generated for a command. sh based commands should be able to do the same. Option argument name hint is any text that comes after [*=?!] after the argument name up to the first whitespace. Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21Merge branch 'nd/upload-pack-shallow'Libravatar Junio C Hamano1-0/+10
Serving objects from a shallow repository needs to write a temporary file to be used, but the serving upload-pack may not have write access to the repository which is meant to be read-only. Instead feed these temporary shallow bounds from the standard input of pack-objects so that we do not have to use a temporary file. * nd/upload-pack-shallow: upload-pack: send shallow info over stdin to pack-objects
2014-03-21Merge branch 'nd/tag-version-sort'Libravatar Junio C Hamano1-5/+66
Allow v1.9.0 sorted before v1.10.0 in "git tag --list" output. * nd/tag-version-sort: tag: support --sort=<spec>
2014-03-21Merge branch 'jk/shallow-update-fix'Libravatar Junio C Hamano1-12/+4
Serving objects from a shallow repository needs to write a new file to hold the temporary shallow boundaries but it was not cleaned when we exit due to die() or a signal. * jk/shallow-update-fix: shallow: verify shallow file after taking lock shallow: automatically clean up shallow tempfiles shallow: use stat_validity to check for up-to-date file
2014-03-18Merge branch 'jk/clean-d-pathspec' into maintLibravatar Junio C Hamano1-11/+9
"git clean -d pathspec" did not use the given pathspec correctly and ended up cleaning too much. * jk/clean-d-pathspec: clean: simplify dir/not-dir logic clean: respect pathspecs with "-d"
2014-03-18Merge branch 'nd/reset-setup-worktree' into maintLibravatar Junio C Hamano1-3/+4
"git reset" needs to refresh the index when working in a working tree (it can also be used to match the index to the HEAD in an otherwise bare repository), but it failed to set up the working tree properly, causing GIT_WORK_TREE to be ignored. * nd/reset-setup-worktree: reset: optionally setup worktree and refresh index on --mixed
2014-03-18Merge branch 'jc/check-attr-honor-working-tree' into maintLibravatar Junio C Hamano1-0/+3
"git check-attr" when working on a repository with a working tree did not work well when the working tree was specified via the --work-tree (and obviously with --git-dir) option. * jc/check-attr-honor-working-tree: check-attr: move to the top of working tree when in non-bare repository t0003: do not chdir the whole test process
2014-03-18Merge branch 'ds/rev-parse-required-args' into maintLibravatar Junio C Hamano1-6/+11
"git rev-parse" was loose in rejecting command line arguments that do not make sense, e.g. "--default" without the required value for that option. * ds/rev-parse-required-args: rev-parse: check i before using argv[i] against argc
2014-03-18Merge branch 'nd/submodule-pathspec-ending-with-slash' into maintLibravatar Junio C Hamano9-36/+18
Allow "git cmd path/", when the 'path' is where a submodule is bound to the top-level working tree, to match 'path', despite the extra and unnecessary trailing slash (such a slash is often given by command line completion). * nd/submodule-pathspec-ending-with-slash: clean: use cache_name_is_other() clean: replace match_pathspec() with dir_path_match() pathspec: pass directory indicator to match_pathspec_item() match_pathspec: match pathspec "foo/" against directory "foo" dir.c: prepare match_pathspec_item for taking more flags pathspec: rename match_pathspec_depth() to match_pathspec() pathspec: convert some match_pathspec_depth() to dir_path_match() pathspec: convert some match_pathspec_depth() to ce_path_match()
2014-03-18Merge branch 'jc/tag-contains-with'Libravatar Junio C Hamano1-0/+6
* jc/tag-contains-with: tag: grok "--with" as synonym to "--contains"
2014-03-18Merge branch 'jk/repack-pack-keep-objects'Libravatar Junio C Hamano1-1/+12
* jk/repack-pack-keep-objects: repack: add `repack.packKeptObjects` config var
2014-03-18Merge branch 'sh/finish-tmp-packfile'Libravatar Junio C Hamano1-9/+6
* sh/finish-tmp-packfile: finish_tmp_packfile():use strbuf for pathname construction
2014-03-18Merge branch 'dd/use-alloc-grow'Libravatar Junio C Hamano2-10/+4
Replace open-coded reallocation with ALLOC_GROW() macro. * dd/use-alloc-grow: sha1_file.c: use ALLOC_GROW() in pretend_sha1_file() read-cache.c: use ALLOC_GROW() in add_index_entry() builtin/mktree.c: use ALLOC_GROW() in append_to_tree() attr.c: use ALLOC_GROW() in handle_attr_line() dir.c: use ALLOC_GROW() in create_simplify() reflog-walk.c: use ALLOC_GROW() replace_object.c: use ALLOC_GROW() in register_replace_object() patch-ids.c: use ALLOC_GROW() in add_commit() diffcore-rename.c: use ALLOC_GROW() diff.c: use ALLOC_GROW() commit.c: use ALLOC_GROW() in register_commit_graft() cache-tree.c: use ALLOC_GROW() in find_subtree() bundle.c: use ALLOC_GROW() in add_to_ref_list() builtin/pack-objects.c: use ALLOC_GROW() in check_pbase_path()
2014-03-18Merge branch 'jk/clean-d-pathspec'Libravatar Junio C Hamano1-11/+9
"git clean -d pathspec" did not use the given pathspec correctly and ended up cleaning too much. * jk/clean-d-pathspec: clean: simplify dir/not-dir logic clean: respect pathspecs with "-d"
2014-03-18add: use struct argv_array in run_add_interactive()Libravatar Fabian Ruch1-11/+10
run_add_interactive() in builtin/add.c manually computes array bounds and allocates a static args array to build the add--interactive command line, which is error-prone. Use the argv-array helper functions instead. Signed-off-by: Fabian Ruch <bafain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18merge: fix GIT_EDITOR override for commit hookLibravatar Benoit Pierre1-1/+1
Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the editor is going to be called (e.g. with "merge -e"). Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18commit: fix patch hunk editing with "commit -p -m"Libravatar Benoit Pierre5-17/+38
Don't change git environment: move the GIT_EDITOR=":" override to the hook command subprocess, like it's already done for GIT_INDEX_FILE. Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17index-pack: report error using the correct variableLibravatar Junio C Hamano1-2/+2
We feed a string pointer that is potentially NULL to die() when showing the message. Don't. Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: turn off bitmaps when skipping objectsLibravatar Jeff King1-1/+11
The pack bitmap format requires that we have a single bit for each object in the pack, and that each object's bitmap represents its complete set of reachable objects. Therefore we have no way to represent the bitmap of an object which references objects outside the pack. We notice this problem while generating the bitmaps, as we try to find the offset of a particular object and realize that we do not have it. In this case we die, and neither the bitmap nor the pack is generated. This is correct, but perhaps a little unfriendly. If you have bitmaps turned on in the config, many repacks will fail which would otherwise succeed. E.g., incremental repacks, repacks with "-l" when you have alternates, ".keep" files. Instead, this patch notices early that we are omitting some objects from the pack and turns off bitmaps (with a warning). Note that this is not strictly correct, as it's possible that the object being omitted is not reachable from any other object in the pack. In practice, this is almost never the case, and there are two advantages to doing it this way: 1. The code is much simpler, as we do not have to cleanly abort the bitmap-generation process midway through. 2. We do not waste time partially generating bitmaps only to find out that some object deep in the history is not being packed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: show reused packfile objects in "Counting objects"Libravatar Jeff King1-8/+3
When we are sending a pack for push or fetch, we may reuse a chunk of packfile without even parsing it. The progress meter then looks like this: Reusing existing pack: 3440489, done. Counting objects: 3, done. The first line shows that we are reusing a large chunk of objects, and then we further count any objects not included in the reused portion with an actual traversal. These are all implementation details that the user does not need to care about. Instead, we can show the reused objects in the normal "counting..." progress meter (which will simply go much faster than normal), and then continue to add to it as we traverse. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: show progress for reused packfilesLibravatar Jeff King1-3/+16
When the "--all-progress" option is in effect, pack-objects shows a progress report for the "writing" phase. If the repository has bitmaps and we are reusing a packfile, the user sees no progress update until the whole packfile is sent. Since this is typically the bulk of what is being written, it can look like git hangs during this phase, even though the transfer is proceeding. This generally only happens with "git push" from a repository with bitmaps. We do not use "--all-progress" for fetch (since the result is going to index-pack on the client, which takes care of progress reporting). And for regular repacks to disk, we do not reuse packfiles. We already have the progress meter setup during write_reused_pack; we just need to call display_progress whiel we are writing out the pack. The progress meter is attached to our output descriptor, so it automatically handles the throughput measurements. However, we need to update the object count as we go, since that is what feeds the percentage we show. We aren't actually parsing the packfile as we send it, so we have no idea how many objects we have sent; we only know that at the end of N bytes, we will have sent M objects. So we cheat a little and assume each object is M/N bytes (i.e., the mean of the objects we are sending). While this isn't strictly true, it actually produces a more pleasing progress meter for the user, as it moves smoothly and predictably (and nobody really cares about the object count; they care about the percentage, and the object count is a proxy for that). One alternative would be to actually show two progress meters: one for the reused pack, and one for the rest of the objects. That would more closely reflect the data we have (the first would be measured in bytes, and the second measured in objects). But it would also be more complex and annoying to the user; rather than seeing one progress meter counting up to 100%, they would finish one meter, then start another one at zero. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17mv: prevent mismatched data when ignoring errors.Libravatar brian m. carlson1-0/+5
We shrink the source and destination arrays, but not the modes or submodule_gitfile arrays, resulting in potentially mismatched data. Shrink all the arrays at the same time to prevent this. Add tests to ensure the problem does not recur. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14Merge branch 'sh/write-pack-file-warning-message-fix'Libravatar Junio C Hamano1-1/+1
A warning from "git pack-objects" were generated by referring to an incorrect variable when forming the filename that we had trouble with. * sh/write-pack-file-warning-message-fix: write_pack_file: use correct variable in diagnostic
2014-03-14Merge branch 'mh/replace-refs-variable-rename'Libravatar Junio C Hamano6-6/+6
* mh/replace-refs-variable-rename: Document some functions defined in object.c Add docstrings for lookup_replace_object() and do_lookup_replace_object() rename read_replace_refs to check_replace_refs
2014-03-14Merge branch 'nd/i18n-progress'Libravatar Junio C Hamano5-9/+9
Mark the progress indicators from various time-consuming commands for i18n/l10n. * nd/i18n-progress: i18n: mark all progress lines for translation
2014-03-14Merge branch 'jh/note-trees-record-blobs'Libravatar Junio C Hamano1-1/+5
"git notes -C <blob>" should not take an object that is not a blob. * jh/note-trees-record-blobs: notes: disallow reusing non-blob as a note object