1. 15 1月, 2019 1 次提交
  2. 14 11月, 2018 1 次提交
    • N
      checkout: disambiguate dwim tracking branches and local files · be4908f1
      Nguyễn Thái Ngọc Duy 提交于
      When checkout dwim is added in [1], it is restricted to only dwim when
      certain conditions are met and fall back to default checkout behavior
      otherwise. It turns out falling back could be confusing. One of the
      conditions to turn
      
          git checkout frotz
      
      to
      
          git checkout -b frotz origin/frotz
      
      is that frotz must not exist as a file. But when the user comes to
      expect "git checkout frotz" to create the branch "frotz" and there
      happens to be a file named "frotz", git's silently reverting "frotz"
      file content is not helping. This is reported in Git mailing list [2]
      and even used as an example of "Git is bad" elsewhere [3].
      
      We normally try to do the right thing, but when there are multiple
      "right things" to do, it's best to leave it to the user to decide.
      Check this case, ask the user to to disambiguate:
      
      - "git checkout -- foo" will check out path "foo"
      - "git checkout foo --" will dwim and create branch "foo" [4]
      
      For users who do not want dwim, use --no-guess. It's useless in this
      particular case because "git checkout --no-guess foo --" will just
      fail. But it could be used by scripts.
      
      [1] 70c9ac2f (DWIM "git checkout frotz" to "git checkout -b frotz
          origin/frotz" - 2009-10-18)
      [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/
      [3] https://news.ycombinator.com/item?id=18230655
      [4] a047fafc (checkout: allow dwim for branch creation for "git
          checkout $branch --" - 2013-10-18)
      Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      be4908f1
  3. 12 11月, 2018 1 次提交
  4. 04 10月, 2018 1 次提交
  5. 22 9月, 2018 2 次提交
  6. 30 8月, 2018 1 次提交
    • J
      convert "oidcmp() == 0" to oideq() · 4a7e27e9
      Jeff King 提交于
      Using the more restrictive oideq() should, in the long run,
      give the compiler more opportunities to optimize these
      callsites. For now, this conversion should be a complete
      noop with respect to the generated code.
      
      The result is also perhaps a little more readable, as it
      avoids the "zero is equal" idiom. Since it's so prevalent in
      C, I think seasoned programmers tend not to even notice it
      anymore, but it can sometimes make for awkward double
      negations (e.g., we can drop a few !!oidcmp() instances
      here).
      
      This patch was generated almost entirely by the included
      coccinelle patch. This mechanical conversion should be
      completely safe, because we check explicitly for cases where
      oidcmp() is compared to 0, which is what oideq() is doing
      under the hood. Note that we don't have to catch "!oidcmp()"
      separately; coccinelle's standard isomorphisms make sure the
      two are treated equivalently.
      
      I say "almost" because I did hand-edit the coccinelle output
      to fix up a few style violations (it mostly keeps the
      original formatting, but sometimes unwraps long lines).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4a7e27e9
  7. 17 8月, 2018 1 次提交
    • B
      checkout: optimize "git checkout -b <new_branch>" · fa655d84
      Ben Peart 提交于
      Skip merging the commit, updating the index and working directory if and
      only if we are creating a new branch via "git checkout -b <new_branch>."
      Any other checkout options will still go through the former code path.
      
      If sparse_checkout is on, require the user to manually opt in to this
      optimzed behavior by setting the config setting checkout.optimizeNewBranch
      to true as we will no longer update the skip-worktree bit in the index, nor
      add/remove files in the working directory to reflect the current sparse
      checkout settings.
      
      For comparison, running "git checkout -b <new_branch>" on a large repo takes:
      
      14.6 seconds - without this patch
      0.3 seconds - with this patch
      Signed-off-by: NBen Peart <Ben.Peart@microsoft.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      fa655d84
  8. 14 8月, 2018 1 次提交
  9. 24 7月, 2018 1 次提交
    • N
      Update messages in preparation for i18n · 1a07e59c
      Nguyễn Thái Ngọc Duy 提交于
      Many messages will be marked for translation in the following
      commits. This commit updates some of them to be more consistent and
      reduce diff noise in those commits. Changes are
      
      - keep the first letter of die(), error() and warning() in lowercase
      - no full stop in die(), error() or warning() if it's single sentence
        messages
      - indentation
      - some messages are turned to BUG(), or prefixed with "BUG:" and will
        not be marked for i18n
      - some messages are improved to give more information
      - some messages are broken down by sentence to be i18n friendly
        (on the same token, combine multiple warning() into one big string)
      - the trailing \n is converted to printf_ln if possible, or deleted
        if not redundant
      - errno_errno() is used instead of explicit strerror()
      Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1a07e59c
  10. 04 7月, 2018 2 次提交
    • J
      block alloc: add lifecycle APIs for cache_entry structs · a849735b
      Jameson Miller 提交于
      It has been observed that the time spent loading an index with a large
      number of entries is partly dominated by malloc() calls. This change
      is in preparation for using memory pools to reduce the number of
      malloc() calls made to allocate cahce entries when loading an index.
      
      Add an API to allocate and discard cache entries, abstracting the
      details of managing the memory backing the cache entries. This commit
      does actually change how memory is managed - this will be done in a
      later commit in the series.
      
      This change makes the distinction between cache entries that are
      associated with an index and cache entries that are not associated with
      an index. A main use of cache entries is with an index, and we can
      optimize the memory management around this. We still have other cases
      where a cache entry is not persisted with an index, and so we need to
      handle the "transient" use case as well.
      
      To keep the congnitive overhead of managing the cache entries, there
      will only be a single discard function. This means there must be enough
      information kept with the cache entry so that we know how to discard
      them.
      
      A summary of the main functions in the API is:
      
      make_cache_entry: create cache entry for use in an index. Uses specified
                        parameters to populate cache_entry fields.
      
      make_empty_cache_entry: Create an empty cache entry for use in an index.
                              Returns cache entry with empty fields.
      
      make_transient_cache_entry: create cache entry that is not used in an
                                  index. Uses specified parameters to populate
                                  cache_entry fields.
      
      make_empty_transient_cache_entry: create cache entry that is not used in
                                        an index. Returns cache entry with
                                        empty fields.
      
      discard_cache_entry: A single function that knows how to discard a cache
                           entry regardless of how it was allocated.
      Signed-off-by: NJameson Miller <jamill@microsoft.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a849735b
    • J
      read-cache: teach make_cache_entry to take object_id · 825ed4d9
      Jameson Miller 提交于
      Teach make_cache_entry function to take object_id instead of a SHA-1.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      825ed4d9
  11. 30 6月, 2018 1 次提交
  12. 12 6月, 2018 4 次提交
    • Æ
      checkout & worktree: introduce checkout.defaultRemote · 8d7b558b
      Ævar Arnfjörð Bjarmason 提交于
      Introduce a checkout.defaultRemote setting which can be used to
      designate a remote to prefer (via checkout.defaultRemote=origin) when
      running e.g. "git checkout master" to mean origin/master, even though
      there's other remotes that have the "master" branch.
      
      I want this because it's very handy to use this workflow to checkout a
      repository and create a topic branch, then get back to a "master" as
      retrieved from upstream:
      
          (
              cd /tmp &&
              rm -rf tbdiff &&
              git clone git@github.com:trast/tbdiff.git &&
              cd tbdiff &&
              git branch -m topic &&
              git checkout master
          )
      
      That will output:
      
          Branch 'master' set up to track remote branch 'master' from 'origin'.
          Switched to a new branch 'master'
      
      But as soon as a new remote is added (e.g. just to inspect something
      from someone else) the DWIMery goes away:
      
          (
              cd /tmp &&
              rm -rf tbdiff &&
              git clone git@github.com:trast/tbdiff.git &&
              cd tbdiff &&
              git branch -m topic &&
              git remote add avar git@github.com:avar/tbdiff.git &&
              git fetch avar &&
              git checkout master
          )
      
      Will output (without the advice output added earlier in this series):
      
          error: pathspec 'master' did not match any file(s) known to git.
      
      The new checkout.defaultRemote config allows me to say that whenever
      that ambiguity comes up I'd like to prefer "origin", and it'll still
      work as though the only remote I had was "origin".
      
      Also adjust the advice.checkoutAmbiguousRemoteBranchName message to
      mention this new config setting to the user, the full output on my
      git.git is now (the last paragraph is new):
      
          $ ./git --exec-path=$PWD checkout master
          error: pathspec 'master' did not match any file(s) known to git.
          hint: 'master' matched more than one remote tracking branch.
          hint: We found 26 remotes with a reference that matched. So we fell back
          hint: on trying to resolve the argument as a path, but failed there too!
          hint:
          hint: If you meant to check out a remote tracking branch on, e.g. 'origin',
          hint: you can do so by fully qualifying the name with the --track option:
          hint:
          hint:     git checkout --track origin/<name>
          hint:
          hint: If you'd like to always have checkouts of an ambiguous <name> prefer
          hint: one remote, e.g. the 'origin' remote, consider setting
          hint: checkout.defaultRemote=origin in your config.
      
      I considered splitting this into checkout.defaultRemote and
      worktree.defaultRemote, but it's probably less confusing to break our
      own rules that anything shared between config should live in core.*
      than have two config settings, and I couldn't come up with a short
      name under core.* that made sense (core.defaultRemoteForCheckout?).
      
      See also 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b
      frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature
      to begin with, and 4e853331 ("worktree: make add <path> <branch>
      dwim", 2017-11-26) which added it to git-worktree.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8d7b558b
    • Æ
      checkout: add advice for ambiguous "checkout <branch>" · ad8d5104
      Ævar Arnfjörð Bjarmason 提交于
      As the "checkout" documentation describes:
      
          If <branch> is not found but there does exist a tracking branch in
          exactly one remote (call it <remote>) with a matching name, treat
          as equivalent to [...] <remote>/<branch.
      
      This is a really useful feature. The problem is that when you add
      another remote (e.g. a fork), git won't find a unique branch name
      anymore, and will instead print this unhelpful message:
      
          $ git checkout master
          error: pathspec 'master' did not match any file(s) known to git
      
      Now it will, on my git.git checkout, print:
      
          $ ./git --exec-path=$PWD checkout master
          error: pathspec 'master' did not match any file(s) known to git.
          hint: 'master' matched more than one remote tracking branch.
          hint: We found 26 remotes with a reference that matched. So we fell back
          hint: on trying to resolve the argument as a path, but failed there too!
          hint:
          hint: If you meant to check out a remote tracking branch on, e.g. 'origin',
          hint: you can do so by fully qualifying the name with the --track option:
          hint:
          hint:     git checkout --track origin/<name>
      
      Note that the "error: pathspec[...]" message is still printed. This is
      because whatever else checkout may have tried earlier, its final
      fallback is to try to resolve the argument as a path. E.g. in this
      case:
      
          $ ./git --exec-path=$PWD checkout master pu
          error: pathspec 'master' did not match any file(s) known to git.
          error: pathspec 'pu' did not match any file(s) known to git.
      
      There we don't print the "hint:" implicitly due to earlier logic
      around the DWIM fallback. That fallback is only used if it looks like
      we have one argument that might be a branch.
      
      I can't think of an intrinsic reason for why we couldn't in some
      future change skip printing the "error: pathspec[...]" error. However,
      to do so we'd need to pass something down to checkout_paths() to make
      it suppress printing an error on its own, and for us to be confident
      that we're not silencing cases where those errors are meaningful.
      
      I don't think that's worth it since determining whether that's the
      case could easily change due to future changes in the checkout logic.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ad8d5104
    • Æ
      builtin/checkout.c: use "ret" variable for return · 1c550553
      Ævar Arnfjörð Bjarmason 提交于
      There is no point in doing this right now, but in later change the
      "ret" variable will be inspected. This change makes that meaningful
      change smaller.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1c550553
    • Æ
      checkout: pass the "num_matches" up to callers · 3c87aa94
      Ævar Arnfjörð Bjarmason 提交于
      Pass the previously added "num_matches" struct value up to the callers
      of unique_tracking_name(). This will allow callers to optionally print
      better error messages in a later change.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3c87aa94
  13. 29 5月, 2018 1 次提交
  14. 22 5月, 2018 1 次提交
    • M
      unpack_trees_options: free messages when done · 1c41d280
      Martin Ågren 提交于
      The strings allocated in `setup_unpack_trees_porcelain()` are never
      freed. Provide a function `clear_unpack_trees_porcelain()` to do so and
      call it where we use `setup_unpack_trees_porcelain()`. The only
      non-trivial user is `unpack_trees_start()`, where we should place the
      new call in `unpack_trees_finish()`.
      
      We keep the string pointers in an array, mixing pointers to static
      memory and memory that we allocate on the heap. We also keep several
      copies of the individual pointers. So we need to make sure that we do
      not free what we must not free and that we do not double-free. Let a
      separate argv_array take ownership of all the strings we create so that
      we can easily free them.
      
      Zero the whole array of string pointers to make sure that we do not
      leave any dangling pointers.
      
      Note that we only take responsibility for the memory allocated in
      `setup_unpack_trees_porcelain()` and not any other members of the
      `struct unpack_trees_options`.
      Helped-by: NJunio C Hamano <gitster@pobox.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      Signed-off-by: NMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1c41d280
  15. 16 5月, 2018 1 次提交
    • S
      object-store: move object access functions to object-store.h · cbd53a21
      Stefan Beller 提交于
      This should make these functions easier to find and cache.h less
      overwhelming to read.
      
      In particular, this moves:
      - read_object_file
      - oid_object_info
      - write_object_file
      
      As a result, most of the codebase needs to #include object-store.h.
      In this patch the #include is only added to files that would fail to
      compile otherwise.  It would be better to #include wherever
      identifiers from the header are used.  That can happen later
      when we have better tooling for it.
      Signed-off-by: NStefan Beller <sbeller@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cbd53a21
  16. 11 4月, 2018 2 次提交
    • D
      treewide: replace maybe_tree with accessor methods · 2e27bd77
      Derrick Stolee 提交于
      In anticipation of making trees load lazily, create a Coccinelle
      script (contrib/coccinelle/commit.cocci) to ensure that all
      references to the 'maybe_tree' member of struct commit are either
      mutations or accesses through get_commit_tree() or
      get_commit_tree_oid().
      
      Apply the Coccinelle script to create the rest of the patch.
      Signed-off-by: NDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2e27bd77
    • D
      treewide: rename tree to maybe_tree · 891435d5
      Derrick Stolee 提交于
      Using the commit-graph file to walk commit history removes the large
      cost of parsing commits during the walk. This exposes a performance
      issue: lookup_tree() takes a large portion of the computation time,
      even when Git never uses those trees.
      
      In anticipation of lazy-loading these trees, rename the 'tree' member
      of struct commit to 'maybe_tree'. This serves two purposes: it hints
      at the future role of possibly being NULL even if the commit has a
      valid tree, and it allows for unambiguous transformation from simple
      member access (i.e. commit->maybe_tree) to method access.
      Signed-off-by: NDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      891435d5
  17. 15 3月, 2018 3 次提交
  18. 23 2月, 2018 1 次提交
  19. 10 2月, 2018 2 次提交
  20. 31 1月, 2018 1 次提交
  21. 25 1月, 2018 1 次提交
  22. 29 12月, 2017 1 次提交
    • R
      checkout: avoid using the rev_info flag leak_pending · a9a03fa0
      René Scharfe 提交于
      The leak_pending flag is so awkward to use that multiple comments had to
      be added around each occurrence.  We only use it for remembering the
      commits whose marks we have to clear after checking if the old HEAD is
      detached.  This is easy, though: We need to do that for the old commit,
      the new one -- and for all refs.
      
      Don't bother tracking exactly which commits need their flags cleared,
      just nuke all we have in-core.  This change is safe because refs can
      point at anything, so other program parts can't depend on any kept flags
      anyway.  And since all refs are loaded we have to basically deal with
      all commits anyway, so performance should not be negatively impacted.
      Signed-off-by: NRene Scharfe <l.s.r@web.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a9a03fa0
  23. 08 12月, 2017 1 次提交
  24. 06 12月, 2017 1 次提交
    • A
      checkout: describe_detached_head: remove ellipsis after committish · ca69d4d5
      Ann T Ropea 提交于
      We do not want an ellipsis displayed following an (abbreviated) SHA-1
      value.
      
      The days when this was necessary to indicate the truncation to
      lower-level Git commands and/or the user are bygone.
      
      However, to ease the transition, the ellipsis will still be printed if
      the user sets the environment variable GIT_PRINT_SHA1_ELLIPSIS to "yes".
      
      Correct documentation with respect to what describe_detached_head prints
      when GIT_PRINT_SHA1_ELLIPSIS is not set as indicated above.
      
      Add tests for the old and new behaviour.
      Signed-off-by: NAnn T Ropea <bedhanger@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ca69d4d5
  25. 27 11月, 2017 1 次提交
  26. 13 11月, 2017 1 次提交
  27. 06 11月, 2017 1 次提交
  28. 16 10月, 2017 3 次提交
  29. 13 10月, 2017 1 次提交
    • J
      branch: split validate_new_branchname() into two · bc1c9c0e
      Junio C Hamano 提交于
      Checking if a proposed name is appropriate for a branch is strictly
      a subset of checking if we want to allow creating or updating a
      branch with such a name.  The mysterious sounding 'attr_only'
      parameter to validate_new_branchname() is used to switch the
      function between these two roles.
      
      Instead, split the function into two, and adjust the callers.  A new
      helper validate_branchname() only checks the name and reports if the
      branch already exists.
      
      This loses one NEEDSWORK from the branch API.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bc1c9c0e