Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 29, 2015
  1. @peff @gitster

    convert "enum date_mode" into a struct

    peff authored gitster committed
    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
         statement).
    
      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
         matter.
    
    This patch implements 3, along with a minor macro to keep
    the size of the callers sane.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on May 4, 2012
  1. @peff @gitster

    reflog-walk: always make HEAD@{0} show indexed selectors

    peff authored gitster committed
    When we are showing reflog selectors during a walk, we infer
    from context whether the user wanted to see the index in
    each selector, or the reflog date. The current rules are:
    
      1. if the user asked for an explicit date format in the
         output, show the date
    
      2. if the user asked for ref@{now}, show the date
    
      3. if neither is true, show the index
    
    However,  if we see "ref@{0}", that should be a strong clue
    that the user wants to see the counted version. In fact, it
    should be much stronger than the date format in (1). The
    user may have been setting the date format to use in another
    part of the output (e.g., in --format="%gd (%ad)", they may
    have wanted to influence the author date).
    
    This patch flips the rules to:
    
      1. if the user asked for ref@{0}, always show the index
    
      2. if the user asked for ref@{now}, always show the date
    
      3. otherwise, we have just "ref"; show them counted by
         default, but respect the presence of "--date" as a clue
         that the user wanted them date-based
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @peff @gitster

    reflog-walk: clean up "flag" field of commit_reflog struct

    peff authored gitster committed
    When we prepare to walk a reflog, we parse the specification
    and pull some information from it, such as which reflog to
    look in (e.g., HEAD), and where to start (e.g., HEAD@{10} or
    HEAD@{yesterday}). The resulting struct has a "recno" field
    to show where in the reflog we are starting. It also has a
    "flag" field; if true, it means the recno field came from
    parsing a date like HEAD@{yesterday}.
    
    There are two problems with this:
    
      1. "flag" is an absolutely terrible name, as it conveys
         nothing about the meaning
    
      2. you can tell "HEAD" from "HEAD@{yesterday}", but you
         can't differentiate "HEAD" from "HEAD{0}"
    
    This patch converts the flag into a tri-state (and gives it
    a better name!).
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 16, 2011
  1. @peff @gitster

    pretty: give placeholders to reflog identity

    peff authored gitster committed
    When doing a reflog walk, you can get some information about
    the reflog (such as the subject line), but not the identity
    information (i.e., name and email).
    
    Let's make those available, mimicing the options for author
    and committer identity.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 24, 2010
  1. @peff @gitster

    reflogs: clear flags properly in corner case

    peff authored gitster committed
    The reflog-walking mechanism is based on the regular
    revision traversal. We just rewrite the parents of each
    commit in fake_reflog_parent to point to the commit in the
    next reflog entry instead of the real parents.
    
    However, the regular revision traversal tries not to show
    the same commit twice, and so sets the SHOWN flag on each
    commit it shows. In a reflog, however, we may want to see
    the same commit more than once if it appears in the reflog
    multiple times (which easily happens, for example, if you do
    a reset to a prior state).
    
    The fake_reflog_parent function takes care of this by
    clearing flags, including SHOWN. Unfortunately, it does so
    at the very end of the function, and it is possible to
    return early from the function if there is no fake parent to
    set up (e.g., because we are at the very first reflog entry
    on the branch). In such a case the flag is not cleared, and
    the entry is skipped by the revision traversal machinery as
    already shown.
    
    You can see this by walking the log of a ref which is set to
    its very first commit more than once (the test below shows
    such a situation). In this case the reflog walk will fail to
    show the entry for the initial creation of the ref.
    
    We don't want to simply move the flag-clearing to the top of
    the function; we want to make sure flags set during the
    fake-parent installation are also cleared. Instead, let's
    hoist the flag-clearing out of the fake_reflog_parent
    function entirely. It's not really about fake parents
    anyway, and the only caller is the get_revision machinery.
    
    Reported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
    Signed-off-by: Jeff King <peff@peff.net>
    Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 20, 2009
  1. @peff @gitster

    make oneline reflog dates more consistent with multiline format

    peff authored gitster committed
    The multiline reflog format (e.g., as shown by "git log -g")
    will show HEAD@{<date>} rather than HEAD@{<count>} in two
    situations:
    
      1. If the user gave branch@{<date>} syntax to specify the
         reflog
    
      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: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.