Change git_get_project_config to run git-config only once per
repository, without changing its signature (its calling convention).
This means for example that it returns 'true' or 'false' when called
with second argument '--bool', and not true or false value.
Instead of calling 'git config [<type>] --get gitweb.<key>' once for
each config variable, call 'git config -z -l' only once, parsing and
saving its output to %config variable. This makes possible to add new
per repository configuration without paying cost of forking once per
variable checked. We can now allow repository description and
repository URLs to be stored in config file without badly affecting
gitweb performance.
For now only configuration variables for 'gitweb' section are stored.
Multiple values for single configuration variable are stored as
anonymous array reference; configuration variable with no value is
stored as undef.
Converting configuration variable values to boolean or integer value
are done in Perl. Results differ from git-config in the fact that no
conversion error is ever raised. For boolean values no value, 'true'
(any case) and 'false' (any case) are considered true, numbers are
true if not zero; all other values (even invalid for bool) are
considered false. For integer values value suffix of 'k', 'm', or 'g'
following decimal number will cause the value to be multiplied by
1024, 1048576, or 1073741824; other values are returned as-is, only
whitespace stripped.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Fixing path quoting in git-rebase
Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.
Documentation: quote commit messages consistently.
Remove escaping of '|' in manpage option sections
* ph/parseopt: (24 commits)
gc: use parse_options
Fixed a command line option type for builtin-fsck.c
Make builtin-pack-refs.c use parse_options.
Make builtin-name-rev.c use parse_options.
Make builtin-count-objects.c use parse_options.
Make builtin-fsck.c use parse_options.
Update manpages to reflect new short and long option aliases
Make builtin-for-each-ref.c use parse-opts.
Make builtin-symbolic-ref.c use parse_options.
Make builtin-update-ref.c use parse_options
Make builtin-revert.c use parse_options.
Make builtin-describe.c use parse_options
Make builtin-branch.c use parse_options.
Make builtin-mv.c use parse-options
Make builtin-rm.c use parse_options.
Port builtin-add.c to use the new option parser.
parse-options: allow callbacks to take no arguments at all.
parse-options: Allow abbreviated options when unambiguous
Add shortcuts for very often used options.
parse-options: make some arguments optional, add callbacks.
...
* np/progress:
Show total transferred as part of throughput progress
make sure throughput display gets updated even if progress doesn't move
return the prune-packed progress display to the inner loop
add throughput display to git-push
add some copyright notice to the progress display code
add throughput display to index-pack
add throughput to progress display
relax usage of the progress API
make struct progress an opaque type
prune-packed: don't call display_progress() for every file
Stop displaying "Pack pack-$ID created." during git-gc
Teach prune-packed to use the standard progress meter
Change 'Deltifying objects' to 'Compressing objects'
fix for more minor memory leaks
fix const issues with some functions
pack-objects.c: fix some global variable abuse and memory leaks
pack-objects: no delta possible with only one object in the list
cope with multiple line breaks within sideband progress messages
more compact progress display
git-p4: Detect changes to executable bit and include them in p4 submit.
This changeset takes advantage of the new parseDiffTreeEntry(...) function to
detect changes to the execute bit in the git repository. During submit, git-p4
now looks for changes to the executable bit and if it finds them it "reopens"
the file in perforce, which allows it to change the file type.
The logic for adding the executable bit in perforce is straightforward: the +x
modifier can be used. Removing the executable bit in perforce requires that the
entire filetype be redefined (there is no way to join remove the bit with a -x
modifier, for example). This changeset includes logic to remove the executable
bit from the full file type while preserving the base file type and other
modifiers.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is a good idea to use pack index version 2 all the time since it has
proper protection against propagation of certain pack corruptions when
repacking which is not possible with index version 1, as demonstrated
in test t5302.
Hence this config option.
The default is still pack index version 1.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Use href(-replay=>1, action=>...) to generate alternate views
Use href(action=>..., -replay=>1) to generate links to alternate views
of current page in the $formats_nav (bottom) part of page_nav
navigation bar. This form is used only when all parameters are
repeated, and when the replay form is shorter.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Easier adding/changing parameters to current URL
Add boolean option '-replay' to href() subroutine, which is used to
generate links in gitweb. This option "replays" current URL,
overriding it with provided parameters. It means that current value
of each CGI parameter is used unless otherwise provided.
This change is meant to make it easier to generate links which differ
from current page URL only by one parameter, for example the same view
but sorted by different column:
href(-replay=>1, order=>"age")
or view which differs by some option, e.g. in log views
href(-replay=>1, extra_options=>"--no-merges")
or alternate view of the same object, e.g. in the 'blob' view
href(-replay=>1, action=>"blob_plain")
Actual use of this functionality is left for later.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Add 'status_str' to parse_difftree_raw_line output
Add 'status_str' to diffinfo output, which stores status (also for
merge commit) as a string. This allows for easy checking if there is
given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /D/;
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
Always set 'from_file' and 'to_file' keys when parsing raw diff output
format line, even if filename didn't change (file was not renamed).
This allows for simpler code.
format-patch -s: add MIME encoding header if signer's name requires so
When the body of the commit log message contains a non-ASCII character,
format-patch correctly emitted the encoding header to mark the resulting
message as such. However, if the original message was fully ASCII, the
command line switch "-s" was given to add a new sign-off, and
the signer's name was not ASCII only, the resulting message would have
contained non-ASCII character but was not marked as such.
* maint:
git-format-patch.txt: fix explanation of an example.
git-filter-branch.txt: fix a typo.
git-clone.txt: Improve --depth description.
gitweb: Update config file example for snapshot feature in gitweb/INSTALL
git-diff.txt: add section "output format" describing the diff formats
git-diff.txt includes diff-options.txt which for the -p option refers
to a section "generating patches.." which is missing from the git-diff
documentation. This patch adapts diff-format.txt to additionally
mention the git-diff program, and includes diff-format.txt into
git-diff.txt.
Tino Keitel noticed this problem.
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Show total transferred as part of throughput progress
Right now it is infeasible to offer to the user a reasonable concept
of when a clone will be complete as we aren't able to come up with
the final pack size until after we have actually transferred the
entire thing to the client. However in many cases users can work
with a rough rule-of-thumb; for example it is somewhat well known
that git.git is about 16 MiB today and that linux-2.6.git is over
120 MiB.
We now show the total amount of data we have transferred over
the network as part of the throughput meter, organizing it in
"human friendly" terms like `ls -h` would do. Users can glance at
this, see that the total transferred size is about 3 MiB, see the
throughput of X KiB/sec, and determine a reasonable figure of about
when the clone will be complete, assuming they know the rough size
of the source repository or are able to obtain it.
This is also a helpful indicator that there is progress being made
even if we stall on a very large object. The thoughput meter may
remain relatively constant and the percentage complete and object
count won't be changing, but the total transferred will be increasing
as additional data is received for this object.
[from an initial proposal from Shawn O. Pearce]
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
make sure throughput display gets updated even if progress doesn't move
Currently the progress/throughput display update happens only through
display_progress(). If the progress based on object count remains
unchanged because a large object is being received, the latest throughput
won't be displayed. The display update should occur through
display_throughput() as well.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Wed, 31 Oct 2007, Shawn O. Pearce wrote:
> During my testing with a 40,000 loose object case (yea, I fully
> unpacked a git.git clone I had laying around) my system stalled
> hard in the first object directory. A *lot* longer than 1 second.
> So I got no progress meter for a long time, and then a progress
> meter appeared on the second directory.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sergei Organov <osv@javad.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Update config file example for snapshot feature in gitweb/INSTALL
Commit a3c8ab30a54c30a6a434760bedf04548425416ef by Matt McCutchen
"gitweb: snapshot cleanups & support for offering multiple formats"
introduced new format of $feature{'snapshot'}{'default'} value. Update
"Config file example" in gitweb/INSTALL accordingly.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/forkexec:
Use the asyncronous function infrastructure to run the content filter.
Avoid a dup2(2) in apply_filter() - start_command() can do it for us.
t0021-conversion.sh: Test that the clean filter really cleans content.
upload-pack: Run rev-list in an asynchronous function.
upload-pack: Move the revision walker into a separate function.
Use the asyncronous function infrastructure in builtin-fetch-pack.c.
Add infrastructure to run a function asynchronously.
upload-pack: Use start_command() to run pack-objects in create_pack_file().
Have start_command() create a pipe to read the stderr of the child.
Use start_comand() in builtin-fetch-pack.c instead of explicit fork/exec.
Use run_command() to spawn external diff programs instead of fork/exec.
Use start_command() to run content filters instead of explicit fork/exec.
Use start_command() in git_connect() instead of explicit fork/exec.
Change git_connect() to return a struct child_process instead of a pid_t.
* sp/mergetool:
mergetool: avoid misleading message "Resetting to default..."
mergetool: add support for ECMerge
mergetool: use path to mergetool in config var mergetool.<tool>.path
* sp/help:
shell should call the new setup_path() to setup $PATH
include $PATH in generating list of commands for "help -a"
use only the $PATH for exec'ing git commands
list_commands(): simplify code by using chdir()
"current_exec_path" is a misleading name, use "argv_exec_path"
remove unused/unneeded "pattern" argument of list_commands
"git" returns 1; "git help" and "git help -a" return 0
* kh/commit:
Export rerere() and launch_editor().
Introduce entry point add_interactive and add_files_to_cache
Enable wt-status to run against non-standard index file.
Enable wt-status output to a given FILE pointer.
cvsexportcommit: fix for commits that do not have parents
Previously commits without parents would fail to export with a
message indicating that the commits had more than one parent.
Instead we should use the --root option for git-diff-tree in
place of a parent.
Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update GIT 1.5.3.5 Release Notes
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
Fix --strategy parsing in git-rebase--interactive.sh
Make merge-recursive honor diff.renamelimit
cherry-pick/revert: more compact user direction message
core-tutorial: Use new syntax for git-merge.
git-merge: document but discourage the historical syntax
Prevent send-pack from segfaulting (backport from 'master')
Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
* cc/skip:
Bisect: add "skip" to the short usage string.
Bisect run: "skip" current commit if script exit code is 125.
Bisect: add a "bisect replay" test case.
Bisect: add "bisect skip" to the documentation.
Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
Bisect: refactor some logging into "bisect_write".
Bisect: refactor "bisect_write_*" functions.
Bisect: implement "bisect skip" to mark untestable revisions.
Bisect: fix some white spaces and empty lines breakages.
rev-list documentation: add "--bisect-all".
rev-list: implement --bisect-all
* lt/rename:
Do the fuzzy rename detection limits with the exact renames removed
Fix ugly magic special case in exact rename detection
Do exact rename detection regardless of rename limits
Do linear-time/space rename logic for exact renames
copy vs rename detection: avoid unnecessary O(n*m) loops
Ref-count the filespecs used by diffcore
Split out "exact content match" phase of rename detection
Add 'diffcore.h' to LIB_H
* ds/gitweb:
gitweb: Use chop_and_escape_str in more places.
gitweb: Refactor abbreviation-with-title-attribute code.
gitweb: Provide title attributes for abbreviated author names.
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
git-rebase--interactive.sh used to pass all parents of a merge commit to
git-merge, which means that we have at least 3 heads to merge: HEAD,
first parent and second parent. So 3-way merge strategies like recursive
wouldn't work.
Fortunately, we have checked out the first parent right before the merge
anyway, so that is HEAD. Therefore we can drop simply it from the list
of parents, making 3-way strategies work for merge commits with only
two parents.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
git-cherry-pick doesn't support a strategy paramter, so don't pass one.
This means that --strategy for interactive rebases is a no-op for
anything but merge commits, but that's still better than being broken. A
correct fix would probably need to port the --merge behaviour from plain
git-rebase.sh, but I have no clue how to integrate that cleanly.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix --strategy parsing in git-rebase--interactive.sh
For the --strategy/-s option, git-rebase--interactive.sh dropped the
parameter which it was trying to parse.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It might be a sign of source code management gone bad, but when two branches
has diverged almost beyond recognition and time has come for the branches to
merge, the user is going to need all the help his tool can give him. Honoring
diff.renamelimit has great potential as a painkiller in such situations.
The painkiller effect could have been achieved by e.g. 'merge.renamelimit',
but the flexibility gained by a separate option is questionable: our user
would probably expect git to detect renames equally good when merging as
when diffing (I known I did).
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge: document but discourage the historical syntax
Historically "git merge" took its command line arguments in a
rather strange order. Document the historical syntax, and also
document clearly that it is not encouraged in new scripts.
There is no reason to deprecate the historical syntax, as the
current code can sanely tell which syntax the caller is using,
and existing scripts by people do use the historical syntax.
If we can't find a source match, and we have no destination, we
need to abort the match function early before we try to match
the destination against the remote.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since it is now OK to pass a null pointer to display_progress() and
stop_progress() resulting in a no-op, then we can simplify the code
and remove a bunch of lines by not making those calls conditional all
the time.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows for better management of progress "object" existence,
as well as making the progress display implementation more independent
from its callers.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are some cases when one line from "raw" git-diff output (raw
format) corresponds to more than one patch in the patchset git-diff
output; we call this situation "split patch". Old code misdetected
subsequent patches (for different files) with the same pre-image and
post-image as fragments of "split patch", leading to mislabeled
from-file/to-file diff header etc.
Old code used pre-image and post-image SHA-1 identifier ('from_id' and
'to_id') to check if current patch corresponds to old raw diff format
line, to find if one difftree raw line coresponds to more than one
patch in the patch format. Now we use post-image filename for that.
This assumes that post-image filename alone can be used to identify
difftree raw line. In the case this changes (which is unlikely
considering current diff engine) we can add 'from_id' and 'to_id'
to detect "patch splitting" together with 'to_file'.
Because old code got pre-image and post-image SHA-1 identifier for the
patch from the "index" line in extended diff header, diff header had
to be buffered. New code takes post-image filename from "git diff"
header, which is first line of a patch; this allows to simplify
git_patchset_body code. A side effect of resigning diff header
buffering is that there is always "diff extended_header" div, even
if extended diff header is empty.
Alternate solution would be to check when git splits patches, and do
not check if parsed info from current patch corresponds to current or
next raw diff format output line. Git splits patches only for 'T'
(typechange) status filepair, and there always two patches
corresponding to one raw diff line. It was not used because it would
tie gitweb code to minute details of git diff output.
While at it, use newly introduced parsed_difftree_line wrapper
subroutine in git_difftree_body.
Noticed-by: Yann Dirson <ydirson@altern.org> Diagnosed-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
parse-options: Allow abbreviated options when unambiguous
When there is an option "--amend", the option parser now recognizes
"--am" for that option, provided that there is no other option beginning
with "--am".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
parse-options: make some arguments optional, add callbacks.
* add the possibility to use callbacks to parse some options, this can
help implementing new options kinds with great flexibility. struct option
gains a callback pointer and a `defval' where callbacks user can put
either integers or pointers. callbacks also can use the `value' pointer
for anything, preferably to the pointer to the final storage for the value
though.
* add a `flag' member to struct option to make explicit that this option may
have an optional argument. The semantics depends on the option type. For
INTEGERS, it means that if the switch is not used in its
--long-form=<value> form, and that there is no token after it or that the
token does not starts with a digit, then it's assumed that the switch has
no argument. For STRING or CALLBACK it works the same, except that the
condition is that the next atom starts with a dash. This is needed to
implement backward compatible behaviour with existing ways to parse the
command line. Its use for new options is discouraged.
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The option parser takes argc, argv, an array of struct option
and a usage string. Each of the struct option elements in the array
describes a valid option, its type and a pointer to the location where the
value is written. The entry point is parse_options(), which scans through
the given argv, and matches each option there against the list of valid
options. During the scan, argv is rewritten to only contain the
non-option command line arguments and the number of these is returned.
Aggregation of single switches is allowed:
-rC0 is the same as -r -C 0 (supposing that -C wants an arg).
Every long option automatically support the option with the same name,
prefixed with 'no-' to unset the switch. It assumes that initial value for
strings are "NULL" and for integers is "0".
Long options are supported either with '=' or without:
--some-option=foo is the same as --some-option foo
Acked-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
include $PATH in generating list of commands for "help -a"
Git had previously been using the $PATH for scripts--a previous
patch moved exec'ed commands to also use the $PATH. For consistency
"help -a" should also list commands in the $PATH.
The main commands are still listed from the git_exec_path(), but
the $PATH is walked and other git commands (probably extensions) are
listed.
Signed-off-by: Scott R Parish <srp@srparish.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We need to correctly set up $PATH for non-c based git commands.
Since we already do this, we can just use that $PATH and execvp,
instead of looping over the paths with execve.
This patch adds a setup_path() function to exec_cmd.c, which sets
the $PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's
main() only only needs to call setup_path().
Signed-off-by: Scott R Parish <srp@srparish.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>