1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00
Commit graph

289 commits

Author SHA1 Message Date
Junio C Hamano
6296062285 Merge branch 'tr/rev-list-count'
* tr/rev-list-count:
  bash completion: Support "divergence from upstream" messages in __git_ps1
  rev-list: introduce --count option

Conflicts:
	contrib/completion/git-completion.bash
2010-06-30 11:55:38 -07:00
Junio C Hamano
a81f1a825b Merge branch 'jn/show-num-walks'
* jn/show-num-walks:
  DWIM 'git show -5' to 'git show --do-walk -5'
2010-06-27 12:07:44 -07:00
Junio C Hamano
a214afd25b Merge branch 'jc/rev-list-ancestry-path'
* jc/rev-list-ancestry-path:
  revision: Turn off history simplification in --ancestry-path mode
  revision: Fix typo in --ancestry-path error message
  Documentation/rev-list-options.txt: Explain --ancestry-path
  Documentation/rev-list-options.txt: Fix missing line in example history graph
  revision: --ancestry-path
2010-06-22 09:45:21 -07:00
Thomas Rast
f69c501832 rev-list: introduce --count option
Add a --count option that, instead of actually listing the commits,
merely counts them.

This is mostly geared towards script use, and to this end it acts
specially when used with --left-right: it outputs the left and right
counts separately.  Previously, scripts would have to run a shell loop
or small inline script over to achieve the same.  (Without
--left-right, a simple |wc -l does the job.)

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-12 09:39:06 -07:00
Johan Herland
cb7529e13b revision: Turn off history simplification in --ancestry-path mode
When using --ancestry-path together with history simplification (typically
triggered by path limiting), history simplification would get in the way of
--ancestry-path by prematurely removing the parent links between commits on
which the ancestry path calculations are made.

This patch disables this history simplification when --ancestry-path is
enabled. This is similar to what e.g. --full-history already does.

The patch also includes a simple testcase verifying that --ancestry-path
works together with path limiting.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06 10:16:37 -07:00
Johan Herland
97b03c3538 revision: Fix typo in --ancestry-path error message
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06 10:16:35 -07:00
Jonathan Nieder
5853caec96 DWIM 'git show -5' to 'git show --do-walk -5'
To show the last two commits with one command, one might try

 1) git show -s master~2..
 2) git show -s ^master~2 master
 3) git show -s master^ master
 4) git show -s -2 master

Choice (3) works because both commits are listed on the command line.
Choices (1) and (2) have worked ever since v1.6.4-rc~3 (Make 'git
show' more useful, 2009-07-13) disabled --no-walk in this case because
there is no other useful meaning for them to have.  Unfortunately, (4)
does not work: it outputs only one commit, because --no-walk stays on.

So disable --no-walk in this case so ‘git show’ and future ‘git
cherry-pick’ can behave as expected.

As a side effect, this unfortunately changes the meaning of
‘git log --oneline --decorate --no-walk -5 --all’: instead of listing
five refs, after this patch that command would list the five most
recent commits.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02 09:15:38 -07:00
Gary V. Vaughan
4b05548fc0 enums: omit trailing comma for portability
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX
5.1 fails to compile git.

enum style is inconsistent already, with some enums declared on one
line, some over 3 lines with the enum values all on the middle line,
sometimes with 1 enum value per line... and independently of that the
trailing comma is sometimes present and other times absent, often
mixing with/without trailing comma styles in a single file, and
sometimes in consecutive enum declarations.

Clearly, omitting the comma is the more portable style, and this patch
changes all enum declarations to use the portable omitted dangling
comma style consistently.

Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31 16:59:27 -07:00
Junio C Hamano
ebdc94f3be revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A.  This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).

	       x---x---A---B---C  <-- topic
	      /			\
     x---x---x---o---o---o---o---M---D---E---F---G  <-- dev
    /						  \
   x---o---o---o---o---o---o---o---o---o---o---o---N---H  <-- master

The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.

When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'.  Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".

Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21 01:15:33 -07:00
Junio C Hamano
a86ed83cce Merge branch 'tr/notes-display'
* tr/notes-display:
  git-notes(1): add a section about the meaning of history
  notes: track whether notes_trees were changed at all
  notes: add shorthand --ref to override GIT_NOTES_REF
  commit --amend: copy notes to the new commit
  rebase: support automatic notes copying
  notes: implement helpers needed for note copying during rewrite
  notes: implement 'git notes copy --stdin'
  rebase -i: invoke post-rewrite hook
  rebase: invoke post-rewrite hook
  commit --amend: invoke post-rewrite hook
  Documentation: document post-rewrite hook
  Support showing notes from more than one notes tree
  test-lib: unset GIT_NOTES_REF to stop it from influencing tests

Conflicts:
	git-am.sh
	refs.c
2010-03-24 16:26:43 -07:00
Junio C Hamano
797d44343c Merge branch 'pb/log-first-parent-p-m'
* pb/log-first-parent-p-m:
  show --first-parent/-m: do not default to --cc
  show -c: show patch text
  revision: introduce setup_revision_opt
  t4013: add tests for log -p -m --first-parent
  git log -p -m: document -m and honor --first-parent
2010-03-24 16:25:39 -07:00
Dave Olszewski
8fcaca3ff2 don't use default revision if a rev was specified
If a revision is specified, it happens not to have any commits, don't
use the default revision.  By doing so, surprising and undesired
behavior can happen, such as showing the reflog for HEAD when a branch
was specified.

[jc: squashed a test from René]

Signed-off-by: Dave Olszewski <cxreg@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13 21:23:43 -08:00
Thomas Rast
894a9d333e Support showing notes from more than one notes tree
With this patch, you can set notes.displayRef to a glob that points at
your favourite notes refs, e.g.,

[notes]
	displayRef = refs/notes/*

Then git-log and friends will show notes from all trees.

Thanks to Junio C Hamano for lots of feedback, which greatly
influenced the design of the entire series and this commit in
particular.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12 21:55:39 -08:00
Junio C Hamano
b449005997 show -c: show patch text
Traditionally, "show" defaulted to "show --cc" (dense combined patch), but
asking for combined patch with "show -c" didn't turn the patch output
format on; the placement of this logic in setup_revisions() dates back to
cd2bdc5 (Common option parsing for "git log --diff" and friends,
2006-04-14).

This unfortunately cannot be done as a trivial change of "if dense
combined is asked, default to patch format" done in setup_revisions() to
"if any combined is asked, default to patch format", as "diff-tree -c"
needs to default to raw, while "diff-tree --cc" needs to default to patch,
and they share the codepath.  These command specific defaults are now
handled in the new "tweak" callback that can be customized by individual
command implementations.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09 01:11:18 -08:00
Junio C Hamano
32962c9bd5 revision: introduce setup_revision_opt
So far the last parameter to setup_revisions() was to specify the default
ref when the command line did not give any (typically "HEAD").  This changes
it to take a pointer to a structure so that we can add other information without
touching too many codepaths in later patches.

There is no functionality change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09 01:11:18 -08:00
Junio C Hamano
1f54d693fd Merge branch 'jc/grep-author-all-match-implicit' into maint
* jc/grep-author-all-match-implicit:
  "log --author=me --grep=it" should find intersection, not union
2010-03-08 00:35:59 -08:00
Junio C Hamano
712d352577 Merge branch 'tr/maint-cherry-pick-list' into maint
* tr/maint-cherry-pick-list:
  cherry_pick_list: quit early if one side is empty
2010-03-04 22:26:44 -08:00
Junio C Hamano
80eac928ae Merge branch 'il/rev-glob' 2010-02-23 12:05:18 -08:00
Thomas Rast
36c079756f cherry_pick_list: quit early if one side is empty
The --cherry-pick logic starts by counting the commits on each side,
so that it can filter away commits on the bigger one.  However, so
far it missed an opportunity for optimization: it doesn't need to do
any work if either side is empty.

This in particular helps the common use-case 'git rebase -i HEAD~$n':
it internally uses --cherry-pick, but since HEAD~$n is a direct
ancestor the left side is always empty.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20 10:33:11 -08:00
Junio C Hamano
105e473397 Fix log -g this@{upstream}
It showed the correct objects but walked a wrong reflog.
Again, tests are from Jeff King.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26 13:49:50 -08:00
Junio C Hamano
80235ba79e "log --author=me --grep=it" should find intersection, not union
Historically, any grep filter in "git log" family of commands were taken
as restricting to commits with any of the words in the commit log message.
However, the user almost always want to find commits "done by this person
on that topic".  With "--all-match" option, a series of grep patterns can
be turned into a requirement that all of them must produce a match, but
that makes it impossible to ask for "done by me, on either this or that"
with:

	log --author=me --committer=him --grep=this --grep=that

because it will require both "this" and "that" to appear.

Change the "header" parser of grep library to treat the headers specially,
and parse it as:

	(all-match-OR (HEADER-AUTHOR me)
		      (HEADER-COMMITTER him)
		      (OR
		      	(PATTERN this)
			(PATTERN that) ) )

Even though the "log" command line parser doesn't give direct access to
the extended grep syntax to group terms with parentheses, this change will
cover the majority of the case the users would want.

This incidentally revealed that one test in t7002 was bogus.  It ran:

	log --author=Thor --grep=Thu --format='%s'

and expected (wrongly) "Thu" to match "Thursday" in the author/committer
date, but that would never match, as the timestamp in raw commit buffer
does not have the name of the day-of-the-week.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-25 19:28:13 -08:00
Junio C Hamano
78bc024ab0 Merge branch 'il/rev-glob'
* il/rev-glob:
  Documentation: improve description of --glob=pattern and friends
  rev-parse --branches/--tags/--remotes=pattern
  rev-parse --glob
2010-01-22 16:08:16 -08:00
Junio C Hamano
c6ec7efdd4 Merge branch 'jl/submodule-diff'
* jl/submodule-diff:
  Performance optimization for detection of modified submodules
  git status: Show uncommitted submodule changes too when enabled
  Teach diff that modified submodule directory is dirty
  Show submodules as modified when they contain a dirty work tree
2010-01-22 16:08:10 -08:00
Junio C Hamano
67bc740721 Merge branch 'jc/maint-limit-note-output'
* jc/maint-limit-note-output:
  Fix "log --oneline" not to show notes
  Fix "log" family not to be too agressive about showing notes
2010-01-22 16:08:01 -08:00
Junio C Hamano
7dccadf363 Fix "log --oneline" not to show notes
This option should be treated pretty much the same as --format="%h %s".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-21 14:57:41 -08:00
Junio C Hamano
66b2ed09c2 Fix "log" family not to be too agressive about showing notes
Giving "Notes" information in the default output format of "log" and
"show" is a sensible progress (the user has asked for it by having the
notes), but for some commands (e.g. "format-patch") spewing notes into the
formatted commit log message without being asked is too aggressive.

Enable notes output only for "log", "show", "whatchanged" by default and
only when the user didn't ask any specific --pretty/--format from the
command line; users can explicitly override this default with --show-notes
and --no-notes option.

Parts of tests are taken from Jeff King's fix.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 19:57:02 -08:00
Ilari Liusvaara
b09fe971de rev-parse --branches/--tags/--remotes=pattern
Since local branch, tags and remote tracking branch namespaces are
most often used, add shortcut notations for globbing those in
manner similar to --glob option.

With this, one can express the "what I have but origin doesn't?"
as:

'git log --branches --not --remotes=origin'

Original-idea-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 12:30:25 -08:00
Ilari Liusvaara
d08bae7e22 rev-parse --glob
Add --glob=<glob-pattern> option to rev-parse and everything that
accepts its options. This option matches all refs that match given
shell glob pattern (complete with some DWIM logic).

Example:

'git log --branches --not --glob=remotes/origin'

To show what you have that origin doesn't.

Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 12:29:05 -08:00
Jens Lehmann
e3d42c4773 Performance optimization for detection of modified submodules
In the worst case is_submodule_modified() got called three times for
each submodule. The information we got from scanning the whole
submodule tree the first time can be reused instead.

New parameters have been added to diff_change() and diff_addremove(),
the information is stored in a new member of struct diff_filespec. Its
value is then reused instead of calling is_submodule_modified() again.

When no explicit "-dirty" is needed in the output the call to
is_submodule_modified() is not necessary when the submodules HEAD
already disagrees with the ref of the superproject, as this alone
marks it as modified. To achieve that, get_stat_data() got an extra
argument.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-18 17:28:21 -08:00
Junio C Hamano
3cc3fb7df6 Merge branch 'jc/1.7.0-diff-whitespace-only-status'
* jc/1.7.0-diff-whitespace-only-status:
  diff.c: fix typoes in comments
  Make test case number unique
  diff: Rename QUIET internal option to QUICK
  diff: change semantics of "ignore whitespace" options

Conflicts:
	diff.h
2009-12-26 14:03:18 -08:00
Junio C Hamano
e61f25f3a6 Merge branch 'jc/log-stdin'
* jc/log-stdin:
  Add trivial tests for --stdin option to log family
  Make --stdin option to "log" family read also pathspecs
  setup_revisions(): do not call get_pathspec() too early
  Teach --stdin option to "log" family
  read_revision_from_stdin(): use strbuf

Conflicts:
	revision.c
2009-11-23 22:30:08 -08:00
Junio C Hamano
60da8b15c1 Make --stdin option to "log" family read also pathspecs
Similar to the command line arguments, after giving zero or more revs, you can
feed a line "--" and then feed pathspecs one at a time.

With this

	(
		echo ^maint
		echo --
		echo Documentation
	) | git log --stat --oneline --stdin master -- t

lists commits that touch Documentation/ or t/ between maint and master.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20 15:10:47 -08:00
Junio C Hamano
5486ef0e6d setup_revisions(): do not call get_pathspec() too early
This is necessary because we will later allow pathspecs to be fed from the
standard input, and pathspecs taken from the command line (and converted
via get_pathspec() already) in revs->prune_data too early gets in the way
when we want to append from the standard input.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20 15:10:47 -08:00
Junio C Hamano
8b3dce5650 Teach --stdin option to "log" family
Move the logic to read revs from standard input that rev-list knows about
from it to revision machinery, so that all the users of setup_revisions()
can feed the list of revs from the standard input when "--stdin" is used
on the command line.

Allow some users of the revision machinery that want different semantics
from the "--stdin" option to disable it by setting an option in the
rev_info structure.

This also cleans up the kludge made to bundle.c via cut and paste.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20 15:10:29 -08:00
Junio C Hamano
63d564b300 read_revision_from_stdin(): use strbuf
It is so 2005 (and Linus ;-) to have a fixed 1000-byte buffer that
reads from the user.  Let's use strbuf to unlimit the input length.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20 14:50:43 -08:00
Linus Torvalds
ad3f9a71a8 Add '--bisect' revision machinery argument
I personally use "git bisect visualize" all the time when I bisect, but it
turns out that that is not a very flexible model. Sometimes I want to do
bisection based on all commits (no pathname limiting), but then visualize
the current bisection tree with just a few pathnames because I _suspect_
those pathnames are involved in the problem but am not totally sure about
them.

And at other times, I want to use other revision parsing logic, none of
which is available with "git bisect visualize".

So this adds "--bisect" as a revision parsing argument, and as a result it
just works with all the normal logging tools. So now I can just do

	gitk --bisect --simplify-by-decoration filename-here

etc.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-28 16:07:43 -07:00
Jeff King
f4ea32f0b4 improve reflog date/number heuristic
When we show a reflog, we have two ways of naming the entry:
by sequence number (e.g., HEAD@{0}) or by date (e.g.,
HEAD@{10 minutes ago}). There is no explicit option to set
one or the other, but we guess based on whether or not the
user has provided us with a date format, showing them the
date version if they have done so, and the sequence number
otherwise.

This usually made sense if the use did something like "git
log -g --date=relative". However, it didn't make much sense
if the user set the date format using the log.date config
variable; in that case, all of their reflogs would end up as
dates.

This patch records the source of the date format and only
triggers the date-based view if --date= was given on the
command line.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-29 10:06:49 -07:00
Junio C Hamano
24343c6099 Merge branch 'as/maint-graph-interesting-fix'
* as/maint-graph-interesting-fix:
  Add tests for rev-list --graph with options that simplify history
  graph API: fix bug in graph_is_interesting()
2009-08-27 16:59:56 -07:00
Adam Simpkins
beb5af43a6 graph API: fix bug in graph_is_interesting()
Previously, graph_is_interesting() did not behave quite the same way as
the code in get_revision().  As a result, it would sometimes think
commits were uninteresting, even though get_revision() would return
them.  This resulted in incorrect lines in the graph output.

This change creates a get_commit_action() function, which
graph_is_interesting() and simplify_commit() both now use to determine
if a commit will be shown.  It is identical to the old simplify_commit()
behavior, except that it never calls rewrite_parents().

This problem was reported by Santi Béjar.  The following command
would exhibit the problem before, but now works correctly:

  git log --graph --simplify-by-decoration --oneline v1.6.3.3

Previously git graph did not display the output for this command
correctly between f29ac4f and 66996ec, among other places.

Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-21 12:41:25 -07:00
Lars Hjemli
33e7018c45 git-log: allow --decorate[=short|full]
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.

This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18 13:14:17 -07:00
Junio C Hamano
90b1994170 diff: Rename QUIET internal option to QUICK
The option "QUIET" primarily meant "find if we have _any_ difference as
quick as possible and report", which means we often do not even have to
look at blobs if we know the trees are different by looking at the higher
level (e.g. "diff-tree A B").  As a side effect, because there is no point
showing one change that we happened to have found first, it also enables
NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.

Rename the internal option to QUICK to reflect this better; it also makes
grepping the source tree much easier, as there are other kinds of QUIET
option everywhere.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 10:22:39 -07:00
Linus Torvalds
f222abdeec Make 'git show' more useful
For some reason, I ended up doing

	git show HEAD~5..

as an odd way of asking for a log. I realize I should just have used "git
log", but at the same time it does make perfect conceptual sense. After
all, you _could_ have done

	git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4

and saying "git show HEAD~5.." is pretty natural. It's not like "git show"
only ever showed a single commit (or other object) before either! So
conceptually, giving a commit range is a very sensible operation, even
though you'd traditionally have used "git log" for that.

However, doing that currently results in an error

	fatal: object ranges do not make sense when not walking revisions

which admittedly _also_ makes perfect sense - from an internal git
implementation standpoint in 'revision.c'.

However, I think that asking to show a range makes sense to a user, while
saying "object ranges no not make sense when not walking revisions" only
makes sense to a git developer.

So on the whole, of the two different "makes perfect sense" behaviors, I
think I originally picked the wrong one. And quite frankly, I don't really
see anybody actually _depending_ on that error case. So why not change it?

So rather than error out, just turn that non-walking error case into a
"silently turn on walking" instead.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-14 13:50:29 -07:00
Linus Torvalds
b8e8db281c git log: add '--merges' flag to match '--no-merges'
I do various statistics on git, and one of the things I look at is merges,
because they are often interesting events to count ("how many merges vs
how much 'real development'" kind of statistics). And you can do it with
some fairly straightforward scripting, ie

	git rev-list --parents HEAD |
		grep ' .* ' |
		git diff-tree --always -s --pretty=oneline --stdin |
		less -S

will do it.

But I finally got irritated with the fact that we can skip merges with
'--no-merges', but we can't do the trivial reverse operation.

So this just adds a '--merges' flag that _only_ shows merges. Now you can
do the above with just a

	git log --merges --pretty=oneline

which is a lot simpler. It also means that we automatically get a lot of
statistics for free, eg

	git shortlog -ns --merges

does exactly what you'd want it to do.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-29 12:32:51 -07:00
Linus Torvalds
ceff8e7ade Clean up and simplify rev_compare_tree()
This simplifies the logic of rev_compare_tree() by removing a special
case.

It does so by turning the special case of finding a diff to be "all new
files" into a more generic case of "all new" vs "all removed" vs "mixed
changes", so now the code is actually more powerful and more generic, and
the added symmetry actually makes it simpler too.

This makes no changes to any existing behavior, but apart from the
simplification it does make it possible to some day care about whether all
changes were just deletions if we want to. Which we may well want to for
merge handling.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 00:49:50 -07:00
Mike Ralphson
3ea3c215c0 Fix typos / spelling in comments
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22 19:02:12 -07:00
Junio C Hamano
9824a388e5 Merge branch 'lt/pack-object-memuse'
* lt/pack-object-memuse:
  show_object(): push path_name() call further down
  process_{tree,blob}: show objects without buffering

Conflicts:
	builtin-pack-objects.c
	builtin-rev-list.c
	list-objects.c
	list-objects.h
	upload-pack.c
2009-04-18 14:46:17 -07:00
Linus Torvalds
cf2ab916af show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow

 - more clarity into who "owns" the name (ie now when we free the name in
   the show_object callback, it's because we generated it ourselves by
   calling path_name())

 - not calling path_name() at all, either because we don't care about the
   name in the first place, or because we are actually happy walking the
   linked list of "struct name_path *" and the last component.

Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.

Why? We use that name for two things:
 - add_preferred_base_object(), which actually _wants_ to traverse the
   path, and now does it by looking for '/' characters!
 - for 'name_hash()', which only cares about the last 16 characters of a
   name, so again, generating the full name seems to be just unnecessary
   work.

Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.

This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 17:28:31 -07:00
Linus Torvalds
8d2dfc49b1 process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.

I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.

Now, there are possible downsides to this:

 - the "buffer using object_array" _can_ in theory result in at least
   better I-cache usage (two tight loops rather than one more spread out
   one). I don't think this is a real issue, but in theory..

 - this _does_ change the order of the objects printed. Instead of doing a
   "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
   over the commits (which puts all the root trees _first_ in the object
   list, this patch just adds them to the list of pending objects, and
   then we'll traverse them in that order (and thus show each root tree
   object together with the objects we discover under it)

   I _think_ the new ordering actually makes more sense, but the object
   ordering is actually a subtle thing when it comes to packing
   efficiency, so any change in order is going to have implications for
   packing. Good or bad, I dunno.

 - There may be some reason why we did it that odd way with the object
   array, that I have simply forgotten.

Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.

This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...

Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.

Or maybe there _used_ to be a reason, and no longer is.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 17:28:31 -07:00
Junio C Hamano
3c91bf6805 Merge branch 'jc/maint-1.6.0-keep-pack'
* jc/maint-1.6.0-keep-pack:
  pack-objects: don't loosen objects available in alternate or kept packs
  t7700: demonstrate repack flaw which may loosen objects unnecessarily
  Remove --kept-pack-only option and associated infrastructure
  pack-objects: only repack or loosen objects residing in "local" packs
  git-repack.sh: don't use --kept-pack-only option to pack-objects
  t7700-repack: add two new tests demonstrating repacking flaws

Conflicts:
	t/t7700-repack.sh
2009-04-01 22:34:19 -07:00
Brandon Casey
4d6acb7041 Remove --kept-pack-only option and associated infrastructure
This option to pack-objects/rev-list was created to improve the -A and -a
options of repack.  It was found to be lacking in that it did not provide
the ability to differentiate between local and non-local kept packs, and
found to be unnecessary since objects residing in local kept packs can be
filtered out by the --honor-pack-keep option.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20 13:32:33 -07:00