|
|
|
git-show-branch(1)
|
|
|
|
==================
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-show-branch - Show branches and their commits
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
|
|
|
'git show-branch' [-a|--all] [-r|--remotes] [--topo-order | --date-order]
|
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>
15 years ago
|
|
|
[--current] [--color[=<when>] | --no-color] [--sparse]
|
|
|
|
[--more=<n> | --list | --independent | --merge-base]
|
|
|
|
[--no-name | --sha1-name] [--topics]
|
|
|
|
[(<rev> | <glob>)...]
|
|
|
|
'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
|
|
|
Shows the commit ancestry graph starting from the commits named
|
docs: don't talk about $GIT_DIR/refs/ everywhere
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
may also consult the packed refs mechanism. These days we tend to treat
the "refs hierarchy" as more of an abstract namespace that happens to be
represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
worst it can confuse users who then look in $GIT_DIR/refs and find that it
is missing some of the refs they expected to see.
This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
"refs/*", under the assumption that users can handle the concept of an
abstract refs namespace. There are a few things to note:
- most cases just dropped the $GIT_DIR/ portion. But for cases where
that left _just_ the word "refs", I changed it to "refs/" to help
indicate that it was a hierarchy. I didn't do the same for longer
paths (e.g., "refs/heads" remained, instead of becoming
"refs/heads/").
- in some cases, no change was made, as the text was explicitly about
unpacked refs (e.g., the discussion in git-pack-refs).
- In some cases it made sense instead to note the existence of packed
refs (e.g., in check-ref-format and rev-parse).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
15 years ago
|
|
|
with <rev>s or <globs>s (or all refs under refs/heads
|
|
|
|
and/or refs/tags) semi-visually.
|
|
|
|
|
|
|
|
It cannot show more than 29 branches and commits at a time.
|
|
|
|
|
|
|
|
It uses `showbranch.default` multi-valued configuration items if
|
|
|
|
no <rev> nor <glob> is given on the command line.
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
<rev>::
|
|
|
|
Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])
|
|
|
|
that typically names a branch head or a tag.
|
|
|
|
|
|
|
|
<glob>::
|
|
|
|
A glob pattern that matches branch or tag names under
|
docs: don't talk about $GIT_DIR/refs/ everywhere
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
may also consult the packed refs mechanism. These days we tend to treat
the "refs hierarchy" as more of an abstract namespace that happens to be
represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
worst it can confuse users who then look in $GIT_DIR/refs and find that it
is missing some of the refs they expected to see.
This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
"refs/*", under the assumption that users can handle the concept of an
abstract refs namespace. There are a few things to note:
- most cases just dropped the $GIT_DIR/ portion. But for cases where
that left _just_ the word "refs", I changed it to "refs/" to help
indicate that it was a hierarchy. I didn't do the same for longer
paths (e.g., "refs/heads" remained, instead of becoming
"refs/heads/").
- in some cases, no change was made, as the text was explicitly about
unpacked refs (e.g., the discussion in git-pack-refs).
- In some cases it made sense instead to note the existence of packed
refs (e.g., in check-ref-format and rev-parse).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
15 years ago
|
|
|
refs/. For example, if you have many topic
|
|
|
|
branches under refs/heads/topic, giving
|
|
|
|
`topic/*` would show all of them.
|
|
|
|
|
|
|
|
-r::
|
|
|
|
--remotes::
|
|
|
|
Show the remote-tracking branches.
|
|
|
|
|
|
|
|
-a::
|
|
|
|
--all::
|
|
|
|
Show both remote-tracking branches and local branches.
|
|
|
|
|
|
|
|
--current::
|
|
|
|
With this option, the command includes the current
|
|
|
|
branch to the list of revs to be shown when it is not
|
|
|
|
given on the command line.
|
|
|
|
|
|
|
|
--topo-order::
|
|
|
|
By default, the branches and their commits are shown in
|
|
|
|
reverse chronological order. This option makes them
|
|
|
|
appear in topological order (i.e., descendant commits
|
|
|
|
are shown before their parents).
|
|
|
|
|
|
|
|
--date-order::
|
|
|
|
This option is similar to '--topo-order' in the sense that no
|
|
|
|
parent comes before all of its children, but otherwise commits
|
|
|
|
are ordered according to their commit date.
|
|
|
|
|
|
|
|
--sparse::
|
|
|
|
By default, the output omits merges that are reachable
|
|
|
|
from only one tip being shown. This option makes them
|
|
|
|
visible.
|
|
|
|
|
|
|
|
--more=<n>::
|
|
|
|
Usually the command stops output upon showing the commit
|
|
|
|
that is the common ancestor of all the branches. This
|
|
|
|
flag tells the command to go <n> more common commits
|
|
|
|
beyond that. When <n> is negative, display only the
|
|
|
|
<reference>s given, without showing the commit ancestry
|
|
|
|
tree.
|
|
|
|
|
|
|
|
--list::
|
|
|
|
Synonym to `--more=-1`
|
|
|
|
|
|
|
|
--merge-base::
|
|
|
|
Instead of showing the commit list, determine possible
|
|
|
|
merge bases for the specified commits. All merge bases
|
|
|
|
will be contained in all specified commits. This is
|
|
|
|
different from how linkgit:git-merge-base[1] handles
|
|
|
|
the case of three or more commits.
|
|
|
|
|
|
|
|
--independent::
|
|
|
|
Among the <reference>s given, display only the ones that
|
|
|
|
cannot be reached from any other <reference>.
|
|
|
|
|
|
|
|
--no-name::
|
|
|
|
Do not show naming strings for each commit.
|
|
|
|
|
|
|
|
--sha1-name::
|
|
|
|
Instead of naming the commits using the path to reach
|
|
|
|
them from heads (e.g. "master~2" to mean the grandparent
|
|
|
|
of "master"), name them with the unique prefix of their
|
|
|
|
object names.
|
|
|
|
|
|
|
|
--topics::
|
|
|
|
Shows only commits that are NOT on the first branch given.
|
|
|
|
This helps track topic branches by hiding any commit that
|
|
|
|
is already in the main line of development. When given
|
|
|
|
"git show-branch --topics master topic1 topic2", this
|
|
|
|
will show the revisions given by "git rev-list {caret}master
|
|
|
|
topic1 topic2"
|
|
|
|
|
|
|
|
-g::
|
|
|
|
--reflog[=<n>[,<base>]] [<ref>]::
|
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>
18 years ago
|
|
|
Shows <n> most recent ref-log entries for the given
|
|
|
|
ref. If <base> is given, <n> entries going back from
|
|
|
|
that entry. <base> can be specified as count or date.
|
|
|
|
When no explicit <ref> parameter is given, it defaults to the
|
|
|
|
current branch (or `HEAD` if it is detached).
|
|
|
|
|
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>
15 years ago
|
|
|
--color[=<when>]::
|
|
|
|
Color the status sign (one of these: `*` `!` `+` `-`) of each commit
|
|
|
|
corresponding to the branch it's in.
|
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>
15 years ago
|
|
|
The value must be always (the default), never, or auto.
|
|
|
|
|
|
|
|
--no-color::
|
|
|
|
Turn off colored output, even when the configuration file gives the
|
|
|
|
default to color output.
|
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>
15 years ago
|
|
|
Same as `--color=never`.
|
|
|
|
|
|
|
|
Note that --more, --list, --independent and --merge-base options
|
|
|
|
are mutually exclusive.
|
|
|
|
|
|
|
|
|
|
|
|
OUTPUT
|
|
|
|
------
|
|
|
|
Given N <references>, the first N lines are the one-line
|
|
|
|
description from their commit message. The branch head that is
|
|
|
|
pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*`
|
|
|
|
character while other heads are prefixed with a `!` character.
|
|
|
|
|
|
|
|
Following these N lines, one-line log for each commit is
|
|
|
|
displayed, indented N places. If a commit is on the I-th
|
|
|
|
branch, the I-th indentation character shows a `+` sign;
|
|
|
|
otherwise it shows a space. Merge commits are denoted by
|
|
|
|
a `-` sign. Each commit shows a short name that
|
|
|
|
can be used as an extended SHA1 to name that commit.
|
|
|
|
|
|
|
|
The following example shows three branches, "master", "fixes"
|
|
|
|
and "mhf":
|
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
$ git show-branch master fixes mhf
|
|
|
|
* [master] Add 'git show-branch'.
|
|
|
|
! [fixes] Introduce "reset type" flag to "git reset"
|
|
|
|
! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
|
|
|
|
---
|
|
|
|
+ [mhf] Allow "+remote:local" refspec to cause --force when fetching.
|
|
|
|
+ [mhf~1] Use git-octopus when pulling more than one heads.
|
|
|
|
+ [fixes] Introduce "reset type" flag to "git reset"
|
|
|
|
+ [mhf~2] "git fetch --force".
|
|
|
|
+ [mhf~3] Use .git/remote/origin, not .git/branches/origin.
|
|
|
|
+ [mhf~4] Make "git pull" and "git fetch" default to origin
|
|
|
|
+ [mhf~5] Infamous 'octopus merge'
|
|
|
|
+ [mhf~6] Retire git-parse-remote.
|
|
|
|
+ [mhf~7] Multi-head fetch.
|
|
|
|
+ [mhf~8] Start adding the $GIT_DIR/remotes/ support.
|
|
|
|
*++ [master] Add 'git show-branch'.
|
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
These three branches all forked from a common commit, [master],
|
|
|
|
whose commit message is "Add {apostrophe}git show-branch{apostrophe}".
|
|
|
|
The "fixes" branch adds one commit "Introduce "reset type" flag to
|
|
|
|
"git reset"". The "mhf" branch adds many other commits.
|
|
|
|
The current branch is "master".
|
|
|
|
|
|
|
|
|
|
|
|
EXAMPLE
|
|
|
|
-------
|
|
|
|
|
|
|
|
If you keep your primary branches immediately under
|
docs: don't talk about $GIT_DIR/refs/ everywhere
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
may also consult the packed refs mechanism. These days we tend to treat
the "refs hierarchy" as more of an abstract namespace that happens to be
represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
worst it can confuse users who then look in $GIT_DIR/refs and find that it
is missing some of the refs they expected to see.
This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
"refs/*", under the assumption that users can handle the concept of an
abstract refs namespace. There are a few things to note:
- most cases just dropped the $GIT_DIR/ portion. But for cases where
that left _just_ the word "refs", I changed it to "refs/" to help
indicate that it was a hierarchy. I didn't do the same for longer
paths (e.g., "refs/heads" remained, instead of becoming
"refs/heads/").
- in some cases, no change was made, as the text was explicitly about
unpacked refs (e.g., the discussion in git-pack-refs).
- In some cases it made sense instead to note the existence of packed
refs (e.g., in check-ref-format and rev-parse).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
15 years ago
|
|
|
`refs/heads`, and topic branches in subdirectories of
|
|
|
|
it, having the following in the configuration file may help:
|
|
|
|
|
|
|
|
------------
|
|
|
|
[showbranch]
|
|
|
|
default = --topo-order
|
|
|
|
default = heads/*
|
|
|
|
|
|
|
|
------------
|
|
|
|
|
|
|
|
With this, `git show-branch` without extra parameters would show
|
|
|
|
only the primary branches. In addition, if you happen to be on
|
|
|
|
your topic branch, it is shown as well.
|
|
|
|
|
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>
18 years ago
|
|
|
------------
|
|
|
|
$ git show-branch --reflog="10,1 hour ago" --list master
|
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>
18 years ago
|
|
|
------------
|
|
|
|
|
|
|
|
shows 10 reflog entries going back from the tip as of 1 hour ago.
|
|
|
|
Without `--list`, the output also shows how these tips are
|
|
|
|
topologically related with each other.
|
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the linkgit:git[1] suite
|