Every single user actually wanted this only for commit objects, and we
have no reason to waste space on it for other object types. So just move
the structure member from the low-level "struct object" into the "struct
commit".
This leaves the commit object the same size, and removes one unnecessary
pointer from all other object allocations.
This shrinks memory usage (still at a fairly hefty half-gig, admittedly)
of "git-rev-list --all --objects" on the mozilla repo by another 5% in my
tests.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This patch touches a couple of files, because it adds options to print a
custom text just after the subject of a commit, and just after the
diffstat.
[jc: made "many dashes" used as the boundary leader into a single
variable, to reduce the possibility of later tweaks to miscount the
number of dashes to break it.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting contents of topic branches for yet-to-be-merged
commits, a commit that is in the release/master branch is
uninteresting. Previous round still showed them, especially,
the ones before a topic branch that was forked from the
release/master later than other topic branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a new flag, --topics, to help managing topic
branches. When you have topic branches forked some time ago
from your primary line of development, show-branch would show
many "uninteresting" things that happend on the primary line of
development when trying to see what are still not merged from
the topic branches.
With this flag, the first ref given to show-branch is taken as
the primary branch, and the rest are taken as the topic
branches. Output from the command is modified so that commits
only on the primary branch are not shown. In other words,
$ git show-branch --topics master topic1 topic2 ...
shows an (almost) equivalent of
$ git rev-list ^master topic1 topic2 ...
The major differences are that (1) you can tell which commits
are on which branch, and (2) the commit at the fork point is
shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --date-order to rev-list; it is similar to topo order
in the sense that no parent comes before all of its children,
but otherwise things are still ordered in the commit timestamp
order.
The same flag is also added to show-branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you call setup_git_directory() to work from a subdirectory,
that should be run first before running git_config(). Otherwise
you would not read the configuration file from the correct place.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this, the command includes the current branch to the list
of revs to be shown when it is not given on the command line.
This is handy to use in the configuration file like this:
[showbranch]
default = --current
default = heads/* ; primary branches, not topics under
; subdirectories
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the character used to mark the commits that is on the
branch from '+' to '*' for the current branch, to make it stand out.
Also we show '-' for merge commits.
When you have a handful branches with relatively long diversion, it
is easier to see which one is the current branch this way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier only '?' and '*' signalled the command that what the
user has given is a glob pattern. This prevented us to say:
$ git show-branch 'v0.99.[0-3]'
Now we notice '[' as well, so the above would work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets showbranch.default multivalued configuration item to
be used as the default set of parameters to git-show-branch when
none is given on the command line.
I keep many topic branches (e.g. zzz/pack, net/misc) and
branches used only as a reference under subdirectories
(e.g. hold/{html,man,todo} track the same from git.git, but
clutters the show-branch output when shown along with the main
development; ko/master tracks what I have pushed out already and
refetched from the kernel.org server), and often run:
$ git show-branch ko/master heads/*
to view only the ko/master head and branches I keep immediately
under $GIT_DIR/refs/heads. With this change, I can have this in
my $GIT_DIR/config file:
[showbranch]
default = ko/master
default = heads/*
and say
$ git show-branch
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Junio C Hamano