1. 12 Apr, 2018 4 commits
  2. 22 Nov, 2017 1 commit
    • Rafael Ascensão's avatar
      log: add option to choose which refs to decorate · 65516f58
      Rafael Ascensão authored
      When `log --decorate` is used, git will decorate commits with all
      available refs. While in most cases this may give the desired effect,
      under some conditions it can lead to excessively verbose output.
      
      Introduce two command line options, `--decorate-refs=<pattern>` and
      `--decorate-refs-exclude=<pattern>` to allow the user to select which
      refs are used in decoration.
      
      When "--decorate-refs=<pattern>" is given, only the refs that match the
      pattern are used in decoration. The refs that match the pattern when
      "--decorate-refs-exclude=<pattern>" is given, are never used in
      decoration.
      
      These options follow the same convention for mixing negative and
      positive patterns across the system, assuming that the inclusive default
      is to match all refs available.
      
       (1) if there is no positive pattern given, pretend as if an
           inclusive default positive pattern was given;
      
       (2) for each candidate, reject it if it matches no positive
           pattern, or if it matches any one of the negative patterns.
      
      The rules for what is considered a match are slightly different from the
      rules used elsewhere.
      
      Commands like `log --glob` assume a trailing '/*' when glob chars are
      not present in the pattern. This makes it difficult to specify a single
      ref.  On the other hand, commands like `describe --match --all` allow
      specifying exact refs, but do not have the convenience of allowing
      "shorthand refs" like 'refs/heads' or 'heads' to refer to
      'refs/heads/*'.
      
      The commands introduced in this patch consider a match if:
      
        (a) the pattern contains globs chars,
      	and regular pattern matching returns a match.
      
        (b) the pattern does not contain glob chars,
               and ref '<pattern>' exists, or if ref exists under '<pattern>/'
      
      This allows both behaviours (allowing single refs and shorthand refs)
      yet remaining compatible with existent commands.
      Helped-by: default avatarKevin Daudt <me@ikke.info>
      Helped-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarRafael Ascensão <rafa.almas@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      65516f58
  3. 06 Nov, 2017 4 commits
  4. 16 Oct, 2017 12 commits
  5. 24 Sep, 2017 1 commit
  6. 14 Sep, 2017 1 commit
    • Thomas Gummerer's avatar
      refs: strip out not allowed flags from ref_transaction_update · c788c54c
      Thomas Gummerer authored
      Callers are only allowed to pass certain flags into
      ref_transaction_update, other flags are internal to it.  To prevent
      mistakes from the callers, strip the internal only flags out before
      continuing.
      
      This was noticed because of a compiler warning gcc 7.1.1 issued about
      passing a NULL parameter as second parameter to memcpy (through
      hashcpy):
      
      In file included from refs.c:5:0:
      refs.c: In function ‘ref_transaction_verify’:
      cache.h:948:2: error: argument 2 null where non-null expected [-Werror=nonnull]
        memcpy(sha_dst, sha_src, GIT_SHA1_RAWSZ);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      In file included from git-compat-util.h:165:0,
                       from cache.h:4,
                       from refs.c:5:
      /usr/include/string.h:43:14: note: in a call to function ‘memcpy’ declared here
       extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
                    ^~~~~~
      
      The call to hascpy in ref_transaction_add_update is protected by the
      passed in flags, but as we only add flags there, gcc notices
      REF_HAVE_NEW or REF_HAVE_OLD flags could be passed in from the outside,
      which would potentially result in passing in NULL as second parameter to
      memcpy.
      
      Fix both the compiler warning, and make the interface safer for its
      users by stripping the internal flags out.
      Suggested-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarThomas Gummerer <t.gummerer@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c788c54c
  7. 24 Aug, 2017 4 commits
  8. 27 Jun, 2017 1 commit
  9. 19 Jun, 2017 2 commits
    • Michael Haggerty's avatar
      for_each_bisect_ref(): don't trim refnames · 03df567f
      Michael Haggerty authored
      `for_each_bisect_ref()` is called by `for_each_bad_bisect_ref()` with
      a term "bad". This used to make it call `for_each_ref_in_submodule()`
      with a prefix "refs/bisect/bad". But the latter is the name of the
      reference that is being sought, so the empty string was being passed
      to the callback as the trimmed refname. Moreover, this questionable
      practice was turned into an error by
      
          b9c8e7f2 prefix_ref_iterator: don't trim too much, 2017-05-22
      
      It makes more sense (and agrees better with the documentation of
      `--bisect`) for the callers to receive the full reference names. So
      
      * Add a new function, `for_each_fullref_in_submodule()`, to the refs
        API. This plugs a gap in the existing functionality, analogous to
        `for_each_fullref_in()` but accepting a `submodule` argument.
      
      * Change `for_each_bad_bisect_ref()` to call the new function rather
        than `for_each_ref_in_submodule()`.
      
      * Add a test.
      Signed-off-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      03df567f
    • Sahil's avatar
      branch: add a --copy (-c) option to go with --move (-m) · 52d59cc6
      Sahil authored
      Add the ability to --copy a branch and its reflog and configuration,
      this uses the same underlying machinery as the --move (-m) option
      except the reflog and configuration is copied instead of being moved.
      
      This is useful for e.g. copying a topic branch to a new version,
      e.g. work to work-2 after submitting the work topic to the list, while
      preserving all the tracking info and other configuration that goes
      with the branch, and unlike --move keeping the other already-submitted
      branch around for reference.
      
      Like --move, when the source branch is the currently checked out
      branch the HEAD is moved to the destination branch. In the case of
      --move we don't really have a choice (other than remaining on a
      detached HEAD) and in order to keep the functionality consistent, we
      are doing it in similar way for --copy too.
      
      The most common usage of this feature is expected to be moving to a
      new topic branch which is a copy of the current one, in that case
      moving to the target branch is what the user wants, and doesn't
      unexpectedly behave differently than --move would.
      
      One outstanding caveat of this implementation is that:
      
          git checkout maint &&
          git checkout master &&
          git branch -c topic &&
          git checkout -
      
      Will check out 'maint' instead of 'master'. This is because the @{-N}
      feature (or its -1 shorthand "-") relies on HEAD reflogs created by
      the checkout command, so in this case we'll checkout maint instead of
      master, as the user might expect. What to do about that is left to a
      future change.
      Helped-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: Sahil's avatarSahil Dua <sahildua2305@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      52d59cc6
  10. 23 May, 2017 3 commits
    • Michael Haggerty's avatar
      ref_transaction_prepare(): new optional step for reference updates · 30173b88
      Michael Haggerty authored
      In the future, compound reference stores will sometimes need to modify
      references in two different reference stores at the same time, meaning
      that a single logical reference transaction might have to be
      implemented as two internal sub-transactions. They won't want to call
      `ref_transaction_commit()` for the two sub-transactions one after the
      other, because that wouldn't be atomic (the first commit could succeed
      and the second one fail). Instead, they will want to prepare both
      sub-transactions (i.e., obtain any necessary locks and do any
      pre-checks), and only if both prepare steps succeed, then commit both
      sub-transactions.
      
      Start preparing for that day by adding a new, optional
      `ref_transaction_prepare()` step to the reference transaction
      sequence, which obtains the locks and does any prechecks, reporting
      any errors that occur. Also add a `ref_transaction_abort()` function
      that can be used to abort a sub-transaction even if it has already
      been prepared.
      
      That is on the side of the public-facing API. On the side of the
      `ref_store` VTABLE, get rid of `transaction_commit` and instead add
      methods `transaction_prepare`, `transaction_finish`, and
      `transaction_abort`. A `ref_transaction_commit()` now basically calls
      methods `transaction_prepare` then `transaction_finish`.
      Signed-off-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      30173b88
    • Michael Haggerty's avatar
      ref_store: take a `msg` parameter when deleting references · 64da4199
      Michael Haggerty authored
      Just because the files backend can't retain reflogs for deleted
      references is no reason that they shouldn't be supported by the
      virtual method interface. Also, `delete_ref()` and `refs_delete_ref()`
      have already gained `msg` parameters. Now let's add them to
      `delete_refs()` and `refs_delete_refs()`.
      Signed-off-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      64da4199
    • Michael Haggerty's avatar
      refs.h: clarify docstring for the ref_transaction_update()-related fns · fd2ce9c0
      Michael Haggerty authored
      In particular, make it clear that they make copies of the sha1
      arguments.
      Signed-off-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      fd2ce9c0
  11. 08 May, 2017 1 commit
  12. 27 Apr, 2017 1 commit
    • Johannes Schindelin's avatar
      timestamp_t: a new data type for timestamps · dddbad72
      Johannes Schindelin authored
      Git's source code assumes that unsigned long is at least as precise as
      time_t. Which is incorrect, and causes a lot of problems, in particular
      where unsigned long is only 32-bit (notably on Windows, even in 64-bit
      versions).
      
      So let's just use a more appropriate data type instead. In preparation
      for this, we introduce the new `timestamp_t` data type.
      
      By necessity, this is a very, very large patch, as it has to replace all
      timestamps' data type in one go.
      
      As we will use a data type that is not necessarily identical to `time_t`,
      we need to be very careful to use `time_t` whenever we interact with the
      system functions, and `timestamp_t` everywhere else.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      dddbad72
  13. 25 Apr, 2017 2 commits
    • Duy Nguyen's avatar
      refs: kill set_worktree_head_symref() · d026a256
      Duy Nguyen authored
      70999e9c (branch -m: update all per-worktree HEADs - 2016-03-27)
      added this function in order to update HEADs of all relevant
      worktrees, when a branch is renamed.
      
      It, as a public ref api, kind of breaks abstraction when it uses
      internal functions of files backend. With the introduction of
      refs_create_symref(), we can move back pretty close to the code before
      70999e9c, where create_symref() was used for updating HEAD.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d026a256
    • Duy Nguyen's avatar
      refs: introduce get_worktree_ref_store() · 17eff96b
      Duy Nguyen authored
      files-backend at this point is still aware of the per-repo/worktree
      separation in refs, so it can handle a linked worktree.
      
      Some refs operations are known not working when current files-backend is
      used in a linked worktree (e.g. reflog). Tests will be written when
      refs_* functions start to be called with worktree backend to verify that
      they work as expected.
      
      Note: accessing a worktree of a submodule remains unaddressed. Perhaps
      after get_worktrees() can access submodule (or rather a new function
      get_submodule_worktrees(), that lists worktrees of a submodule), we can
      update this function to work with submodules as well.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      17eff96b
  14. 17 Apr, 2017 1 commit
  15. 14 Apr, 2017 2 commits