This does three things:
. It simplifies the logic to handle the case in which no
refs are given on the command line, and fixes the bug
when only "--heads" is specified. Earlier we showed
them twice.
. It avoids to add the same ref twice.
. It sorts the glob result (e.g. "git show-branch
'tags/v1.0*'") according to a more version friendly
sort order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git show-branch bugs/*" shows all branches whose name match the
specified pattern, but in the order readdir() happened to
returned. Sort them to make the output more predictable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this, you can say "git-show-branch topic/* master" to show
all the topic branches you have under .git/refs/heads/topic/ and
your master branch. Another example is "git-show-branch --list
v1.0*" to show all the v1.0 tags. You can disambiguate by
saying "heads/topic/*" to show only topic branches if you have
tags under .git/refs/tags/topic/ as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When both heads/foo and tags/foo exist, get_sha1_basic("foo")
picked up the tag without complaining, which is quite confusing.
Make sure we require unambiguous form, "heads/foo" or "tags/foo"
in such cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the change in the previous round, we are guaranteed to come up
with the list of all relevant merge bases, but sometimes we do not
fully mark unintersting ones due to a horizon effect. Add a phase to
postprocess, so that we mark all ancestor of "interesting" commit.
This also changes the default ordering of shown commits back to
chronological order, and adds --topo-order flag to show them in
topological order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the merge-base computation resistant to the pathological
case discussed on the list earlier, by doing the same logic as
git-merge-base. As a side effect, it breaks the command's primary
function to list non-merge commit sequences, which needs to be fixed
separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-show-branch acquires two new options. --sha1-name to name
commits using the unique prefix of their object names, and
--no-name to not to show names at all.
This was outlined in <7vk6gpyuyr.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs". By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.
The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
It was ignoring the generation number of the commit when naming 2nd
and later parents, showing "(linus^n)^2" for any <n> incorrectly as
"linus^2".
Signed-off-by: Junio C Hamano <junkio@cox.net>
We may end up trying to print a commit we do not actually have but we
know about its existence only because another commit we do have refers
to it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from b204feab9371040982d2c60611925e7693106c84 commit)
The --list option is what 'git branch' without parameter should
have been; it shows the one-line commit message for each branch
name. The --independent option is used to filter out commits
that can be reachable from other commits, to make detection of
fast forward condition in multi-head merge easier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier show-branch gave names only to commits reachable via first
parent ancestry chain. Change the naming code to name everybody.
The original idea was to stop at the first merge point in the
topological order, and --more=<n> to show commits until we show <n>
more extra merge points. However depending on the order of how we
discover the commits, it additionally showed parents of the <n>th
merge points, which was unnecessary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When showing only one branch a lot of default output becomes redundant,
so clean it up a bit, and document what is shown. Retire the earlier
implementation "git-show-branches-script".
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'git show-branches' command turns out to be reasonably useful,
but painfully slow. So rewrite it in C, using ideas from merge-base
while enhancing it a bit more.
- Unlike show-branches, it can take --heads (show me all my
heads), --tags (show me all my tags), or --all (both).
- It can take --more=<number> to show beyond the merge-base.
- It shows the short name for each commit in the extended SHA1
syntax.
- It can find merge-base for more than two heads.
Examples:
$ git show-branch --more=6 HEAD
is almost the same as "git log --pretty=oneline --max-count=6".
$ git show-branch --merge-base master mhf misc
finds the merge base of the three given heads.
$ git show-branch master mhf misc
shows logs from the top of these three branch heads, up to their
common ancestor commit is shown.
$ git show-branch --all --more=10
is poor-man's gitk, showing all the tags and heads, and
going back 10 commits beyond the merge base of those refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
