2007-01-11 18:47:48 +08:00
|
|
|
#ifndef REFLOG_WALK_H
|
|
|
|
|
#define REFLOG_WALK_H
|
|
|
|
|
|
2009-03-20 14:00:43 +08:00
|
|
|
#include "cache.h"
|
|
|
|
|
|
2018-08-16 01:54:05 +08:00
|
|
|
struct commit;
|
2009-10-19 23:48:10 +08:00
|
|
|
struct reflog_walk_info;
|
|
|
|
|
|
2019-04-29 16:28:14 +08:00
|
|
|
void init_reflog_walk(struct reflog_walk_info **info);
|
|
|
|
|
int add_reflog_for_walk(struct reflog_walk_info *info,
|
2019-04-29 16:28:23 +08:00
|
|
|
struct commit *commit, const char *name);
|
2019-04-29 16:28:14 +08:00
|
|
|
void show_reflog_message(struct reflog_walk_info *info, int,
|
2019-04-29 16:28:23 +08:00
|
|
|
const struct date_mode *, int force_date);
|
2019-04-29 16:28:14 +08:00
|
|
|
void get_reflog_message(struct strbuf *sb,
|
2019-04-29 16:28:23 +08:00
|
|
|
struct reflog_walk_info *reflog_info);
|
2019-04-29 16:28:14 +08:00
|
|
|
const char *get_reflog_ident(struct reflog_walk_info *reflog_info);
|
|
|
|
|
timestamp_t get_reflog_timestamp(struct reflog_walk_info *reflog_info);
|
|
|
|
|
void get_reflog_selector(struct strbuf *sb,
|
2019-04-29 16:28:23 +08:00
|
|
|
struct reflog_walk_info *reflog_info,
|
|
|
|
|
const struct date_mode *dmode, int force_date,
|
|
|
|
|
int shorten);
|
2007-01-11 18:47:48 +08:00
|
|
|
|
2019-04-29 16:28:14 +08:00
|
|
|
int reflog_walk_empty(struct reflog_walk_info *walk);
|
2017-07-07 17:08:30 +08:00
|
|
|
|
reflog-walk: stop using fake parents
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
traversal:
- 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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-07 17:14:07 +08:00
|
|
|
struct commit *next_reflog_entry(struct reflog_walk_info *reflog_info);
|
|
|
|
|
|
2007-01-11 18:47:48 +08:00
|
|
|
#endif
|
