This project is mirrored from Updated .
  1. 09 Jul, 2017 3 commits
    • Jeff King's avatar
      reflog-walk: apply --since/--until to reflog dates · de239446
      Jeff King authored
      When doing a reflog walk, we use the commit's date to
      do any date limiting. In earlier versions of Git, this could
      lead to nonsense results, since a skipped commit would
      truncate the traversal. So a sequence like:
        git commit ...
        git checkout week-old-branch
        git checkout -
        git log -g
      would stop at the week-old-branch, even though the "git
      commit" entry further back is still interesting.
      As of the prior commit, which uses a parent-less traversal
      of the reflog, you get the whole reflog minus any commits
      whose dates do not match the specified options. This is
      arguably useful, as you could scan the reflogs for commits
      that originated in a certain range.
      But more likely a user doing a reflog walk wants to limit
      based on the reflog entries themselves. You can simulate
      --until with:
        git log -g @{}
      but there's no way to ask Git to traverse only back to a
      certain date. E.g.:
        # show me reflog entries from the past day
        git log -g
      This patch teaches the revision machinery to prefer the
      reflog entry dates to the commit dates when doing a reflog
      walk. Technically this is a change in behavior that affects
      plumbing, but the previous behavior was so buggy that it's
      unlikely anyone was relying on it.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      reflog-walk: stop using fake parents · d08565bf
      Jeff King authored
      The reflog-walk system works by putting a ref's tip into the
      pending queue, and then "traversing" the reflog by
      pretending that the parent of each commit is the previous
      reflog entry.
      This causes a number of user-visible oddities, as documented
      in t1414 (and the commit message which introduced it). We
      can fix all of them in one go by replacing the fake-reflog
      system with a much simpler one: just keeping a list of
      reflogs to show, and walking through them entry by entry.
      The implementation is fairly straight-forward, but there are
      a few items to note:
        1. We obviously must skip calling add_parents_to_list()
           when we are traversing reflogs, since we do not want to
           walk the original parents at all.  As a result, we must call
           try_to_simplify_commit() ourselves.
           There are other parts of add_parents_to_list() we skip,
           as well, but none of them should matter for a reflog
             -  We do not allow UNINTERESTING commits, nor
                symmetric ranges (and we bail when these are used
                with "-g").
             - Using --source makes no sense, since we aren't
               traversing. The reflog selector shows the same
               information with more detail.
             - Using --first-parent is still sensible, since you
               may want to see the first-parent diff for each
               entry. But since we're not traversing, we don't
               need to cull the parent list here.
        2. Since we now just walk the reflog entries themselves,
           rather than starting with the ref tip, we now look at
           the "new" field of each entry rather than the "old"
           (i.e., we are showing entries, not faking parents).
           This removes all of the tricky logic around skipping
           past root commits.
           But note that we have no way to show an entry with the
           null sha1 in its "new" field (because such a commit
           obviously does not exist). Normally this would not
           happen, since we delete reflogs along with refs, but
           there is one special case. When we rename the currently
           checked out branch, we write two reflog entries into
           the HEAD log: one where the commit goes away, and
           another where it comes back.
           Prior to this commit, we show both entries with
           identical reflog messages. After this commit, we show
           only the "comes back" entry. See the update in t3200
           which demonstrates this.
           Arguably either is fine, as the whole double-entry
           thing is a bit hacky in the first place. And until a
           recent fix, we truncated the traversal in such a case
           anyway, which was _definitely_ wrong.
        3. We show individual reflogs in order, but choose which
           reflog to show at each stage based on which has the
           most recent timestamp.  This interleaves the output
           from multiple reflogs based on date order, which is
           probably what you'd want with limiting like "-n 30".
           Note that the implementation aims for simplicity. It
           does a linear walk over the reflog queue for each
           commit it pulls, which may perform badly if you
           interleave an enormous number of reflogs. That seems
           like an unlikely use case; if we did want to handle it,
           we could probably keep a priority queue of reflogs,
           ordered by the timestamp of their current tip entry.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      rev-list: check reflog_info before showing usage · 7f97de5e
      Jeff King authored
      When git-rev-list sees no pending commits, it shows a usage
      message. This works even when reflog-walking is requested,
      because the reflog-walk code currently puts the reflog tips
      into the pending queue.
      In preparation for refactoring the reflog-walk code, let's
      explicitly check whether we have any reflogs to walk. For
      now this is a noop, but the existing reflog tests will make
      sure that it kicks in after the refactoring. Likewise, we'll
      add a test that "rev-list -g" without specifying any reflogs
      continues to fail (so that we know our check does not kick
      in too aggressively).
      Note that the implementation needs to go into its own
      sub-function, as the walk code does not expose its innards
      outside of reflog-walk.c.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 29 Jun, 2015 1 commit
    • Jeff King's avatar
      convert "enum date_mode" into a struct · a5481a6c
      Jeff King authored
      In preparation for adding date modes that may carry extra
      information beyond the mode itself, this patch converts the
      date_mode enum into a struct.
      Most of the conversion is fairly straightforward; we pass
      the struct as a pointer and dereference the type field where
      necessary. Locations that declare a date_mode can use a "{}"
      constructor.  However, the tricky case is where we use the
      enum labels as constants, like:
        show_date(t, tz, DATE_NORMAL);
      Ideally we could say:
        show_date(t, tz, &{ DATE_NORMAL });
      but of course C does not allow that. Likewise, we cannot
      cast the constant to a struct, because we need to pass an
      actual address. Our options are basically:
        1. Manually add a "struct date_mode d = { DATE_NORMAL }"
           definition to each caller, and pass "&d". This makes
           the callers uglier, because they sometimes do not even
           have their own scope (e.g., they are inside a switch
        2. Provide a pre-made global "date_normal" struct that can
           be passed by address. We'd also need "date_rfc2822",
           "date_iso8601", and so forth. But at least the ugliness
           is defined in one place.
        3. Provide a wrapper that generates the correct struct on
           the fly. The big downside is that we end up pointing to
           a single global, which makes our wrapper non-reentrant.
           But show_date is already not reentrant, so it does not
      This patch implements 3, along with a minor macro to keep
      the size of the callers sane.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 02 Sep, 2014 1 commit
  4. 07 May, 2012 1 commit
  5. 16 Dec, 2011 1 commit
  6. 20 Oct, 2009 1 commit
    • Thomas Rast's avatar
      Introduce new pretty formats %g[sdD] for reflog information · 8f8f5476
      Thomas Rast authored
      Add three new --pretty=format escapes:
        %gD  long  reflog descriptor (e.g. refs/[email protected]{0})
        %gd  short reflog descriptor (e.g. [email protected]{0})
        %gs  reflog message
      This is achieved by passing down the reflog info, if any, inside the
      pretty_print_context struct.
      We use the newly refactored get_reflog_selector(), and give it some
      extra functionality to extract a shortened ref.  The shortening is
      cached inside the commit_reflogs struct; the only allocation of it
      happens in read_complete_reflog(), where it is initialised to 0.  Also
      add another helper get_reflog_message() for the message extraction.
      Note that the --format="%h %gD: %gs" tests may not work in real
      repositories, as the --pretty formatter doesn't know to leave away the
      ": " on the last commit in an incomplete (because git-gc removed the
      old part) reflog.  This equivalence is nevertheless the main goal of
      this patch.
      Thanks to Jeff King for reviews, the %gd testcase and documentation.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  7. 20 Mar, 2009 1 commit
    • Jeff King's avatar
      make oneline reflog dates more consistent with multiline format · cd437120
      Jeff King authored
      The multiline reflog format (e.g., as shown by "git log -g")
      will show [email protected]{<date>} rather than [email protected]{<count>} in two
        1. If the user gave [email protected]{<date>} syntax to specify the
        2. If the user gave a --date=<format> specifier
      It uses the "normal" date format in case 1, and the
      user-specified format in case 2.
      The oneline reflog format (e.g., "git reflog show" or "git
      log -g --oneline") will show the date in the same two
      circumstances. However, it _always_ shows the date as a
      relative date, and it always ignores the timezone.
      In case 2, it seems ridiculous to trigger the date but use a
      format totally different from what the user requested.
      For case 1, it is arguable that the user might want to see
      the relative date by default; however, the multiline version
      shows the normal format.
      This patch does three things:
        - refactors the "relative_date" parameter to
          show_reflog_message to be an actual date_mode enum,
          since this is how it is used (it is passed to show_date)
        - uses the passed date_mode parameter in the oneline
          format (making it consistent with the multiline format)
        - does not ignore the timezone parameter in oneline mode
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  8. 25 Jul, 2007 1 commit
  9. 09 Feb, 2007 1 commit
  10. 21 Jan, 2007 2 commits