2005-08-23 06:16:46 +00:00
|
|
|
git-show-branch(1)
|
|
|
|
==================
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2006-03-09 16:24:50 +00:00
|
|
|
git-show-branch - Show branches and their commits
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2006-01-11 08:16:42 +00:00
|
|
|
[verse]
|
2022-10-13 15:39:06 +00:00
|
|
|
'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>
2010-02-17 04:55:58 +00:00
|
|
|
[--current] [--color[=<when>] | --no-color] [--sparse]
|
2006-03-06 00:00:48 +00:00
|
|
|
[--more=<n> | --list | --independent | --merge-base]
|
2009-06-01 06:34:46 +00:00
|
|
|
[--no-name | --sha1-name] [--topics]
|
2010-10-08 17:31:17 +00:00
|
|
|
[(<rev> | <glob>)...]
|
2022-10-13 15:39:06 +00:00
|
|
|
'git show-branch' (-g | --reflog)[=<n>[,<base>]] [--list] [<ref>]
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2005-12-04 23:58:50 +00:00
|
|
|
|
|
|
|
Shows the commit ancestry graph starting from the commits named
|
2018-10-17 05:37:41 +00:00
|
|
|
with <rev>s or <glob>s (or all refs under refs/heads
|
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>
2010-02-18 01:16:20 +00:00
|
|
|
and/or refs/tags) semi-visually.
|
2005-12-04 23:58:50 +00:00
|
|
|
|
|
|
|
It cannot show more than 29 branches and commits at a time.
|
|
|
|
|
2006-01-11 08:09:16 +00:00
|
|
|
It uses `showbranch.default` multi-valued configuration items if
|
2014-03-31 22:11:44 +00:00
|
|
|
no <rev> or <glob> is given on the command line.
|
2006-01-11 08:09:16 +00:00
|
|
|
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
2005-12-04 23:58:50 +00:00
|
|
|
<rev>::
|
2013-04-15 17:49:04 +00:00
|
|
|
Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])
|
2008-12-19 12:14:18 +00:00
|
|
|
that typically names a branch head or a tag.
|
2005-12-04 23:58:50 +00:00
|
|
|
|
|
|
|
<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>
2010-02-18 01:16:20 +00:00
|
|
|
refs/. For example, if you have many topic
|
|
|
|
branches under refs/heads/topic, giving
|
2005-12-04 23:58:50 +00:00
|
|
|
`topic/*` would show all of them.
|
2005-08-23 06:16:46 +00:00
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-r::
|
|
|
|
--remotes::
|
2006-12-22 13:58:39 +00:00
|
|
|
Show the remote-tracking branches.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-a::
|
|
|
|
--all::
|
2006-12-22 13:58:39 +00:00
|
|
|
Show both remote-tracking branches and local branches.
|
2005-08-23 06:16:46 +00:00
|
|
|
|
2006-01-11 08:16:42 +00:00
|
|
|
--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.
|
|
|
|
|
2005-12-08 23:28:05 +00:00
|
|
|
--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).
|
|
|
|
|
2009-06-01 06:34:46 +00:00
|
|
|
--date-order::
|
2016-06-28 11:40:11 +00:00
|
|
|
This option is similar to `--topo-order` in the sense that no
|
2009-06-01 06:34:46 +00:00
|
|
|
parent comes before all of its children, but otherwise commits
|
|
|
|
are ordered according to their commit date.
|
|
|
|
|
2006-07-07 02:21:47 +00:00
|
|
|
--sparse::
|
|
|
|
By default, the output omits merges that are reachable
|
|
|
|
from only one tip being shown. This option makes them
|
|
|
|
visible.
|
|
|
|
|
2005-08-23 06:16:46 +00:00
|
|
|
--more=<n>::
|
|
|
|
Usually the command stops output upon showing the commit
|
|
|
|
that is the common ancestor of all the branches. This
|
2005-08-30 00:21:06 +00:00
|
|
|
flag tells the command to go <n> more common commits
|
2005-09-09 22:40:45 +00:00
|
|
|
beyond that. When <n> is negative, display only the
|
show-branch doc: say <ref>, not <reference>
The glossary defines 'ref' as the official name of the thing,
and the output from "git grep -e '<ref' Documentation/" shows
that most everybody uses <ref>, not <reference>. In addition,
the page already says <ref> in its SYNOPSIS section for the
command when it is used in the mode to follow the reflogs.
Strictly speaking, many references of these should be updated to
<commit> after adding an explanation on how these <commit>s are
discovered (i.e. we take <rev>, <glob>, or <ref> and starting from
these commits, follow their ancestry or reflog entries to list
commits), but that would be a lot bigger change I would rather not
to do in this patch, whose primary purpose is to make the existing
documentation more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sean Allred <allred.sean@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-19 04:17:50 +00:00
|
|
|
<ref>s given, without showing the commit ancestry tree.
|
2005-09-09 22:40:45 +00:00
|
|
|
|
|
|
|
--list::
|
2006-01-11 08:09:16 +00:00
|
|
|
Synonym to `--more=-1`
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
--merge-base::
|
2009-08-05 07:59:20 +00:00
|
|
|
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.
|
2005-08-23 06:16:46 +00:00
|
|
|
|
2005-09-09 22:40:45 +00:00
|
|
|
--independent::
|
show-branch doc: say <ref>, not <reference>
The glossary defines 'ref' as the official name of the thing,
and the output from "git grep -e '<ref' Documentation/" shows
that most everybody uses <ref>, not <reference>. In addition,
the page already says <ref> in its SYNOPSIS section for the
command when it is used in the mode to follow the reflogs.
Strictly speaking, many references of these should be updated to
<commit> after adding an explanation on how these <commit>s are
discovered (i.e. we take <rev>, <glob>, or <ref> and starting from
these commits, follow their ancestry or reflog entries to list
commits), but that would be a lot bigger change I would rather not
to do in this patch, whose primary purpose is to make the existing
documentation more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sean Allred <allred.sean@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-19 04:17:50 +00:00
|
|
|
Among the <ref>s given, display only the ones that cannot be
|
|
|
|
reached from any other <ref>.
|
2005-09-09 22:40:45 +00:00
|
|
|
|
2005-10-11 22:22:48 +00:00
|
|
|
--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.
|
|
|
|
|
2006-12-18 15:48:33 +00:00
|
|
|
--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"
|
|
|
|
|
2009-01-06 03:14:02 +00:00
|
|
|
-g::
|
2007-02-04 07:31:47 +00:00
|
|
|
--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>
2007-01-19 09:20:23 +00:00
|
|
|
Shows <n> most recent ref-log entries for the given
|
|
|
|
ref. If <base> is given, <n> entries going back from
|
2007-01-24 14:05:16 +00:00
|
|
|
that entry. <base> can be specified as count or date.
|
2009-01-06 03:14:02 +00:00
|
|
|
When no explicit <ref> parameter is given, it defaults to the
|
2007-02-04 07:31:47 +00:00
|
|
|
current branch (or `HEAD` if it is detached).
|
2006-12-26 08:11:50 +00:00
|
|
|
|
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 04:55:58 +00:00
|
|
|
--color[=<when>]::
|
2009-04-22 21:41:25 +00:00
|
|
|
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>
2010-02-17 04:55:58 +00:00
|
|
|
The value must be always (the default), never, or auto.
|
2009-04-22 21:41:25 +00:00
|
|
|
|
|
|
|
--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>
2010-02-17 04:55:58 +00:00
|
|
|
Same as `--color=never`.
|
2009-04-22 21:41:25 +00:00
|
|
|
|
2005-09-09 22:40:45 +00:00
|
|
|
Note that --more, --list, --independent and --merge-base options
|
|
|
|
are mutually exclusive.
|
|
|
|
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
OUTPUT
|
|
|
|
------
|
show-branch doc: say <ref>, not <reference>
The glossary defines 'ref' as the official name of the thing,
and the output from "git grep -e '<ref' Documentation/" shows
that most everybody uses <ref>, not <reference>. In addition,
the page already says <ref> in its SYNOPSIS section for the
command when it is used in the mode to follow the reflogs.
Strictly speaking, many references of these should be updated to
<commit> after adding an explanation on how these <commit>s are
discovered (i.e. we take <rev>, <glob>, or <ref> and starting from
these commits, follow their ancestry or reflog entries to list
commits), but that would be a lot bigger change I would rather not
to do in this patch, whose primary purpose is to make the existing
documentation more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sean Allred <allred.sean@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-19 04:17:50 +00:00
|
|
|
|
|
|
|
Given N <ref>s, 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.
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
Following these N lines, one-line log for each commit is
|
|
|
|
displayed, indented N places. If a commit is on the I-th
|
2006-01-11 22:02:38 +00:00
|
|
|
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
|
2013-04-15 17:49:04 +00:00
|
|
|
can be used as an extended SHA-1 to name that commit.
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
The following example shows three branches, "master", "fixes"
|
|
|
|
and "mhf":
|
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
$ git show-branch master fixes mhf
|
2006-01-11 22:02:38 +00:00
|
|
|
* [master] Add 'git show-branch'.
|
2005-08-23 06:16:46 +00:00
|
|
|
! [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.
|
2006-01-11 22:02:38 +00:00
|
|
|
*++ [master] Add 'git show-branch'.
|
2005-08-23 06:16:46 +00:00
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
These three branches all forked from a common commit, [master],
|
2019-04-10 00:37:33 +00:00
|
|
|
whose commit message is "Add \'git show-branch'".
|
2010-08-20 10:37:06 +00:00
|
|
|
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".
|
2005-08-23 06:16:46 +00:00
|
|
|
|
|
|
|
|
2018-04-30 15:35:33 +00:00
|
|
|
EXAMPLES
|
|
|
|
--------
|
2006-01-11 08:09:16 +00:00
|
|
|
|
|
|
|
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>
2010-02-18 01:16:20 +00:00
|
|
|
`refs/heads`, and topic branches in subdirectories of
|
2006-01-11 08:09:16 +00:00
|
|
|
it, having the following in the configuration file may help:
|
|
|
|
|
|
|
|
------------
|
|
|
|
[showbranch]
|
|
|
|
default = --topo-order
|
|
|
|
default = heads/*
|
|
|
|
|
|
|
|
------------
|
|
|
|
|
2006-03-18 00:25:46 +00:00
|
|
|
With this, `git show-branch` without extra parameters would show
|
2006-01-11 08:16:42 +00:00
|
|
|
only the primary branches. In addition, if you happen to be on
|
|
|
|
your topic branch, it is shown as well.
|
2006-01-11 08:09:16 +00: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 09:20:23 +00:00
|
|
|
------------
|
2008-12-21 10:00:31 +00:00
|
|
|
$ 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>
2007-01-19 09:20:23 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
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.
|
2006-01-11 08:09:16 +00:00
|
|
|
|
2022-09-07 08:27:04 +00:00
|
|
|
CONFIGURATION
|
|
|
|
-------------
|
|
|
|
|
|
|
|
include::includes/cmd-config-section-all.txt[]
|
|
|
|
|
|
|
|
include::config/showbranch.txt[]
|
|
|
|
|
2005-08-23 06:16:46 +00:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|