1. 30 Dec, 2013 7 commits
    • Vicent Marti's avatar
      pack-objects: implement bitmap writing · 7cc8f971
      Vicent Marti authored
      This commit extends more the functionality of `pack-objects` by allowing
      it to write out a `.bitmap` index next to any written packs, together
      with the `.idx` index that currently gets written.
      If bitmap writing is enabled for a given repository (either by calling
      `pack-objects` with the `--write-bitmap-index` flag or by having
      `pack.writebitmaps` set to `true` in the config) and pack-objects is
      writing a packfile that would normally be indexed (i.e. not piping to
      stdout), we will attempt to write the corresponding bitmap index for the
      Bitmap index writing happens after the packfile and its index has been
      successfully written to disk (`finish_tmp_packfile`). The process is
      performed in several steps:
          1. `bitmap_writer_set_checksum`: this call stores the partial
             checksum for the packfile being written; the checksum will be
             written in the resulting bitmap index to verify its integrity
          2. `bitmap_writer_build_type_index`: this call uses the array of
             `struct object_entry` that has just been sorted when writing out
             the actual packfile index to disk to generate 4 type-index bitmaps
             (one for each object type).
             These bitmaps have their nth bit set if the given object is of
             the bitmap's type. E.g. the nth bit of the Commits bitmap will be
             1 if the nth object in the packfile index is a commit.
             This is a very cheap operation because the bitmap writing code has
             access to the metadata stored in the `struct object_entry` array,
             and hence the real type for each object in the packfile.
          3. `bitmap_writer_reuse_bitmaps`: if there exists an existing bitmap
             index for one of the packfiles we're trying to repack, this call
             will efficiently rebuild the existing bitmaps so they can be
             reused on the new index. All the existing bitmaps will be stored
             in a `reuse` hash table, and the commit selection phase will
             prioritize these when selecting, as they can be written directly
             to the new index without having to perform a revision walk to
             fill the bitmap. This can greatly speed up the repack of a
             repository that already has bitmaps.
          4. `bitmap_writer_select_commits`: if bitmap writing is enabled for
             a given `pack-objects` run, the sequence of commits generated
             during the Counting Objects phase will be stored in an array.
             We then use that array to build up the list of selected commits.
             Writing a bitmap in the index for each object in the repository
             would be cost-prohibitive, so we use a simple heuristic to pick
             the commits that will be indexed with bitmaps.
             The current heuristics are a simplified version of JGit's
             original implementation. We select a higher density of commits
             depending on their age: the 100 most recent commits are always
             selected, after that we pick 1 commit of each 100, and the gap
             increases as the commits grow older. On top of that, we make sure
             that every single branch that has not been merged (all the tips
             that would be required from a clone) gets their own bitmap, and
             when selecting commits between a gap, we tend to prioritize the
             commit with the most parents.
             Do note that there is no right/wrong way to perform commit
             selection; different selection algorithms will result in
             different commits being selected, but there's no such thing as
             "missing a commit". The bitmap walker algorithm implemented in
             `prepare_bitmap_walk` is able to adapt to missing bitmaps by
             performing manual walks that complete the bitmap: the ideal
             selection algorithm, however, would select the commits that are
             more likely to be used as roots for a walk in the future (e.g.
             the tips of each branch, and so on) to ensure a bitmap for them
             is always available.
          5. `bitmap_writer_build`: this is the computationally expensive part
             of bitmap generation. Based on the list of commits that were
             selected in the previous step, we perform several incremental
             walks to generate the bitmap for each commit.
             The walks begin from the oldest commit, and are built up
             incrementally for each branch. E.g. consider this dag where A, B,
             C, D, E, F are the selected commits, and a, b, c, e are a chunk
             of simplified history that will not receive bitmaps.
             We start by building the bitmap for A, using A as the root for a
             revision walk and marking all the objects that are reachable
             until the walk is over. Once this bitmap is stored, we reuse the
             bitmap walker to perform the walk for B, assuming that once we
             reach A again, the walk will be terminated because A has already
             been SEEN on the previous walk.
             This process is repeated for C, and D, but when we try to
             generate the bitmaps for E, we can reuse neither the current walk
             nor the bitmap we have generated so far.
             What we do now is resetting both the walk and clearing the
             bitmap, and performing the walk from scratch using E as the
             origin. This new walk, however, does not need to be completed.
             Once we hit B, we can lookup the bitmap we have already stored
             for that commit and OR it with the existing bitmap we've composed
             so far, allowing us to limit the walk early.
             After all the bitmaps have been generated, another iteration
             through the list of commits is performed to find the best XOR
             offsets for compression before writing them to disk. Because of
             the incremental nature of these bitmaps, XORing one of them with
             its predecesor results in a minimal "bitmap delta" most of the
             time. We can write this delta to the on-disk bitmap index, and
             then re-compose the original bitmaps by XORing them again when
             This is a phase very similar to pack-object's `find_delta` (using
             bitmaps instead of objects, of course), except the heuristics
             have been greatly simplified: we only check the 10 bitmaps before
             any given one to find best compressing one. This gives good
             results in practice, because there is locality in the ordering of
             the objects (and therefore bitmaps) in the packfile.
           6. `bitmap_writer_finish`: the last step in the process is
      	serializing to disk all the bitmap data that has been generated
      	in the two previous steps.
      	The bitmap is written to a tmp file and then moved atomically to
      	its final destination, using the same process as
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Vicent Marti's avatar
      rev-list: add bitmap mode to speed up object lists · aa32939f
      Vicent Marti authored
      The bitmap reachability index used to speed up the counting objects
      phase during `pack-objects` can also be used to optimize a normal
      rev-list if the only thing required are the SHA1s of the objects during
      the list (i.e., not the path names at which trees and blobs were found).
      Calling `git rev-list --objects --use-bitmap-index [committish]` will
      perform an object iteration based on a bitmap result instead of actually
      walking the object graph.
      These are some example timings for `torvalds/linux` (warm cache,
          $ time git rev-list --objects master > /dev/null
          real    0m34.191s
          user    0m33.904s
          sys     0m0.268s
          $ time git rev-list --objects --use-bitmap-index master > /dev/null
          real    0m1.041s
          user    0m0.976s
          sys     0m0.064s
      Likewise, using `git rev-list --count --use-bitmap-index` will speed up
      the counting operation by building the resulting bitmap and performing a
      fast popcount (number of bits set on the bitmap) on the result.
      Here are some sample timings of different ways to count commits in
          $ time git rev-list master | wc -l
              real    0m6.524s
              user    0m6.060s
              sys     0m3.284s
          $ time git rev-list --count master
              real    0m4.318s
              user    0m4.236s
              sys     0m0.076s
          $ time git rev-list --use-bitmap-index --count master
              real    0m0.217s
              user    0m0.176s
              sys     0m0.040s
      This also respects negative refs, so you can use it to count
      a slice of history:
              $ time git rev-list --count v3.0..master
              real    0m1.971s
              user    0m1.932s
              sys     0m0.036s
              $ time git rev-list --use-bitmap-index --count v3.0..master
              real    0m0.280s
              user    0m0.220s
              sys     0m0.056s
      Though note that the closer the endpoints, the less it helps. In the
      traversal case, we have fewer commits to cross, so we take less time.
      But the bitmap time is dominated by generating the pack revindex, which
      is constant with respect to the refs given.
      Note that you cannot yet get a fast --left-right count of a symmetric
      difference (e.g., "--count --left-right master...topic"). The slow part
      of that walk actually happens during the merge-base determination when
      we parse "master...topic". Even though a count does not actually need to
      know the real merge base (it only needs to take the symmetric difference
      of the bitmaps), the revision code would require some refactoring to
      handle this case.
      Additionally, a `--test-bitmap` flag has been added that will perform
      the same rev-list manually (i.e. using a normal revwalk) and using
      bitmaps, and verify that the results are the same. This can be used to
      exercise the bitmap code, and also to verify that the contents of the
      .bitmap file are sane.
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Vicent Marti's avatar
      pack-objects: use bitmaps when packing objects · 6b8fda2d
      Vicent Marti authored
      In this patch, we use the bitmap API to perform the `Counting Objects`
      phase in pack-objects, rather than a traditional walk through the object
      graph. For a reasonably-packed large repo, the time to fetch and clone
      is often dominated by the full-object revision walk during the Counting
      Objects phase. Using bitmaps can reduce the CPU time required on the
      server (and therefore start sending the actual pack data with less
      For bitmaps to be used, the following must be true:
        1. We must be packing to stdout (as a normal `pack-objects` from
           `upload-pack` would do).
        2. There must be a .bitmap index containing at least one of the
           "have" objects that the client is asking for.
        3. Bitmaps must be enabled (they are enabled by default, but can be
           disabled by setting `pack.usebitmaps` to false, or by using
           `--no-use-bitmap-index` on the command-line).
      If any of these is not true, we fall back to doing a normal walk of the
      object graph.
      Here are some sample timings from a full pack of `torvalds/linux` (i.e.
      something very similar to what would be generated for a clone of the
      repository) that show the speedup produced by various
          [existing graph traversal]
          $ time git pack-objects --all --stdout --no-use-bitmap-index \
      			    </dev/null >/dev/null
          Counting objects: 3237103, done.
          Compressing objects: 100% (508752/508752), done.
          Total 3237103 (delta 2699584), reused 3237103 (delta 2699584)
          real    0m44.111s
          user    0m42.396s
          sys     0m3.544s
          [bitmaps only, without partial pack reuse; note that
           pack reuse is automatic, so timing this required a
           patch to disable it]
          $ time git pack-objects --all --stdout </dev/null >/dev/null
          Counting objects: 3237103, done.
          Compressing objects: 100% (508752/508752), done.
          Total 3237103 (delta 2699584), reused 3237103 (delta 2699584)
          real    0m5.413s
          user    0m5.604s
          sys     0m1.804s
          [bitmaps with pack reuse (what you get with this patch)]
          $ time git pack-objects --all --stdout </dev/null >/dev/null
          Reusing existing pack: 3237103, done.
          Total 3237103 (delta 0), reused 0 (delta 0)
          real    0m1.636s
          user    0m1.460s
          sys     0m0.172s
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pack-objects: split add_object_entry · ce2bc424
      Jeff King authored
      This function actually does three things:
        1. Check whether we've already added the object to our
           packing list.
        2. Check whether the object meets our criteria for adding.
        3. Actually add the object to our packing list.
      It's a little hard to see these three phases, because they
      happen linearly in the rather long function. Instead, this
      patch breaks them up into three separate helper functions.
      The result is a little easier to follow, though it
      unfortunately suffers from some optimization
      interdependencies between the stages (e.g., during step 3 we
      use the packing list index from step 1 and the packfile
      information from step 2).
      More importantly, though, the various parts can be
      composed differently, as they will be in the next patch.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Vicent Marti's avatar
      pack-bitmap: add support for bitmap indexes · fff42755
      Vicent Marti authored
      A bitmap index is a `.bitmap` file that can be found inside
      `$GIT_DIR/objects/pack/`, next to its corresponding packfile, and
      contains precalculated reachability information for selected commits.
      The full specification of the format for these bitmap indexes can be found
      in `Documentation/technical/bitmap-format.txt`.
      For a given commit SHA1, if it happens to be available in the bitmap
      index, its bitmap will represent every single object that is reachable
      from the commit itself. The nth bit in the bitmap is the nth object in
      the packfile; if it's set to 1, the object is reachable.
      By using the bitmaps available in the index, this commit implements
      several new functions:
      	- `prepare_bitmap_git`
      	- `prepare_bitmap_walk`
      	- `traverse_bitmap_commit_list`
      	- `reuse_partial_packfile_from_bitmap`
      The `prepare_bitmap_walk` function tries to build a bitmap of all the
      objects that can be reached from the commit roots of a given `rev_info`
      struct by using the following algorithm:
      - If all the interesting commits for a revision walk are available in
      the index, the resulting reachability bitmap is the bitwise OR of all
      the individual bitmaps.
      - When the full set of WANTs is not available in the index, we perform a
      partial revision walk using the commits that don't have bitmaps as
      roots, and limiting the revision walk as soon as we reach a commit that
      has a corresponding bitmap. The earlier OR'ed bitmap with all the
      indexed commits can now be completed as this walk progresses, so the end
      result is the full reachability list.
      - For revision walks with a HAVEs set (a set of commits that are deemed
      uninteresting), first we perform the same method as for the WANTs, but
      using our HAVEs as roots, in order to obtain a full reachability bitmap
      of all the uninteresting commits. This bitmap then can be used to:
      	a) limit the subsequent walk when building the WANTs bitmap
      	b) finding the final set of interesting commits by performing an
      	   AND-NOT of the WANTs and the HAVEs.
      If `prepare_bitmap_walk` runs successfully, the resulting bitmap is
      stored and the equivalent of a `traverse_commit_list` call can be
      performed by using `traverse_bitmap_commit_list`; the bitmap version
      of this call yields the objects straight from the packfile index
      (without having to look them up or parse them) and hence is several
      orders of magnitude faster.
      As an extra optimization, when `prepare_bitmap_walk` succeeds, the
      `reuse_partial_packfile_from_bitmap` call can be attempted: it will find
      the amount of objects at the beginning of the on-disk packfile that can
      be reused as-is, and return an offset into the packfile. The source
      packfile can then be loaded and the bytes up to `offset` can be written
      directly to the result without having to consider the entires inside the
      packfile individually.
      If the `prepare_bitmap_walk` call fails (e.g. because no bitmap files
      are available), the `rev_info` struct is left untouched, and can be used
      to perform a manual rev-walk using `traverse_commit_list`.
      Hence, this new set of functions are a generic API that allows to
      perform the equivalent of
      	git rev-list --objects [roots...] [^uninteresting...]
      for any set of commits, even if they don't have specific bitmaps
      generated for them.
      In further patches, we'll use this bitmap traversal optimization to
      speed up the `pack-objects` and `rev-list` commands.
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Vicent Marti's avatar
      documentation: add documentation for the bitmap format · 0d4455a3
      Vicent Marti authored
      This is the technical documentation for the JGit-compatible Bitmap v1
      on-disk format.
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Vicent Marti's avatar
      ewah: compressed bitmap implementation · e1273106
      Vicent Marti authored
      EWAH is a word-aligned compressed variant of a bitset (i.e. a data
      structure that acts as a 0-indexed boolean array for many entries).
      It uses a 64-bit run-length encoding (RLE) compression scheme,
      trading some compression for better processing speed.
      The goal of this word-aligned implementation is not to achieve
      the best compression, but rather to improve query processing time.
      As it stands right now, this EWAH implementation will always be more
      efficient storage-wise than its uncompressed alternative.
      EWAH arrays will be used as the on-disk format to store reachability
      bitmaps for all objects in a repository while keeping reasonable sizes,
      in the same way that JGit does.
      This EWAH implementation is a mostly straightforward port of the
      original `javaewah` library that JGit currently uses. The library is
      self-contained and has been embedded whole (4 files) inside the `ewah`
      folder to ease redistribution.
      The library is re-licensed under the GPLv2 with the permission of Daniel
      Lemire, the original author. The source code for the C version can
      be found on GitHub:
      The original Java implementation can also be found on GitHub:
      [jc: stripped debug-only code per Peff's $gmane/239768]
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Helped-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 18 Nov, 2013 1 commit
    • Vicent Marti's avatar
      compat: add endianness helpers · 7e3dae49
      Vicent Marti authored
      The POSIX standard doesn't currently define a `ntohll`/`htonll`
      function pair to perform network-to-host and host-to-network
      swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk
      storage of EWAH bitmaps if they are not in native byte order.
      Many thanks to Ramsay Jones <ramsay@ramsay1.demon.co.uk> and
      Torsten Bögershausen <tboegi@web.de> for cygwin/mingw/msvc
      portability fixes.
      Signed-off-by: default avatarVicent Marti <tanoku@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 24 Oct, 2013 6 commits
  4. 23 Oct, 2013 12 commits
    • Junio C Hamano's avatar
      Update draft release notes to 1.8.5 · 3d092bfc
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Junio C Hamano's avatar
      Sync with 'maint' · ea21efc7
      Junio C Hamano authored
    • Junio C Hamano's avatar
      Almost ;-) · ca462804
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Junio C Hamano's avatar
      Merge branch 'jc/ls-files-killed-optim' into maint · e03a5010
      Junio C Hamano authored
      "git ls-files -k" needs to crawl only the part of the working tree
      that may overlap the paths in the index to find killed files, but
      shared code with the logic to find all the untracked files, which
      made it unnecessarily inefficient.
      * jc/ls-files-killed-optim:
        dir.c::test_one_path(): work around directory_exists_in_index_icase() breakage
        t3010: update to demonstrate "ls-files -k" optimization pitfalls
        ls-files -k: a directory only can be killed if the index has a non-directory
        dir.c: use the cache_* macro to access the current index
    • Junio C Hamano's avatar
      Merge branch 'jh/checkout-auto-tracking' into maint · 74051fa8
      Junio C Hamano authored
      "git branch --track" had a minor regression in v1.8.3.2 and later
      that made it impossible to base your local work on anything but a
      local branch of the upstream repository you are tracking from.
      * jh/checkout-auto-tracking:
        t3200: fix failure on case-insensitive filesystems
        branch.c: Relax unnecessary requirement on upstream's remote ref name
        t3200: Add test demonstrating minor regression in 41c21f22
        Refer to branch.<name>.remote/merge when documenting --track
        t3200: Minor fix when preparing for tracking failure
        t2024: Fix &&-chaining and a couple of typos
    • Junio C Hamano's avatar
      Merge branch 'nd/fetch-into-shallow' into maint · 6ba0d955
      Junio C Hamano authored
      When there is no sufficient overlap between old and new history
      during a "git fetch" into a shallow repository, objects that the
      sending side knows the receiving end has were unnecessarily sent.
      * nd/fetch-into-shallow:
        Add testcase for needless objects during a shallow fetch
        list-objects: mark more commits as edges in mark_edges_uninteresting
        list-objects: reduce one argument in mark_edges_uninteresting
        upload-pack: delegate rev walking in shallow fetch to pack-objects
        shallow: add setup_temporary_shallow()
        shallow: only add shallow graft points to new shallow file
        move setup_alternate_shallow and write_shallow_commits to shallow.c
    • Junio C Hamano's avatar
      Merge branch 'bc/gnome-keyring' · 26145c9c
      Junio C Hamano authored
      Cleanups and tweaks for credential handling to work with ancient versions
      of the gnome-keyring library that are still in use.
      * bc/gnome-keyring:
        contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring
        contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring
        contrib/git-credential-gnome-keyring.c: report failure to store password
        contrib/git-credential-gnome-keyring.c: use glib messaging functions
        contrib/git-credential-gnome-keyring.c: use glib memory allocation functions
        contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords
        contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds
        contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object()
        contrib/git-credential-gnome-keyring.c: set Gnome application name
        contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing
        contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t
        contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly
        contrib/git-credential-gnome-keyring.c: add static where applicable
        contrib/git-credential-gnome-keyring.c: *style* use "if ()" not "if()" etc.
        contrib/git-credential-gnome-keyring.c: remove unused die() function
        contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations
    • Junio C Hamano's avatar
      Merge branch 'po/dot-url' · f92f068e
      Junio C Hamano authored
      Explain how '.' can be used to refer to the "current repository"
      in the documentation.
      * po/dot-url:
        doc/cli: make "dot repository" an independent bullet point
        config doc: update dot-repository notes
        doc: command line interface (cli) dot-repository dwimmery
    • Junio C Hamano's avatar
      Merge branch 'jc/prompt-upstream' · 807c895f
      Junio C Hamano authored
      An enhancement to the GIT_PS1_SHOWUPSTREAM facility.
      * jc/prompt-upstream:
        git-prompt.sh: optionally show upstream branch name
    • Junio C Hamano's avatar
      Merge branch 'hu/cherry-pick-previous-branch' · f2c1b01c
      Junio C Hamano authored
      "git cherry-pick" without further options would segfault.
      Could use a follow-up to handle '-' after argv[1] better.
      * hu/cherry-pick-previous-branch:
        cherry-pick: handle "-" after parsing options
    • Junio C Hamano's avatar
      Merge branch 'mg/more-textconv' · 4197361e
      Junio C Hamano authored
      Make "git grep" and "git show" pay attention to --textconv when
      dealing with blob objects.
      * mg/more-textconv:
        grep: honor --textconv for the case rev:path
        grep: allow to use textconv filters
        t7008: demonstrate behavior of grep with textconv
        cat-file: do not die on --textconv without textconv filters
        show: honor --textconv for blobs
        diff_opt: track whether flags have been set explicitly
        t4030: demonstrate behavior of show with textconv
    • Junio C Hamano's avatar
      Merge branch 'jc/pack-objects' · eeb8e837
      Junio C Hamano authored
      * jc/pack-objects:
        pack-objects: shrink struct object_entry
  5. 18 Oct, 2013 8 commits
  6. 17 Oct, 2013 6 commits
    • Junio C Hamano's avatar
      Update draft release notes to 1.8.5 · 2141c474
      Junio C Hamano authored
    • Junio C Hamano's avatar
      Merge branch 'jk/format-patch-from' · 046180ad
      Junio C Hamano authored
      "format-patch --from=<whom>" forgot to omit unnecessary in-body
      from line, i.e. when <whom> is the same as the real author.
      * jk/format-patch-from:
        format-patch: print in-body "From" only when needed
    • Junio C Hamano's avatar
      Merge branch 'es/name-hash-no-trailing-slash-in-dirs' · d6a58b77
      Junio C Hamano authored
      Clean up the internal of the name-hash mechanism used to work
      around case insensitivity on some filesystems to cleanly fix a
      long-standing API glitch where the caller of cache_name_exists()
      that ask about a directory with a counted string was required to
      have '/' at one location past the end of the string.
      * es/name-hash-no-trailing-slash-in-dirs:
        dir: revert work-around for retired dangerous behavior
        name-hash: stop storing trailing '/' on paths in index_state.dir_hash
        employ new explicit "exists in index?" API
        name-hash: refactor polymorphic index_name_exists()
    • Junio C Hamano's avatar
      Merge branch 'jk/trailing-slash-in-pathspec' · be98d915
      Junio C Hamano authored
      Code refactoring.
      * jk/trailing-slash-in-pathspec:
        reset: handle submodule with trailing slash
        rm: re-use parse_pathspec's trailing-slash removal
    • Junio C Hamano's avatar
      Merge branch 'lc/filter-branch-too-many-refs' · f52752d3
      Junio C Hamano authored
      "git filter-branch" in a repository with many refs blew limit of
      command line length.
      * lc/filter-branch-too-many-refs:
        Allow git-filter-branch to process large repositories with lots of branches.
    • Junio C Hamano's avatar
      Merge branch 'jc/checkout-detach-doc' · ff6e1b88
      Junio C Hamano authored
      "git checkout [--detach] <commit>" was listed poorly in the
      synopsis section of its documentation.
      * jc/checkout-detach-doc:
        checkout: update synopsys and documentation on detaching HEAD