2005-08-21 11:51:10 +02:00
|
|
|
#include "cache.h"
|
|
|
|
#include "commit.h"
|
|
|
|
#include "refs.h"
|
2006-05-23 14:15:35 +02:00
|
|
|
#include "builtin.h"
|
2009-04-22 23:41:25 +02:00
|
|
|
#include "color.h"
|
2009-05-21 09:33:18 +02:00
|
|
|
#include "parse-options.h"
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2009-05-21 09:33:18 +02:00
|
|
|
static const char* show_branch_usage[] = {
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--current] [--color[=<when>] | --no-color] [--sparse] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] [--topics] [(<rev> | <glob>)...]"),
|
|
|
|
N_("git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]"),
|
2009-05-21 09:33:18 +02:00
|
|
|
NULL
|
|
|
|
};
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2009-04-22 23:41:25 +02:00
|
|
|
static int showbranch_use_color = -1;
|
|
|
|
|
2006-08-15 19:23:48 +02:00
|
|
|
static int default_num;
|
|
|
|
static int default_alloc;
|
|
|
|
static const char **default_arg;
|
2006-01-09 22:29:23 +01:00
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
#define UNINTERESTING 01
|
|
|
|
|
|
|
|
#define REV_SHIFT 2
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
#define MAX_REVS (FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2006-12-15 00:58:56 +01:00
|
|
|
#define DEFAULT_REFLOG 4
|
|
|
|
|
2009-04-22 23:41:25 +02:00
|
|
|
static const char *get_color_code(int idx)
|
|
|
|
{
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
|
|
|
if (want_color(showbranch_use_color))
|
2011-04-05 07:40:23 +02:00
|
|
|
return column_colors_ansi[idx % column_colors_ansi_max];
|
2009-04-22 23:41:25 +02:00
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *get_color_reset_code(void)
|
|
|
|
{
|
color: delay auto-color decision until point of use
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
|
|
|
if (want_color(showbranch_use_color))
|
2009-04-22 23:41:25 +02:00
|
|
|
return GIT_COLOR_RESET;
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
static struct commit *interesting(struct commit_list *list)
|
|
|
|
{
|
|
|
|
while (list) {
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
list = list->next;
|
|
|
|
if (commit->object.flags & UNINTERESTING)
|
|
|
|
continue;
|
|
|
|
return commit;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct commit *pop_one_commit(struct commit_list **list_p)
|
|
|
|
{
|
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *list;
|
|
|
|
list = *list_p;
|
|
|
|
commit = list->item;
|
|
|
|
*list_p = list->next;
|
|
|
|
free(list);
|
|
|
|
return commit;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct commit_name {
|
2005-08-30 02:19:47 +02:00
|
|
|
const char *head_name; /* which head's ancestor? */
|
|
|
|
int generation; /* how many parents away from head_name */
|
2005-08-21 11:51:10 +02:00
|
|
|
};
|
|
|
|
|
2005-08-30 02:19:47 +02:00
|
|
|
/* Name the commit as nth generation ancestor of head_name;
|
2005-08-21 11:51:10 +02:00
|
|
|
* we count only the first-parent relationship for naming purposes.
|
|
|
|
*/
|
2005-08-30 02:19:47 +02:00
|
|
|
static void name_commit(struct commit *commit, const char *head_name, int nth)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
|
|
|
struct commit_name *name;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (!commit->util)
|
|
|
|
commit->util = xmalloc(sizeof(struct commit_name));
|
|
|
|
name = commit->util;
|
2005-08-30 02:19:47 +02:00
|
|
|
name->head_name = head_name;
|
2005-08-21 11:51:10 +02:00
|
|
|
name->generation = nth;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parent is the first parent of the commit. We may name it
|
2005-08-30 02:19:47 +02:00
|
|
|
* as (n+1)th generation ancestor of the same head_name as
|
2005-12-08 23:10:02 +01:00
|
|
|
* commit is nth generation ancestor of, if that generation
|
2005-08-21 11:51:10 +02:00
|
|
|
* number is better than the name it already has.
|
|
|
|
*/
|
|
|
|
static void name_parent(struct commit *commit, struct commit *parent)
|
|
|
|
{
|
2006-06-18 03:26:18 +02:00
|
|
|
struct commit_name *commit_name = commit->util;
|
|
|
|
struct commit_name *parent_name = parent->util;
|
2005-08-21 11:51:10 +02:00
|
|
|
if (!commit_name)
|
|
|
|
return;
|
|
|
|
if (!parent_name ||
|
|
|
|
commit_name->generation + 1 < parent_name->generation)
|
2005-08-30 02:19:47 +02:00
|
|
|
name_commit(parent, commit_name->head_name,
|
2005-08-21 11:51:10 +02:00
|
|
|
commit_name->generation + 1);
|
|
|
|
}
|
|
|
|
|
2005-08-30 02:19:47 +02:00
|
|
|
static int name_first_parent_chain(struct commit *c)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
while (c) {
|
|
|
|
struct commit *p;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (!c->util)
|
2005-08-30 02:19:47 +02:00
|
|
|
break;
|
|
|
|
if (!c->parents)
|
|
|
|
break;
|
|
|
|
p = c->parents->item;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (!p->util) {
|
2005-08-30 02:19:47 +02:00
|
|
|
name_parent(c, p);
|
|
|
|
i++;
|
|
|
|
}
|
2006-07-23 19:51:04 +02:00
|
|
|
else
|
|
|
|
break;
|
2005-08-30 02:19:47 +02:00
|
|
|
c = p;
|
|
|
|
}
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void name_commits(struct commit_list *list,
|
|
|
|
struct commit **rev,
|
|
|
|
char **ref_name,
|
|
|
|
int num_rev)
|
|
|
|
{
|
|
|
|
struct commit_list *cl;
|
|
|
|
struct commit *c;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* First give names to the given heads */
|
|
|
|
for (cl = list; cl; cl = cl->next) {
|
|
|
|
c = cl->item;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (c->util)
|
2005-08-30 02:19:47 +02:00
|
|
|
continue;
|
|
|
|
for (i = 0; i < num_rev; i++) {
|
|
|
|
if (rev[i] == c) {
|
|
|
|
name_commit(c, ref_name[i], 0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Then commits on the first parent ancestry chain */
|
|
|
|
do {
|
|
|
|
i = 0;
|
|
|
|
for (cl = list; cl; cl = cl->next) {
|
|
|
|
i += name_first_parent_chain(cl->item);
|
|
|
|
}
|
|
|
|
} while (i);
|
|
|
|
|
|
|
|
/* Finally, any unnamed commits */
|
|
|
|
do {
|
|
|
|
i = 0;
|
|
|
|
for (cl = list; cl; cl = cl->next) {
|
|
|
|
struct commit_list *parents;
|
|
|
|
struct commit_name *n;
|
|
|
|
int nth;
|
|
|
|
c = cl->item;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (!c->util)
|
2005-08-30 02:19:47 +02:00
|
|
|
continue;
|
2006-06-18 03:26:18 +02:00
|
|
|
n = c->util;
|
2005-08-30 02:19:47 +02:00
|
|
|
parents = c->parents;
|
|
|
|
nth = 0;
|
|
|
|
while (parents) {
|
|
|
|
struct commit *p = parents->item;
|
2013-04-05 23:15:50 +02:00
|
|
|
struct strbuf newname = STRBUF_INIT;
|
2005-08-30 02:19:47 +02:00
|
|
|
parents = parents->next;
|
|
|
|
nth++;
|
2006-06-18 03:26:18 +02:00
|
|
|
if (p->util)
|
2005-08-30 02:19:47 +02:00
|
|
|
continue;
|
2005-09-25 08:33:02 +02:00
|
|
|
switch (n->generation) {
|
|
|
|
case 0:
|
2013-04-05 23:15:50 +02:00
|
|
|
strbuf_addstr(&newname, n->head_name);
|
2005-09-25 08:33:02 +02:00
|
|
|
break;
|
|
|
|
case 1:
|
2013-04-05 23:15:50 +02:00
|
|
|
strbuf_addf(&newname, "%s^", n->head_name);
|
2005-09-25 08:33:02 +02:00
|
|
|
break;
|
|
|
|
default:
|
2013-04-05 23:15:50 +02:00
|
|
|
strbuf_addf(&newname, "%s~%d",
|
|
|
|
n->head_name, n->generation);
|
2005-10-12 00:22:48 +02:00
|
|
|
break;
|
2005-09-25 08:33:02 +02:00
|
|
|
}
|
2005-10-12 00:22:48 +02:00
|
|
|
if (nth == 1)
|
2013-04-05 23:15:50 +02:00
|
|
|
strbuf_addch(&newname, '^');
|
2005-10-12 00:22:48 +02:00
|
|
|
else
|
2013-04-05 23:15:50 +02:00
|
|
|
strbuf_addf(&newname, "^%d", nth);
|
|
|
|
name_commit(p, strbuf_detach(&newname, NULL), 0);
|
2005-08-30 02:19:47 +02:00
|
|
|
i++;
|
|
|
|
name_first_parent_chain(p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} while (i);
|
|
|
|
}
|
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
static int mark_seen(struct commit *commit, struct commit_list **seen_p)
|
|
|
|
{
|
|
|
|
if (!commit->object.flags) {
|
2006-07-16 09:00:09 +02:00
|
|
|
commit_list_insert(commit, seen_p);
|
2005-08-21 11:51:10 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void join_revs(struct commit_list **list_p,
|
|
|
|
struct commit_list **seen_p,
|
|
|
|
int num_rev, int extra)
|
|
|
|
{
|
|
|
|
int all_mask = ((1u << (REV_SHIFT + num_rev)) - 1);
|
|
|
|
int all_revs = all_mask & ~((1u << REV_SHIFT) - 1);
|
|
|
|
|
|
|
|
while (*list_p) {
|
|
|
|
struct commit_list *parents;
|
2005-11-10 08:36:15 +01:00
|
|
|
int still_interesting = !!interesting(*list_p);
|
2005-08-21 11:51:10 +02:00
|
|
|
struct commit *commit = pop_one_commit(list_p);
|
|
|
|
int flags = commit->object.flags & all_mask;
|
|
|
|
|
2005-11-10 08:36:15 +01:00
|
|
|
if (!still_interesting && extra <= 0)
|
2005-08-21 11:51:10 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
mark_seen(commit, seen_p);
|
|
|
|
if ((flags & all_revs) == all_revs)
|
|
|
|
flags |= UNINTERESTING;
|
|
|
|
parents = commit->parents;
|
|
|
|
|
|
|
|
while (parents) {
|
|
|
|
struct commit *p = parents->item;
|
|
|
|
int this_flag = p->object.flags;
|
|
|
|
parents = parents->next;
|
|
|
|
if ((this_flag & flags) == flags)
|
|
|
|
continue;
|
2005-11-11 00:47:58 +01:00
|
|
|
if (!p->object.parsed)
|
|
|
|
parse_commit(p);
|
2005-08-21 11:51:10 +02:00
|
|
|
if (mark_seen(p, seen_p) && !still_interesting)
|
|
|
|
extra--;
|
|
|
|
p->object.flags |= flags;
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date(p, list_p);
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
}
|
2005-11-11 00:47:58 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Postprocess to complete well-poisoning.
|
|
|
|
*
|
|
|
|
* At this point we have all the commits we have seen in
|
2006-07-16 09:00:09 +02:00
|
|
|
* seen_p list. Mark anything that can be reached from
|
|
|
|
* uninteresting commits not interesting.
|
2005-11-11 00:47:58 +01:00
|
|
|
*/
|
|
|
|
for (;;) {
|
|
|
|
int changed = 0;
|
|
|
|
struct commit_list *s;
|
|
|
|
for (s = *seen_p; s; s = s->next) {
|
|
|
|
struct commit *c = s->item;
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
|
|
|
if (((c->object.flags & all_revs) != all_revs) &&
|
|
|
|
!(c->object.flags & UNINTERESTING))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* The current commit is either a merge base or
|
|
|
|
* already uninteresting one. Mark its parents
|
|
|
|
* as uninteresting commits _only_ if they are
|
|
|
|
* already parsed. No reason to find new ones
|
|
|
|
* here.
|
|
|
|
*/
|
|
|
|
parents = c->parents;
|
|
|
|
while (parents) {
|
|
|
|
struct commit *p = parents->item;
|
|
|
|
parents = parents->next;
|
|
|
|
if (!(p->object.flags & UNINTERESTING)) {
|
|
|
|
p->object.flags |= UNINTERESTING;
|
|
|
|
changed = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!changed)
|
|
|
|
break;
|
|
|
|
}
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
2005-10-12 00:22:48 +02:00
|
|
|
static void show_one_commit(struct commit *commit, int no_name)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
2008-10-09 21:12:12 +02:00
|
|
|
struct strbuf pretty = STRBUF_INIT;
|
2007-06-11 09:34:54 +02:00
|
|
|
const char *pretty_str = "(unavailable)";
|
2006-06-18 03:26:18 +02:00
|
|
|
struct commit_name *name = commit->util;
|
2007-06-11 09:34:54 +02:00
|
|
|
|
|
|
|
if (commit->object.parsed) {
|
2011-05-27 00:27:24 +02:00
|
|
|
pp_commit_easy(CMIT_FMT_ONELINE, commit, &pretty);
|
2007-09-10 12:35:06 +02:00
|
|
|
pretty_str = pretty.buf;
|
2007-06-11 09:34:54 +02:00
|
|
|
}
|
|
|
|
if (!prefixcmp(pretty_str, "[PATCH] "))
|
|
|
|
pretty_str += 8;
|
2005-10-12 00:22:48 +02:00
|
|
|
|
|
|
|
if (!no_name) {
|
|
|
|
if (name && name->head_name) {
|
|
|
|
printf("[%s", name->head_name);
|
|
|
|
if (name->generation) {
|
|
|
|
if (name->generation == 1)
|
|
|
|
printf("^");
|
|
|
|
else
|
|
|
|
printf("~%d", name->generation);
|
|
|
|
}
|
|
|
|
printf("] ");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
printf("[%s] ",
|
2010-05-24 10:50:44 +02:00
|
|
|
find_unique_abbrev(commit->object.sha1,
|
|
|
|
DEFAULT_ABBREV));
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
2007-06-11 09:34:54 +02:00
|
|
|
puts(pretty_str);
|
2007-09-10 12:35:06 +02:00
|
|
|
strbuf_release(&pretty);
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *ref_name[MAX_REVS + 1];
|
|
|
|
static int ref_name_cnt;
|
|
|
|
|
2005-12-23 21:47:18 +01:00
|
|
|
static const char *find_digit_prefix(const char *s, int *v)
|
|
|
|
{
|
|
|
|
const char *p;
|
|
|
|
int ver;
|
|
|
|
char ch;
|
|
|
|
|
|
|
|
for (p = s, ver = 0;
|
|
|
|
'0' <= (ch = *p) && ch <= '9';
|
|
|
|
p++)
|
|
|
|
ver = ver * 10 + ch - '0';
|
|
|
|
*v = ver;
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int version_cmp(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
while (1) {
|
|
|
|
int va, vb;
|
|
|
|
|
|
|
|
a = find_digit_prefix(a, &va);
|
|
|
|
b = find_digit_prefix(b, &vb);
|
|
|
|
if (va != vb)
|
|
|
|
return va - vb;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
int ca = *a;
|
|
|
|
int cb = *b;
|
|
|
|
if ('0' <= ca && ca <= '9')
|
|
|
|
ca = 0;
|
|
|
|
if ('0' <= cb && cb <= '9')
|
|
|
|
cb = 0;
|
|
|
|
if (ca != cb)
|
|
|
|
return ca - cb;
|
|
|
|
if (!ca)
|
|
|
|
break;
|
|
|
|
a++;
|
|
|
|
b++;
|
|
|
|
}
|
|
|
|
if (!*a && !*b)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-25 08:26:20 +02:00
|
|
|
static int compare_ref_name(const void *a_, const void *b_)
|
|
|
|
{
|
|
|
|
const char * const*a = a_, * const*b = b_;
|
2005-12-23 21:47:18 +01:00
|
|
|
return version_cmp(*a, *b);
|
2005-08-25 08:26:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sort_ref_range(int bottom, int top)
|
|
|
|
{
|
|
|
|
qsort(ref_name + bottom, top - bottom, sizeof(ref_name[0]),
|
|
|
|
compare_ref_name);
|
|
|
|
}
|
|
|
|
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
static int append_ref(const char *refname, const unsigned char *sha1,
|
|
|
|
int allow_dups)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
|
|
|
struct commit *commit = lookup_commit_reference_gently(sha1, 1);
|
2005-12-23 21:47:18 +01:00
|
|
|
int i;
|
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
if (!commit)
|
|
|
|
return 0;
|
2005-12-23 21:47:18 +01:00
|
|
|
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
if (!allow_dups) {
|
|
|
|
/* Avoid adding the same thing twice */
|
|
|
|
for (i = 0; i < ref_name_cnt; i++)
|
|
|
|
if (!strcmp(refname, ref_name[i]))
|
|
|
|
return 0;
|
|
|
|
}
|
2005-10-23 10:18:42 +02:00
|
|
|
if (MAX_REVS <= ref_name_cnt) {
|
2009-03-24 02:09:15 +01:00
|
|
|
warning("ignoring %s; cannot handle more than %d refs",
|
2005-08-21 11:51:10 +02:00
|
|
|
refname, MAX_REVS);
|
|
|
|
return 0;
|
|
|
|
}
|
2006-09-02 06:16:31 +02:00
|
|
|
ref_name[ref_name_cnt++] = xstrdup(refname);
|
2005-08-21 11:51:10 +02:00
|
|
|
ref_name[ref_name_cnt] = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-09-21 07:02:01 +02:00
|
|
|
static int append_head_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
2005-11-21 09:43:12 +01:00
|
|
|
unsigned char tmp[20];
|
|
|
|
int ofs = 11;
|
2007-02-20 10:55:07 +01:00
|
|
|
if (prefixcmp(refname, "refs/heads/"))
|
2005-08-21 11:51:10 +02:00
|
|
|
return 0;
|
2005-11-21 09:43:12 +01:00
|
|
|
/* If both heads/foo and tags/foo exists, get_sha1 would
|
|
|
|
* get confused.
|
|
|
|
*/
|
2006-08-17 20:54:57 +02:00
|
|
|
if (get_sha1(refname + ofs, tmp) || hashcmp(tmp, sha1))
|
2005-11-21 09:43:12 +01:00
|
|
|
ofs = 5;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
return append_ref(refname + ofs, sha1, 0);
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
2006-12-22 14:58:39 +01:00
|
|
|
static int append_remote_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
|
|
|
{
|
|
|
|
unsigned char tmp[20];
|
|
|
|
int ofs = 13;
|
2007-02-20 10:55:07 +01:00
|
|
|
if (prefixcmp(refname, "refs/remotes/"))
|
2006-12-22 14:58:39 +01:00
|
|
|
return 0;
|
|
|
|
/* If both heads/foo and tags/foo exists, get_sha1 would
|
|
|
|
* get confused.
|
|
|
|
*/
|
|
|
|
if (get_sha1(refname + ofs, tmp) || hashcmp(tmp, sha1))
|
|
|
|
ofs = 5;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
return append_ref(refname + ofs, sha1, 0);
|
2006-12-22 14:58:39 +01:00
|
|
|
}
|
|
|
|
|
2006-09-21 07:02:01 +02:00
|
|
|
static int append_tag_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
if (prefixcmp(refname, "refs/tags/"))
|
2005-08-21 11:51:10 +02:00
|
|
|
return 0;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
return append_ref(refname + 5, sha1, 0);
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
2005-12-05 00:58:50 +01:00
|
|
|
static const char *match_ref_pattern = NULL;
|
|
|
|
static int match_ref_slash = 0;
|
|
|
|
static int count_slash(const char *s)
|
|
|
|
{
|
|
|
|
int cnt = 0;
|
|
|
|
while (*s)
|
|
|
|
if (*s++ == '/')
|
|
|
|
cnt++;
|
|
|
|
return cnt;
|
|
|
|
}
|
|
|
|
|
2006-09-21 07:02:01 +02:00
|
|
|
static int append_matching_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
2005-12-05 00:58:50 +01:00
|
|
|
{
|
|
|
|
/* we want to allow pattern hold/<asterisk> to show all
|
|
|
|
* branches under refs/heads/hold/, and v0.99.9? to show
|
|
|
|
* refs/tags/v0.99.9a and friends.
|
|
|
|
*/
|
|
|
|
const char *tail;
|
|
|
|
int slash = count_slash(refname);
|
|
|
|
for (tail = refname; *tail && match_ref_slash < slash; )
|
|
|
|
if (*tail++ == '/')
|
|
|
|
slash--;
|
|
|
|
if (!*tail)
|
|
|
|
return 0;
|
|
|
|
if (fnmatch(match_ref_pattern, tail, 0))
|
|
|
|
return 0;
|
2007-02-20 10:54:00 +01:00
|
|
|
if (!prefixcmp(refname, "refs/heads/"))
|
2006-09-21 07:02:01 +02:00
|
|
|
return append_head_ref(refname, sha1, flag, cb_data);
|
2007-02-20 10:54:00 +01:00
|
|
|
if (!prefixcmp(refname, "refs/tags/"))
|
2006-09-21 07:02:01 +02:00
|
|
|
return append_tag_ref(refname, sha1, flag, cb_data);
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
return append_ref(refname, sha1, 0);
|
2005-12-05 00:58:50 +01:00
|
|
|
}
|
|
|
|
|
2006-12-22 14:58:39 +01:00
|
|
|
static void snarf_refs(int head, int remotes)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
2005-08-25 08:26:20 +02:00
|
|
|
if (head) {
|
|
|
|
int orig_cnt = ref_name_cnt;
|
2006-09-21 06:47:42 +02:00
|
|
|
for_each_ref(append_head_ref, NULL);
|
2005-08-25 08:26:20 +02:00
|
|
|
sort_ref_range(orig_cnt, ref_name_cnt);
|
|
|
|
}
|
2006-12-22 14:58:39 +01:00
|
|
|
if (remotes) {
|
2005-08-25 08:26:20 +02:00
|
|
|
int orig_cnt = ref_name_cnt;
|
2006-12-22 14:58:39 +01:00
|
|
|
for_each_ref(append_remote_ref, NULL);
|
2005-08-25 08:26:20 +02:00
|
|
|
sort_ref_range(orig_cnt, ref_name_cnt);
|
|
|
|
}
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
2006-09-12 05:17:35 +02:00
|
|
|
static int rev_is_head(char *head, int headlen, char *name,
|
2005-08-21 11:51:10 +02:00
|
|
|
unsigned char *head_sha1, unsigned char *sha1)
|
|
|
|
{
|
2006-09-12 05:17:35 +02:00
|
|
|
if ((!head[0]) ||
|
2006-08-17 20:54:57 +02:00
|
|
|
(head_sha1 && sha1 && hashcmp(head_sha1, sha1)))
|
2005-08-21 11:51:10 +02:00
|
|
|
return 0;
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
if (!prefixcmp(head, "refs/heads/"))
|
2006-09-22 00:07:01 +02:00
|
|
|
head += 11;
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
if (!prefixcmp(name, "refs/heads/"))
|
2006-09-22 00:07:01 +02:00
|
|
|
name += 11;
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
else if (!prefixcmp(name, "heads/"))
|
2006-09-22 00:07:01 +02:00
|
|
|
name += 6;
|
2006-09-12 05:17:35 +02:00
|
|
|
return !strcmp(head, name);
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static int show_merge_base(struct commit_list *seen, int num_rev)
|
|
|
|
{
|
|
|
|
int all_mask = ((1u << (REV_SHIFT + num_rev)) - 1);
|
|
|
|
int all_revs = all_mask & ~((1u << REV_SHIFT) - 1);
|
2005-09-08 21:15:52 +02:00
|
|
|
int exit_status = 1;
|
2005-08-21 11:51:10 +02:00
|
|
|
|
|
|
|
while (seen) {
|
|
|
|
struct commit *commit = pop_one_commit(&seen);
|
|
|
|
int flags = commit->object.flags & all_mask;
|
|
|
|
if (!(flags & UNINTERESTING) &&
|
|
|
|
((flags & all_revs) == all_revs)) {
|
|
|
|
puts(sha1_to_hex(commit->object.sha1));
|
2005-09-08 21:15:52 +02:00
|
|
|
exit_status = 0;
|
|
|
|
commit->object.flags |= UNINTERESTING;
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
}
|
2005-09-08 21:15:52 +02:00
|
|
|
return exit_status;
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
|
2005-09-10 00:40:45 +02:00
|
|
|
static int show_independent(struct commit **rev,
|
|
|
|
int num_rev,
|
|
|
|
char **ref_name,
|
|
|
|
unsigned int *rev_mask)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < num_rev; i++) {
|
|
|
|
struct commit *commit = rev[i];
|
|
|
|
unsigned int flag = rev_mask[i];
|
|
|
|
|
|
|
|
if (commit->object.flags == flag)
|
|
|
|
puts(sha1_to_hex(commit->object.sha1));
|
|
|
|
commit->object.flags |= UNINTERESTING;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-12-05 00:58:50 +01:00
|
|
|
static void append_one_rev(const char *av)
|
|
|
|
{
|
|
|
|
unsigned char revkey[20];
|
|
|
|
if (!get_sha1(av, revkey)) {
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
append_ref(av, revkey, 0);
|
2005-12-05 00:58:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2006-01-11 09:20:25 +01:00
|
|
|
if (strchr(av, '*') || strchr(av, '?') || strchr(av, '[')) {
|
2005-12-05 00:58:50 +01:00
|
|
|
/* glob style match */
|
|
|
|
int saved_matches = ref_name_cnt;
|
|
|
|
match_ref_pattern = av;
|
|
|
|
match_ref_slash = count_slash(av);
|
2006-09-21 06:47:42 +02:00
|
|
|
for_each_ref(append_matching_ref, NULL);
|
2005-12-05 00:58:50 +01:00
|
|
|
if (saved_matches == ref_name_cnt &&
|
|
|
|
ref_name_cnt < MAX_REVS)
|
|
|
|
error("no matching refs with %s", av);
|
2005-12-16 02:53:44 +01:00
|
|
|
if (saved_matches + 1 < ref_name_cnt)
|
|
|
|
sort_ref_range(saved_matches, ref_name_cnt);
|
2005-12-05 00:58:50 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
die("bad sha1 reference %s", av);
|
|
|
|
}
|
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
static int git_show_branch_config(const char *var, const char *value, void *cb)
|
2006-01-09 22:29:23 +01:00
|
|
|
{
|
|
|
|
if (!strcmp(var, "showbranch.default")) {
|
2008-02-11 19:51:03 +01:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2009-06-09 08:26:44 +02:00
|
|
|
/*
|
|
|
|
* default_arg is now passed to parse_options(), so we need to
|
2010-02-04 06:23:18 +01:00
|
|
|
* mimic the real argv a bit better.
|
2009-06-09 08:26:44 +02:00
|
|
|
*/
|
|
|
|
if (!default_num) {
|
|
|
|
default_alloc = 20;
|
|
|
|
default_arg = xcalloc(default_alloc, sizeof(*default_arg));
|
|
|
|
default_arg[default_num++] = "show-branch";
|
|
|
|
} else if (default_alloc <= default_num + 1) {
|
2006-01-09 22:29:23 +01:00
|
|
|
default_alloc = default_alloc * 3 / 2 + 20;
|
|
|
|
default_arg = xrealloc(default_arg, sizeof *default_arg * default_alloc);
|
|
|
|
}
|
2006-09-02 06:16:31 +02:00
|
|
|
default_arg[default_num++] = xstrdup(value);
|
2006-01-09 22:29:23 +01:00
|
|
|
default_arg[default_num] = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-22 23:41:25 +02:00
|
|
|
if (!strcmp(var, "color.showbranch")) {
|
2011-08-18 07:03:48 +02:00
|
|
|
showbranch_use_color = git_config_colorbool(var, value);
|
2009-04-22 23:41:25 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return git_color_default_config(var, value, cb);
|
2006-01-09 22:29:23 +01:00
|
|
|
}
|
|
|
|
|
2006-05-02 02:12:26 +02:00
|
|
|
static int omit_in_dense(struct commit *commit, struct commit **rev, int n)
|
|
|
|
{
|
|
|
|
/* If the commit is tip of the named branches, do not
|
|
|
|
* omit it.
|
|
|
|
* Otherwise, if it is a merge that is reachable from only one
|
|
|
|
* tip, it is not that interesting.
|
|
|
|
*/
|
|
|
|
int i, flag, count;
|
|
|
|
for (i = 0; i < n; i++)
|
|
|
|
if (rev[i] == commit)
|
|
|
|
return 0;
|
|
|
|
flag = commit->object.flags;
|
|
|
|
for (i = count = 0; i < n; i++) {
|
|
|
|
if (flag & (1u << (i + REV_SHIFT)))
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
if (count == 1)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-21 09:33:18 +02:00
|
|
|
static int reflog = 0;
|
|
|
|
|
|
|
|
static int parse_reflog_param(const struct option *opt, const char *arg,
|
|
|
|
int unset)
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
{
|
|
|
|
char *ep;
|
2009-05-21 09:33:18 +02:00
|
|
|
const char **base = (const char **)opt->value;
|
|
|
|
if (!arg)
|
|
|
|
arg = "";
|
|
|
|
reflog = strtoul(arg, &ep, 10);
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
if (*ep == ',')
|
|
|
|
*base = ep + 1;
|
|
|
|
else if (*ep)
|
2009-05-21 09:33:18 +02:00
|
|
|
return error("unrecognized reflog param '%s'", arg);
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
else
|
|
|
|
*base = NULL;
|
2009-05-21 09:33:18 +02:00
|
|
|
if (reflog <= 0)
|
|
|
|
reflog = DEFAULT_REFLOG;
|
|
|
|
return 0;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
}
|
|
|
|
|
2006-07-29 07:44:25 +02:00
|
|
|
int cmd_show_branch(int ac, const char **av, const char *prefix)
|
2005-08-21 11:51:10 +02:00
|
|
|
{
|
|
|
|
struct commit *rev[MAX_REVS], *commit;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
char *reflog_msg[MAX_REVS];
|
2005-08-21 11:51:10 +02:00
|
|
|
struct commit_list *list = NULL, *seen = NULL;
|
2005-09-10 00:40:45 +02:00
|
|
|
unsigned int rev_mask[MAX_REVS];
|
2005-08-21 11:51:10 +02:00
|
|
|
int num_rev, i, extra = 0;
|
2006-12-22 14:58:39 +01:00
|
|
|
int all_heads = 0, all_remotes = 0;
|
2005-11-11 00:47:58 +01:00
|
|
|
int all_mask, all_revs;
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
enum rev_sort_order sort_order = REV_SORT_IN_GRAPH_ORDER;
|
2006-09-12 05:17:35 +02:00
|
|
|
char head[128];
|
|
|
|
const char *head_p;
|
|
|
|
int head_len;
|
2005-08-21 11:51:10 +02:00
|
|
|
unsigned char head_sha1[20];
|
|
|
|
int merge_base = 0;
|
2005-09-10 00:40:45 +02:00
|
|
|
int independent = 0;
|
2005-10-12 00:22:48 +02:00
|
|
|
int no_name = 0;
|
|
|
|
int sha1_name = 0;
|
2005-11-11 00:47:58 +01:00
|
|
|
int shown_merge_point = 0;
|
2006-01-11 09:16:42 +01:00
|
|
|
int with_current_branch = 0;
|
2006-01-11 23:02:38 +01:00
|
|
|
int head_at = -1;
|
2006-03-03 02:14:00 +01:00
|
|
|
int topics = 0;
|
2006-05-02 02:12:26 +02:00
|
|
|
int dense = 1;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
const char *reflog_base = NULL;
|
2009-05-21 09:33:18 +02:00
|
|
|
struct option builtin_show_branch_options[] = {
|
|
|
|
OPT_BOOLEAN('a', "all", &all_heads,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show remote-tracking and local branches")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN('r', "remotes", &all_remotes,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show remote-tracking branches")),
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 05:55:58 +01:00
|
|
|
OPT__COLOR(&showbranch_use_color,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("color '*!+-' corresponding to the branch")),
|
|
|
|
{ OPTION_INTEGER, 0, "more", &extra, N_("n"),
|
|
|
|
N_("show <n> more commits after the common ancestor"),
|
2009-06-08 01:39:15 +02:00
|
|
|
PARSE_OPT_OPTARG, NULL, (intptr_t)1 },
|
2012-08-20 14:32:44 +02:00
|
|
|
OPT_SET_INT(0, "list", &extra, N_("synonym to more=-1"), -1),
|
|
|
|
OPT_BOOLEAN(0, "no-name", &no_name, N_("suppress naming strings")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN(0, "current", &with_current_branch,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("include the current branch")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN(0, "sha1-name", &sha1_name,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("name commits with their object names")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN(0, "merge-base", &merge_base,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show possible merge bases")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN(0, "independent", &independent,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show refs unreachable from any other ref")),
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
OPT_SET_INT(0, "topo-order", &sort_order,
|
|
|
|
N_("show commits in topological order"),
|
|
|
|
REV_SORT_IN_GRAPH_ORDER),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_BOOLEAN(0, "topics", &topics,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show only commits not on the first branch")),
|
2009-05-21 09:33:18 +02:00
|
|
|
OPT_SET_INT(0, "sparse", &dense,
|
2012-08-20 14:32:44 +02:00
|
|
|
N_("show merges reachable from only one tip"), 0),
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
OPT_SET_INT(0, "date-order", &sort_order,
|
2013-07-18 14:26:56 +02:00
|
|
|
N_("topologically sort, maintaining date order "
|
2013-07-22 20:23:30 +02:00
|
|
|
"where possible"),
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
REV_SORT_BY_COMMIT_DATE),
|
2012-08-20 14:32:44 +02:00
|
|
|
{ OPTION_CALLBACK, 'g', "reflog", &reflog_base, N_("<n>[,<base>]"),
|
|
|
|
N_("show <n> most recent ref-log entries starting at "
|
|
|
|
"base"),
|
2009-05-21 09:33:18 +02:00
|
|
|
PARSE_OPT_OPTARG | PARSE_OPT_LITERAL_ARGHELP,
|
|
|
|
parse_reflog_param },
|
|
|
|
OPT_END()
|
|
|
|
};
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
git_config(git_show_branch_config, NULL);
|
2005-08-31 01:59:37 +02:00
|
|
|
|
2006-01-09 22:29:23 +01:00
|
|
|
/* If nothing is specified, try the default first */
|
|
|
|
if (ac == 1 && default_num) {
|
2009-06-09 08:26:44 +02:00
|
|
|
ac = default_num;
|
|
|
|
av = default_arg;
|
2006-01-09 22:29:23 +01:00
|
|
|
}
|
|
|
|
|
2009-05-23 20:53:12 +02:00
|
|
|
ac = parse_options(ac, av, prefix, builtin_show_branch_options,
|
2009-05-21 09:33:18 +02:00
|
|
|
show_branch_usage, PARSE_OPT_STOP_AT_NON_OPTION);
|
|
|
|
if (all_heads)
|
|
|
|
all_remotes = 1;
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2007-01-26 07:14:45 +01:00
|
|
|
if (extra || reflog) {
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
/* "listing" mode is incompatible with
|
|
|
|
* independent nor merge-base modes.
|
|
|
|
*/
|
|
|
|
if (independent || merge_base)
|
2009-05-21 09:33:18 +02:00
|
|
|
usage_with_options(show_branch_usage,
|
|
|
|
builtin_show_branch_options);
|
2007-01-26 07:14:45 +01:00
|
|
|
if (reflog && ((0 < extra) || all_heads || all_remotes))
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
/*
|
|
|
|
* Asking for --more in reflog mode does not
|
2007-01-20 07:51:49 +01:00
|
|
|
* make sense. --list is Ok.
|
|
|
|
*
|
|
|
|
* Also --all and --remotes do not make sense either.
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
*/
|
2009-05-21 09:33:18 +02:00
|
|
|
die("--reflog is incompatible with --all, --remotes, "
|
|
|
|
"--independent or --merge-base");
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
}
|
2005-09-10 00:40:45 +02:00
|
|
|
|
2005-12-23 21:47:18 +01:00
|
|
|
/* If nothing is specified, show all branches by default */
|
2006-12-22 14:58:39 +01:00
|
|
|
if (ac + all_heads + all_remotes == 0)
|
2005-12-23 21:47:18 +01:00
|
|
|
all_heads = 1;
|
|
|
|
|
2006-12-15 00:58:56 +01:00
|
|
|
if (reflog) {
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
unsigned char sha1[20];
|
|
|
|
char nth_desc[256];
|
|
|
|
char *ref;
|
|
|
|
int base = 0;
|
2007-01-26 07:14:45 +01:00
|
|
|
|
|
|
|
if (ac == 0) {
|
|
|
|
static const char *fake_av[2];
|
2007-02-04 08:31:47 +01:00
|
|
|
|
2011-12-13 15:17:48 +01:00
|
|
|
fake_av[0] = resolve_refdup("HEAD", sha1, 1, NULL);
|
2007-01-26 07:14:45 +01:00
|
|
|
fake_av[1] = NULL;
|
|
|
|
av = fake_av;
|
|
|
|
ac = 1;
|
|
|
|
}
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
if (ac != 1)
|
2006-12-15 00:58:56 +01:00
|
|
|
die("--reflog option needs one branch name");
|
2007-01-26 07:14:45 +01:00
|
|
|
|
2007-01-20 07:51:49 +01:00
|
|
|
if (MAX_REVS < reflog)
|
|
|
|
die("Only %d entries can be shown at one time.",
|
|
|
|
MAX_REVS);
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
if (!dwim_ref(*av, strlen(*av), sha1, &ref))
|
|
|
|
die("No such ref %s", *av);
|
|
|
|
|
|
|
|
/* Has the base been specified? */
|
|
|
|
if (reflog_base) {
|
|
|
|
char *ep;
|
|
|
|
base = strtoul(reflog_base, &ep, 10);
|
|
|
|
if (*ep) {
|
|
|
|
/* Ah, that is a date spec... */
|
|
|
|
unsigned long at;
|
|
|
|
at = approxidate(reflog_base);
|
|
|
|
read_ref_at(ref, at, -1, sha1, NULL,
|
|
|
|
NULL, NULL, &base);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-12-15 00:58:56 +01:00
|
|
|
for (i = 0; i < reflog; i++) {
|
2007-03-07 02:44:17 +01:00
|
|
|
char *logmsg, *m;
|
|
|
|
const char *msg;
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
unsigned long timestamp;
|
|
|
|
int tz;
|
|
|
|
|
|
|
|
if (read_ref_at(ref, 0, base+i, sha1, &logmsg,
|
|
|
|
×tamp, &tz, NULL)) {
|
|
|
|
reflog = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
msg = strchr(logmsg, '\t');
|
|
|
|
if (!msg)
|
|
|
|
msg = "(none)";
|
|
|
|
else
|
|
|
|
msg++;
|
|
|
|
m = xmalloc(strlen(msg) + 200);
|
|
|
|
sprintf(m, "(%s) %s",
|
2007-01-21 03:57:06 +01:00
|
|
|
show_date(timestamp, tz, 1),
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
msg);
|
|
|
|
reflog_msg[i] = m;
|
|
|
|
free(logmsg);
|
|
|
|
sprintf(nth_desc, "%s@{%d}", *av, base+i);
|
|
|
|
append_ref(nth_desc, sha1, 1);
|
2006-12-15 00:58:56 +01:00
|
|
|
}
|
|
|
|
}
|
2007-01-26 07:14:45 +01:00
|
|
|
else if (all_heads + all_remotes)
|
|
|
|
snarf_refs(all_heads, all_remotes);
|
2006-12-15 00:58:56 +01:00
|
|
|
else {
|
|
|
|
while (0 < ac) {
|
|
|
|
append_one_rev(*av);
|
|
|
|
ac--; av++;
|
|
|
|
}
|
2005-12-05 00:58:50 +01:00
|
|
|
}
|
2005-12-23 21:47:18 +01:00
|
|
|
|
2011-12-12 12:20:32 +01:00
|
|
|
head_p = resolve_ref_unsafe("HEAD", head_sha1, 1, NULL);
|
2006-09-12 05:17:35 +02:00
|
|
|
if (head_p) {
|
|
|
|
head_len = strlen(head_p);
|
|
|
|
memcpy(head, head_p, head_len + 1);
|
2006-01-11 09:16:42 +01:00
|
|
|
}
|
|
|
|
else {
|
2006-09-12 05:17:35 +02:00
|
|
|
head_len = 0;
|
|
|
|
head[0] = 0;
|
2006-01-11 09:16:42 +01:00
|
|
|
}
|
|
|
|
|
2006-09-12 05:17:35 +02:00
|
|
|
if (with_current_branch && head_p) {
|
2006-01-11 09:16:42 +01:00
|
|
|
int has_head = 0;
|
|
|
|
for (i = 0; !has_head && i < ref_name_cnt; i++) {
|
|
|
|
/* We are only interested in adding the branch
|
|
|
|
* HEAD points at.
|
|
|
|
*/
|
2006-09-12 05:17:35 +02:00
|
|
|
if (rev_is_head(head,
|
|
|
|
head_len,
|
2006-01-11 09:16:42 +01:00
|
|
|
ref_name[i],
|
|
|
|
head_sha1, NULL))
|
|
|
|
has_head++;
|
|
|
|
}
|
|
|
|
if (!has_head) {
|
2008-05-27 00:09:51 +02:00
|
|
|
int offset = !prefixcmp(head, "refs/heads/") ? 11 : 0;
|
|
|
|
append_one_rev(head + offset);
|
2006-01-11 09:16:42 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-12-05 00:58:50 +01:00
|
|
|
if (!ref_name_cnt) {
|
|
|
|
fprintf(stderr, "No revs to be shown.\n");
|
|
|
|
exit(0);
|
|
|
|
}
|
2005-08-21 11:51:10 +02:00
|
|
|
|
|
|
|
for (num_rev = 0; ref_name[num_rev]; num_rev++) {
|
|
|
|
unsigned char revkey[20];
|
2005-09-10 00:40:45 +02:00
|
|
|
unsigned int flag = 1u << (num_rev + REV_SHIFT);
|
2005-08-21 11:51:10 +02:00
|
|
|
|
|
|
|
if (MAX_REVS <= num_rev)
|
|
|
|
die("cannot handle more than %d revs.", MAX_REVS);
|
|
|
|
if (get_sha1(ref_name[num_rev], revkey))
|
2005-12-15 08:47:30 +01:00
|
|
|
die("'%s' is not a valid ref.", ref_name[num_rev]);
|
2005-08-21 11:51:10 +02:00
|
|
|
commit = lookup_commit_reference(revkey);
|
|
|
|
if (!commit)
|
|
|
|
die("cannot find commit %s (%s)",
|
|
|
|
ref_name[num_rev], revkey);
|
|
|
|
parse_commit(commit);
|
|
|
|
mark_seen(commit, &seen);
|
|
|
|
|
|
|
|
/* rev#0 uses bit REV_SHIFT, rev#1 uses bit REV_SHIFT+1,
|
|
|
|
* and so on. REV_SHIFT bits from bit 0 are used for
|
|
|
|
* internal bookkeeping.
|
|
|
|
*/
|
2005-09-10 00:40:45 +02:00
|
|
|
commit->object.flags |= flag;
|
|
|
|
if (commit->object.flags == flag)
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date(commit, &list);
|
2005-08-21 11:51:10 +02:00
|
|
|
rev[num_rev] = commit;
|
|
|
|
}
|
2005-09-10 00:40:45 +02:00
|
|
|
for (i = 0; i < num_rev; i++)
|
|
|
|
rev_mask[i] = rev[i]->object.flags;
|
|
|
|
|
|
|
|
if (0 <= extra)
|
|
|
|
join_revs(&list, &seen, num_rev, extra);
|
2005-08-21 11:51:10 +02:00
|
|
|
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_sort_by_date(&seen);
|
2006-07-16 09:00:09 +02:00
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
if (merge_base)
|
|
|
|
return show_merge_base(seen, num_rev);
|
|
|
|
|
2005-09-10 00:40:45 +02:00
|
|
|
if (independent)
|
|
|
|
return show_independent(rev, num_rev, ref_name, rev_mask);
|
|
|
|
|
|
|
|
/* Show list; --more=-1 means list-only */
|
2005-09-11 03:24:46 +02:00
|
|
|
if (1 < num_rev || extra < 0) {
|
2005-08-21 11:51:10 +02:00
|
|
|
for (i = 0; i < num_rev; i++) {
|
|
|
|
int j;
|
2006-09-12 05:17:35 +02:00
|
|
|
int is_head = rev_is_head(head,
|
|
|
|
head_len,
|
2005-08-21 11:51:10 +02:00
|
|
|
ref_name[i],
|
|
|
|
head_sha1,
|
|
|
|
rev[i]->object.sha1);
|
2005-09-10 00:40:45 +02:00
|
|
|
if (extra < 0)
|
|
|
|
printf("%c [%s] ",
|
|
|
|
is_head ? '*' : ' ', ref_name[i]);
|
|
|
|
else {
|
|
|
|
for (j = 0; j < i; j++)
|
|
|
|
putchar(' ');
|
2009-04-22 23:41:25 +02:00
|
|
|
printf("%s%c%s [%s] ",
|
2011-04-05 07:40:23 +02:00
|
|
|
get_color_code(i),
|
2009-04-22 23:41:25 +02:00
|
|
|
is_head ? '*' : '!',
|
|
|
|
get_color_reset_code(), ref_name[i]);
|
2005-09-10 00:40:45 +02:00
|
|
|
}
|
show-branch --reflog: show the reflog message at the top.
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 10:20:23 +01:00
|
|
|
|
|
|
|
if (!reflog) {
|
|
|
|
/* header lines never need name */
|
|
|
|
show_one_commit(rev[i], 1);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
puts(reflog_msg[i]);
|
|
|
|
|
2006-01-11 23:02:38 +01:00
|
|
|
if (is_head)
|
|
|
|
head_at = i;
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
2005-09-10 00:40:45 +02:00
|
|
|
if (0 <= extra) {
|
|
|
|
for (i = 0; i < num_rev; i++)
|
|
|
|
putchar('-');
|
|
|
|
putchar('\n');
|
|
|
|
}
|
2005-08-23 08:16:46 +02:00
|
|
|
}
|
2005-09-10 00:40:45 +02:00
|
|
|
if (extra < 0)
|
|
|
|
exit(0);
|
2005-08-23 08:16:46 +02:00
|
|
|
|
2005-08-30 02:19:47 +02:00
|
|
|
/* Sort topologically */
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
sort_in_topological_order(&seen, sort_order);
|
2005-08-30 02:19:47 +02:00
|
|
|
|
|
|
|
/* Give names to commits */
|
2005-10-12 00:22:48 +02:00
|
|
|
if (!sha1_name && !no_name)
|
|
|
|
name_commits(seen, rev, ref_name, num_rev);
|
2005-08-30 02:19:47 +02:00
|
|
|
|
|
|
|
all_mask = ((1u << (REV_SHIFT + num_rev)) - 1);
|
|
|
|
all_revs = all_mask & ~((1u << REV_SHIFT) - 1);
|
|
|
|
|
2005-08-21 11:51:10 +02:00
|
|
|
while (seen) {
|
|
|
|
struct commit *commit = pop_one_commit(&seen);
|
|
|
|
int this_flag = commit->object.flags;
|
2006-03-03 23:34:40 +01:00
|
|
|
int is_merge_point = ((this_flag & all_revs) == all_revs);
|
2005-08-23 08:16:46 +02:00
|
|
|
|
2006-03-03 23:34:40 +01:00
|
|
|
shown_merge_point |= is_merge_point;
|
2005-08-30 02:19:47 +02:00
|
|
|
|
2005-08-23 08:16:46 +02:00
|
|
|
if (1 < num_rev) {
|
2006-05-02 02:12:26 +02:00
|
|
|
int is_merge = !!(commit->parents &&
|
|
|
|
commit->parents->next);
|
2006-03-03 23:34:40 +01:00
|
|
|
if (topics &&
|
|
|
|
!is_merge_point &&
|
|
|
|
(this_flag & (1u << REV_SHIFT)))
|
|
|
|
continue;
|
2006-05-02 02:12:26 +02:00
|
|
|
if (dense && is_merge &&
|
|
|
|
omit_in_dense(commit, rev, num_rev))
|
|
|
|
continue;
|
2006-01-11 23:02:38 +01:00
|
|
|
for (i = 0; i < num_rev; i++) {
|
|
|
|
int mark;
|
|
|
|
if (!(this_flag & (1u << (i + REV_SHIFT))))
|
|
|
|
mark = ' ';
|
|
|
|
else if (is_merge)
|
|
|
|
mark = '-';
|
|
|
|
else if (i == head_at)
|
|
|
|
mark = '*';
|
|
|
|
else
|
|
|
|
mark = '+';
|
2009-04-22 23:41:25 +02:00
|
|
|
printf("%s%c%s",
|
2011-04-05 07:40:23 +02:00
|
|
|
get_color_code(i),
|
2009-04-22 23:41:25 +02:00
|
|
|
mark, get_color_reset_code());
|
2006-01-11 23:02:38 +01:00
|
|
|
}
|
2005-08-23 08:16:46 +02:00
|
|
|
putchar(' ');
|
|
|
|
}
|
2005-10-12 00:22:48 +02:00
|
|
|
show_one_commit(commit, no_name);
|
2005-11-11 00:47:58 +01:00
|
|
|
|
|
|
|
if (shown_merge_point && --extra < 0)
|
|
|
|
break;
|
2005-08-21 11:51:10 +02:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|