This project is mirrored from https://github.com/git/git. Updated .
  1. 24 Jul, 2014 1 commit
    • Jeff King's avatar
      free ref string returned by dwim_ref · 28b35632
      Jeff King authored
      A call to "dwim_ref(name, len, flags, &ref)" will allocate a
      new string in "ref" to return the exact ref we found. We do
      not consistently free it in all code paths, leading to small
      leaks. The worst is in get_sha1_basic, which may be called
      many times (e.g., by "cat-file --batch"), though it is
      relatively unlikely, as it only triggers on a bogus reflog
      specification.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      28b35632
  2. 10 Jul, 2014 1 commit
  3. 20 Jun, 2014 1 commit
    • Jeff King's avatar
      use skip_prefix to avoid repeating strings · 95b567c7
      Jeff King authored
      It's a common idiom to match a prefix and then skip past it
      with strlen, like:
      
        if (starts_with(foo, "bar"))
      	  foo += strlen("bar");
      
      This avoids magic numbers, but means we have to repeat the
      string (and there is no compiler check that we didn't make a
      typo in one of the strings).
      
      We can use skip_prefix to handle this case without repeating
      ourselves.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      95b567c7
  4. 19 Jun, 2014 1 commit
  5. 13 Jun, 2014 2 commits
    • Jeff King's avatar
      commit: record buffer length in cache · 8597ea3a
      Jeff King authored
      Most callsites which use the commit buffer try to use the
      cached version attached to the commit, rather than
      re-reading from disk. Unfortunately, that interface provides
      only a pointer to the NUL-terminated buffer, with no
      indication of the original length.
      
      For the most part, this doesn't matter. People do not put
      NULs in their commit messages, and the log code is happy to
      treat it all as a NUL-terminated string. However, some code
      paths do care. For example, when checking signatures, we
      want to be very careful that we verify all the bytes to
      avoid malicious trickery.
      
      This patch just adds an optional "size" out-pointer to
      get_commit_buffer and friends. The existing callers all pass
      NULL (there did not seem to be any obvious sites where we
      could avoid an immediate strlen() call, though perhaps with
      some further refactoring we could).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8597ea3a
    • Jeff King's avatar
      use get_commit_buffer to avoid duplicate code · ba41c1c9
      Jeff King authored
      For both of these sites, we already do the "fallback to
      read_sha1_file" trick. But we can shorten the code by just
      using get_commit_buffer.
      
      Note that the error cases are slightly different when
      read_sha1_file fails. get_commit_buffer will die() if the
      object cannot be loaded, or is a non-commit.
      
      For get_sha1_oneline, this will almost certainly never
      happen, as we will have just called parse_object (and if it
      does, it's probably worth complaining about).
      
      For record_author_date, the new behavior is probably better;
      we notify the user of the error instead of silently ignoring
      it. And because it's used only for sorting by author-date,
      somebody examining a corrupt repo can fallback to the
      regular traversal order.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ba41c1c9
  6. 25 Mar, 2014 1 commit
  7. 15 Jan, 2014 5 commits
    • Jeff King's avatar
      interpret_branch_name: find all possible @-marks · 9892d5d4
      Jeff King authored
      When we parse a string like "foo@{upstream}", we look for
      the first "@"-sign, and check to see if it is an upstream
      mark. However, since branch names can contain an @, we may
      also see "@foo@{upstream}". In this case, we check only the
      first @, and ignore the second. As a result, we do not find
      the upstream.
      
      We can solve this by iterating through all @-marks in the
      string, and seeing if any is a legitimate upstream or
      empty-at mark.
      
      Another strategy would be to parse from the right-hand side
      of the string. However, that does not work for the
      "empty_at" case, which allows "@@{upstream}". We need to
      find the left-most one in this case (and we then recurse as
      "HEAD@{upstream}").
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9892d5d4
    • Jeff King's avatar
      interpret_branch_name: avoid @{upstream} past colon · 3f6eb30f
      Jeff King authored
      get_sha1() cannot currently parse a valid object name like
      "HEAD:@{upstream}" (assuming that such an oddly named file
      exists in the HEAD commit). It takes two passes to parse the
      string:
      
        1. It first considers the whole thing as a ref, which
           results in looking for the upstream of "HEAD:".
      
        2. It finds the colon, parses "HEAD" as a tree-ish, and then
           finds the path "@{upstream}" in the tree.
      
      For a path that looks like a normal reflog (e.g.,
      "HEAD:@{yesterday}"), the first pass is a no-op. We try to
      dwim_ref("HEAD:"), that returns zero refs, and we proceed
      with colon-parsing.
      
      For "HEAD:@{upstream}", though, the first pass ends up in
      interpret_upstream_mark, which tries to find the branch
      "HEAD:". When it sees that the branch does not exist, it
      actually dies rather than returning an error to the caller.
      As a result, we never make it to the second pass.
      
      One obvious way of fixing this would be to teach
      interpret_upstream_mark to simply report "no, this isn't an
      upstream" in such a case. However, that would make the
      error-reporting for legitimate upstream cases significantly
      worse. Something like "bogus@{upstream}" would simply report
      "unknown revision: bogus@{upstream}", while the current code
      diagnoses a wide variety of possible misconfigurations (no
      such branch, branch exists but does not have upstream, etc).
      
      However, we can take advantage of the fact that a branch
      name cannot contain a colon. Therefore even if we find an
      upstream mark, any prefix with a colon must mean that
      the upstream mark we found is actually a pathname, and
      should be disregarded completely. This patch implements that
      logic.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3f6eb30f
    • Jeff King's avatar
      interpret_branch_name: always respect "namelen" parameter · 8cd4249c
      Jeff King authored
      interpret_branch_name gets passed a "name" buffer to parse,
      along with a "namelen" parameter representing its length. If
      "namelen" is zero, we fallback to the NUL-terminated
      string-length of "name".
      
      However, it does not necessarily follow that if we have
      gotten a non-zero "namelen", it is the NUL-terminated
      string-length of "name". E.g., when get_sha1() is parsing
      "foo:bar", we will be asked to operate only on the first
      three characters.
      
      Yet in interpret_branch_name and its helpers, we use string
      functions like strchr() to operate on "name", looking past
      the length we were given.  This can result in us mis-parsing
      object names.  We should instead be limiting our search to
      "namelen" bytes.
      
      There are three distinct types of object names this patch
      addresses:
      
        - The intrepret_empty_at helper uses strchr to find the
          next @-expression after our potential empty-at.  In an
          expression like "@:foo@bar", it erroneously thinks that
          the second "@" is relevant, even if we were asked only
          to look at the first character. This case is easy to
          trigger (and we test it in this patch).
      
        - When finding the initial @-mark for @{upstream}, we use
          strchr.  This means we might treat "foo:@{upstream}" as
          the upstream for "foo:", even though we were asked only
          to look at "foo". We cannot test this one in practice,
          because it is masked by another bug (which is fixed in
          the next patch).
      
        - The interpret_nth_prior_checkout helper did not receive
          the name length at all. This turns out not to be a
          problem in practice, though, because its parsing is so
          limited: it always starts from the far-left of the
          string, and will not tolerate a colon (which is
          currently the only way to get a smaller-than-strlen
          "namelen"). However, it's still worth fixing to make the
          code more obviously correct, and to future-proof us
          against callers with more exotic buffers.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8cd4249c
    • Jeff King's avatar
      interpret_branch_name: rename "cp" variable to "at" · f278f40f
      Jeff King authored
      In the original version of this function, "cp" acted as a
      pointer to many different things. Since the refactoring in
      the last patch, it only marks the at-sign in the string.
      Let's use a more descriptive variable name.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f278f40f
    • Jeff King's avatar
      interpret_branch_name: factor out upstream handling · a39c14af
      Jeff King authored
      This function checks a few different @{}-constructs. The
      early part checks for and dispatches us to helpers for each
      construct, but the code for handling @{upstream} is inline.
      
      Let's factor this out into its own function. This makes
      interpret_branch_name more readable, and will make it much
      simpler to further refactor the function in future patches.
      
      While we're at it, let's also break apart the refactored
      code into a few helper functions. These will be useful if we
      eventually implement similar @{upstream}-like constructs.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a39c14af
  8. 07 Jan, 2014 1 commit
  9. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59556548
  10. 31 Oct, 2013 1 commit
  11. 24 Oct, 2013 1 commit
  12. 12 Sep, 2013 1 commit
    • Felipe Contreras's avatar
      Add new @ shortcut for HEAD · 9ba89f48
      Felipe Contreras authored
      Typing 'HEAD' is tedious, especially when we can use '@' instead.
      
      The reason for choosing '@' is that it follows naturally from the
      ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
      operation, and when we don't have those, it makes sens to assume
      'HEAD'.
      
      So now we can use 'git show @~1', and all that goody goodness.
      
      Until now '@' was a valid name, but it conflicts with this idea, so
      let's make it invalid. Probably very few people, if any, used this name.
      Signed-off-by: Felipe Contreras's avatarFelipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9ba89f48
  13. 04 Sep, 2013 1 commit
  14. 03 Sep, 2013 3 commits
    • Jeff King's avatar
      peel_onion: do not assume length of x_type globals · c969b6a1
      Jeff King authored
      When we are parsing "rev^{foo}", we check "foo" against the
      various global type strings, like "commit_type",
      "tree_type", etc. This is nicely abstracted, but then we
      destroy the abstraction completely by using magic numbers
      that must match the length of the type strings.
      
      We could avoid these magic numbers by using skip_prefix. But
      taking a step back, we can realize that using the
      "commit_type" global is not really buying us anything. It is
      not ever going to change from being "commit" without causing
      severe breakage to existing uses. And even if it did change
      for some crazy reason, we would want to evaluate its effects
      on the "rev^{}" syntax, anyway.
      
      Let's just switch these to using a custom string literal, as
      we do for "rev^{object}". The resulting code is more robust
      to changes in the type strings, and is more readable.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c969b6a1
    • Richard Hansen's avatar
      peel_onion(): add support for <rev>^{tag} · 75aa26d3
      Richard Hansen authored
      Complete the <rev>^{<type>} family of object descriptors by having
      <rev>^{tag} dereference <rev> until a tag object is found (or fail if
      unable).
      
      At first glance this may not seem very useful, as commits, trees, and
      blobs cannot be peeled to a tag, and a tag would just peel to itself.
      However, this can be used to ensure that <rev> names a tag object:
      
          $ git rev-parse --verify v1.8.4^{tag}
          04f013dc38d7512eadb915eba22efc414f18b869
          $ git rev-parse --verify master^{tag}
          error: master^{tag}: expected tag type, but the object dereferences to tree type
          fatal: Needed a single revision
      
      Users can already ensure that <rev> is a tag object by checking the
      output of 'git cat-file -t <rev>', but:
        * users may expect <rev>^{tag} to exist given that <rev>^{commit},
          <rev>^{tree}, and <rev>^{blob} all exist
        * this syntax is more convenient/natural in some circumstances
      Signed-off-by: default avatarRichard Hansen <rhansen@bbn.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      75aa26d3
    • Felipe Contreras's avatar
      sha1-name: pass len argument to interpret_branch_name() · cf99a761
      Felipe Contreras authored
      This is useful to make sure we don't step outside the boundaries of what
      we are interpreting at the moment. For example while interpreting
      foobar@{u}~1, the job of interpret_branch_name() ends right before ~1,
      but there's no way to figure that out inside the function, unless the
      len argument is passed.
      
      So let's do that.
      Signed-off-by: Felipe Contreras's avatarFelipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cf99a761
  15. 14 Aug, 2013 1 commit
    • Junio C Hamano's avatar
      Revert "Add new @ shortcut for HEAD" · 2c2b6646
      Junio C Hamano authored
      This reverts commit cdfd9483, as it
      does not just apply to "@" (and forms with modifiers like @{u}
      applied to it), but also affects e.g. "refs/heads/@/foo", which it
      shouldn't.
      
      The basic idea of giving a short-hand might be good, and the topic
      can be retried later, but let's revert to avoid affecting existing
      use cases for now for the upcoming release.
      2c2b6646
  16. 31 Jul, 2013 1 commit
  17. 22 Jul, 2013 1 commit
  18. 12 Jul, 2013 1 commit
    • Jeff King's avatar
      cat-file: disable object/refname ambiguity check for batch mode · 25fba78d
      Jeff King authored
      A common use of "cat-file --batch-check" is to feed a list
      of objects from "rev-list --objects" or a similar command.
      In this instance, all of our input objects are 40-byte sha1
      ids. However, cat-file has always allowed arbitrary revision
      specifiers, and feeds the result to get_sha1().
      
      Fortunately, get_sha1() recognizes a 40-byte sha1 before
      doing any hard work trying to look up refs, meaning this
      scenario should end up spending very little time converting
      the input into an object sha1. However, since 798c35fc
      (get_sha1: warn about full or short object names that look
      like refs, 2013-05-29), when we encounter this case, we
      spend the extra effort to do a refname lookup anyway, just
      to print a warning. This is further exacerbated by ca919930
      (get_packed_ref_cache: reload packed-refs file when it
      changes, 2013-06-20), which makes individual ref lookup more
      expensive by requiring a stat() of the packed-refs file for
      each missing ref.
      
      With no patches, this is the time it takes to run:
      
        $ git rev-list --objects --all >objects
        $ time git cat-file --batch-check='%(objectname)' <objects
      
      on the linux.git repository:
      
        real    1m13.494s
        user    0m25.924s
        sys     0m47.532s
      
      If we revert ca919930, the packed-refs up-to-date check, it
      gets a little better:
      
        real    0m54.697s
        user    0m21.692s
        sys     0m32.916s
      
      but we are still spending quite a bit of time on ref lookup
      (and we would not want to revert that patch, anyway, which
      has correctness issues).  If we revert 798c35fc, disabling
      the warning entirely, we get a much more reasonable time:
      
        real    0m7.452s
        user    0m6.836s
        sys     0m0.608s
      
      This patch does the moral equivalent of this final case (and
      gets similar speedups). We introduce a global flag that
      callers of get_sha1() can use to avoid paying the price for
      the warning.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      25fba78d
  19. 09 Jul, 2013 1 commit
    • Duy Nguyen's avatar
      Convert "struct cache_entry *" to "const ..." wherever possible · 9c5e6c80
      Duy Nguyen authored
      I attempted to make index_state->cache[] a "const struct cache_entry **"
      to find out how existing entries in index are modified and where. The
      question I have is what do we do if we really need to keep track of on-disk
      changes in the index. The result is
      
       - diff-lib.c: setting CE_UPTODATE
      
       - name-hash.c: setting CE_HASHED
      
       - preload-index.c, read-cache.c, unpack-trees.c and
         builtin/update-index: obvious
      
       - entry.c: write_entry() may refresh the checked out entry via
         fill_stat_cache_info(). This causes "non-const struct cache_entry
         *" in builtin/apply.c, builtin/checkout-index.c and
         builtin/checkout.c
      
       - builtin/ls-files.c: --with-tree changes stagemask and may set
         CE_UPDATE
      
      Of these, write_entry() and its call sites are probably most
      interesting because it modifies on-disk info. But this is stat info
      and can be retrieved via refresh, at least for porcelain
      commands. Other just uses ce_flags for local purposes.
      
      So, keeping track of "dirty" entries is just a matter of setting a
      flag in index modification functions exposed by read-cache.c. Except
      unpack-trees, the rest of the code base does not do anything funny
      behind read-cache's back.
      
      The actual patch is less valueable than the summary above. But if
      anyone wants to re-identify the above sites. Applying this patch, then
      this:
      
          diff --git a/cache.h b/cache.h
          index 430d021..1692891 100644
          --- a/cache.h
          +++ b/cache.h
          @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
           #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
      
           struct index_state {
          -	struct cache_entry **cache;
          +	const struct cache_entry **cache;
           	unsigned int version;
           	unsigned int cache_nr, cache_alloc, cache_changed;
           	struct string_list *resolve_undo;
      
      will help quickly identify them without bogus warnings.
      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>
      9c5e6c80
  20. 02 Jul, 2013 1 commit
    • Junio C Hamano's avatar
      get_short_sha1(): correctly disambiguate type-limited abbreviation · 94d75d1e
      Junio C Hamano authored
      One test in t1512 that expects a failure incorrectly passed.  The
      test prepares a commit whose object name begins with ten "0"s, and
      also prepares a tag that points at the commit.  The object name of
      the tag also begins with ten "0"s.  There is no other commit-ish
      object in the repository whose name begins with such a prefix.
      
      Ideally, in such a repository:
      
          $ git rev-parse --verify 0000000000^{commit}
      
      should yield that commit.  If 0000000000 is taken as the commit
      0000000000e4f, peeling it to a commmit yields that commit itself,
      and if 0000000000 is taken as the tag 0000000000f8f, peeling it to a
      commit also yields the same commit, so in that twisted sense, the
      extended SHA-1 expression 0000000000^{commit} is unambigous.  The
      test that expects a failure is to check the above command.
      
      The reason the test expects a failure is that we did not implement
      such a "unification" of two candidate objects.  What we did (or at
      least, meant to) implement was to recognise that a commit-ish is
      required to expand 0000000000, and notice that there are two succh
      commit-ish, and diagnose the request as ambiguous.
      
      However, there was a bug in the logic to check the candidate
      objects.  When the code saw 0000000000f8f (a tag) that shared the
      shortened prefix (ten "0"s), it tried to make sure that the tag is a
      commit-ish by looking at the tag object.  Because it incorrectly
      used lookup_object() when the tag has not been parsed, however, we
      incorrectly declared that the tag is _not_ a commit-ish, leaving the
      sole commit in the repository, 0000000000e4f, that has the required
      prefix as "unique match", causing the test to pass when it shouldn't.
      
      This fixes the logic to inspect the type of the object a tag refers
      to, to make the test that is expected to fail correctly fail.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      94d75d1e
  21. 02 Jun, 2013 1 commit
    • Ramkumar Ramachandra's avatar
      sha1_name: fix error message for @{<N>}, @{<date>} · 305ebea0
      Ramkumar Ramachandra authored
      Currently, when we try to resolve @{<N>} or @{<date>} when the reflog
      doesn't go back far enough, we get errors like:
      
        # on branch master
        $ git show @{10000}
        fatal: Log for '' only has 7 entries.
      
        $ git show @{10000.days.ago}
        warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.
        ...
      
        # detached HEAD case
        $ git show @{10000}
        fatal: Log for '' only has 2005 entries.
      
        $ git show master@{10000}
        fatal: Log for 'master' only has 7 entries.
      
      The empty string '' is confusing and does not convey information
      about whose logs we are inspecting.  Change this so that we get:
      
        # on branch master
        $ git show @{10000}
        fatal: Log for 'master' only has 7 entries.
      
        $ git show @{10000.days.ago}
        warning: Log for 'master' only goes back to Tue, 21 May 2013 14:14:45 +0530.
        ...
      
        # detached HEAD case
        $ git show @{10000}
        fatal: Log for 'HEAD' only has 2005 entries.
      
        $ git show master@{10000}
        fatal: Log for 'master' only has 7 entries.
      
      Also one of the message strings given to die() now points into
      real_ref that was not used in that fashion, so stop freeing the
      underlying storage for it.
      Signed-off-by: default avatarRamkumar Ramachandra <artagnon@gmail.com>
      Bug-spotted-and-fixed-by: Thomas Rast
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      305ebea0
  22. 29 May, 2013 1 commit
    • Duy Nguyen's avatar
      get_sha1: warn about full or short object names that look like refs · 798c35fc
      Duy Nguyen authored
      When we get 40 hex digits, we immediately assume it's an SHA-1. This
      is the right thing to do because we have no way else to specify an
      object. If there is a ref with the same object name, it will be
      ignored. Warn the user about this case because the ref with full
      object name is likely a mistake, for example
      
          git checkout -b $empty_var $(git rev-parse something)
      
      advice.object_name_warning is not documented because frankly people
      should not be aware about it until they encounter this situation.
      
      While at there, warn about ambiguation with abbreviated SHA-1 too.
      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>
      798c35fc
  23. 22 May, 2013 1 commit
    • Ramkumar Ramachandra's avatar
      sha1_name: fix error message for @{u} · 17bf4ff3
      Ramkumar Ramachandra authored
      Currently, when no (valid) upstream is configured for a branch, you get
      an error like:
      
        $ git show @{u}
        error: No upstream configured for branch 'upstream-error'
        error: No upstream configured for branch 'upstream-error'
        fatal: ambiguous argument '@{u}': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions, like this:
        'git <command> [<revision>...] -- [<file>...]'
      
      The "error: " line actually appears twice, and the rest of the error
      message is useless.  In sha1_name.c:interpret_branch_name(), there is
      really no point in processing further if @{u} couldn't be resolved, and
      we might as well die() instead of returning an error().  After making
      this change, you get:
      
        $ git show @{u}
        fatal: No upstream configured for branch 'upstream-error'
      
      Also tweak a few tests in t1507 to expect this output.
      
      This only turns error() that may be called after we know we are
      dealing with an @{upstream} marker into die(), without touching
      silent error returns "return -1" from the function.  Any caller that
      wants to handle an error condition itself will not be hurt by this
      change, unless they want to see the message from error() and then
      exit silently without giving its own message, which needs to be
      fixed anyway.
      Signed-off-by: default avatarRamkumar Ramachandra <artagnon@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      17bf4ff3
  24. 16 May, 2013 1 commit
    • Junio C Hamano's avatar
      strbuf_branchname(): do not double-expand @{-1}~22 · 84cf2466
      Junio C Hamano authored
      If you were on 'frotz' branch before you checked out your current
      branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
      
      The strbuf_branchname() function, when interpret_branch_name() gives
      up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
      that it only resolved "@{-1}" part of the input, mistakes this as a
      total failure, and appends the whole thing to the result, yielding
      "frotz@{-1}~22", which does not make any sense.
      
      Inspect the return value from interpret_branch_name() a bit more
      carefully.  When it errored out without consuming anything, we will
      get -1 and we should return the whole thing.  Otherwise, we should
      append the remainder (i.e. "~22" in the earlier example) to the
      partially resolved name (i.e. "frotz").
      
      The test suite adds enough number of checkout to make @{-12} in the
      last test in t0100 that tried to check "we haven't flipped branches
      that many times" error case succeed; raise the number to a hundred.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      84cf2466
  25. 08 May, 2013 8 commits
  26. 31 Mar, 2013 1 commit
    • Junio C Hamano's avatar
      peel_onion(): teach $foo^{object} peeler · a6a3f2cc
      Junio C Hamano authored
      A string that names an object can be suffixed with ^{type} peeler to
      say "I have this object name; peel it until you get this type. If
      you cannot do so, it is an error".  v1.8.2^{commit} asks for a commit
      that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it
      further to the top-level tree object.  A special suffix ^{} (i.e. no
      type specified) means "I do not care what it unwraps to; just peel
      annotated tag until you get something that is not a tag".
      
      When you have a random user-supplied string, you can turn it to a
      bare 40-hex object name, and cause it to error out if such an object
      does not exist, with:
      
      	git rev-parse --verify "$userstring^{}"
      
      for most objects, but this does not yield the tag object name when
      $userstring refers to an annotated tag.
      
      Introduce a new suffix, ^{object}, that only makes sure the given
      name refers to an existing object.  Then
      
      	git rev-parse --verify "$userstring^{object}"
      
      becomes a way to make sure $userstring refers to an existing object.
      
      This is necessary because the plumbing "rev-parse --verify" is only
      about "make sure the argument is something we can feed to get_sha1()
      and turn it into a raw 20-byte object name SHA-1" and is not about
      "make sure that 20-byte object name SHA-1 refers to an object that
      exists in our object store".  When the given $userstring is already
      a 40-hex, by definition "rev-parse --verify $userstring" can turn it
      into a raw 20-byte object name.  With "$userstring^{object}", we can
      make sure that the 40-hex string names an object that exists in our
      object store before "--verify" kicks in.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a6a3f2cc