* [ANNOUNCE] Git 1.7.8
From: Junio C Hamano @ 2011-12-02 20:25 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git 1.7.8 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
7453e737e008f7319a5eca24a9ef3c5fb1f13398 git-1.7.8.tar.gz
2734079e22a0a6e3e78779582be9138ffc7de6f7 git-htmldocs-1.7.8.tar.gz
93315f7f51d7f27d3e421c9b0d64afa27f3d16df git-manpages-1.7.8.tar.gz
Also the following public repositories all have a copy of the v1.7.8
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.8 Release Notes
========================
Updates since v1.7.7
--------------------
* Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates.
* Updates to bash completion scripts.
* The build procedure has been taught to take advantage of computed
dependency automatically when the complier supports it.
* The date parser now accepts timezone designators that lack minutes
part and also has a colon between "hh:mm".
* The contents of the /etc/mailname file, if exists, is used as the
default value of the hostname part of the committer/author e-mail.
* "git am" learned how to read from patches generated by Hg.
* "git archive" talking with a remote repository can report errors
from the remote side in a more informative way.
* "git branch" learned an explicit --list option to ask for branches
listed, optionally with a glob matching pattern to limit its output.
* "git check-attr" learned "--cached" option to look at .gitattributes
files from the index, not from the working tree.
* Variants of "git cherry-pick" and "git revert" that take multiple
commits learned to "--continue" and "--abort".
* "git daemon" gives more human readble error messages to clients
using ERR packets when appropriate.
* Errors at the network layer is logged by "git daemon".
* "git diff" learned "--minimal" option to spend extra cycles to come
up with a minimal patch output.
* "git diff" learned "--function-context" option to show the whole
function as context that was affected by a change.
* "git difftool" can be told to skip launching the tool for a path by
answering 'n' to its prompt.
* "git fetch" learned to honor transfer.fsckobjects configuration to
validate the objects that were received from the other end, just like
"git receive-pack" (the receiving end of "git push") does.
* "git fetch" makes sure that the set of objects it received from the
other end actually completes the history before updating the refs.
"git receive-pack" (the receiving end of "git push") learned to do the
same.
* "git fetch" learned that fetching/cloning from a regular file on the
filesystem is not necessarily a request to unpack a bundle file; the
file could be ".git" with "gitdir: <path>" in it.
* "git for-each-ref" learned "%(contents:subject)", "%(contents:body)"
and "%(contents:signature)". The last one is useful for signed tags.
* "git grep" used to incorrectly pay attention to .gitignore files
scattered in the directory it was working in even when "--no-index"
option was used. It no longer does this. The "--exclude-standard"
option needs to be given to explicitly activate the ignore
mechanism.
* "git grep" learned "--untracked" option, where given patterns are
searched in untracked (but not ignored) files as well as tracked
files in the working tree, so that matches in new but not yet
added files do not get missed.
* The recursive merge backend no longer looks for meaningless
existing merges in submodules unless in the outermost merge.
* "git log" and friends learned "--children" option.
* "git ls-remote" learned to respond to "-h"(elp) requests.
* "mediawiki" remote helper can interact with (surprise!) MediaWiki
with "git fetch" & "git push".
* "git merge" learned the "--edit" option to allow users to edit the
merge commit log message.
* "git rebase -i" can be told to use special purpose editor suitable
only for its insn sheet via sequence.editor configuration variable.
* "git send-email" learned to respond to "-h"(elp) requests.
* "git send-email" allows the value given to sendemail.aliasfile to begin
with "~/" to refer to the $HOME directory.
* "git send-email" forces use of Authen::SASL::Perl to work around
issues between Authen::SASL::Cyrus and AUTH PLAIN/LOGIN.
* "git stash" learned "--include-untracked" option to stash away
untracked/ignored cruft from the working tree.
* "git submodule clone" does not leak an error message to the UI
level unnecessarily anymore.
* "git submodule update" learned to honor "none" as the value for
submodule.<name>.update to specify that the named submodule should
not be checked out by default.
* When populating a new submodule directory with "git submodule init",
the $GIT_DIR metainformation directory for submodules is created inside
$GIT_DIR/modules/<name>/ directory of the superproject and referenced
via the gitfile mechanism. This is to make it possible to switch
between commits in the superproject that has and does not have the
submodule in the tree without re-cloning.
* "gitweb" leaked unescaped control characters from syntax hiliter
outputs.
* "gitweb" can be told to give custom string at the end of the HTML
HEAD element.
* "gitweb" now has its own manual pages.
Also contains other documentation updates and minor code cleanups.
Fixes since v1.7.7
------------------
Unless otherwise noted, all fixes in the 1.7.7.X maintenance track are
included in this release.
* HTTP transport did not use pushurl correctly, and also did not tell
what host it is trying to authenticate with when asking for
credentials.
(merge deba493 jk/http-auth later to maint).
* "git blame" was aborted if started from an uncommitted content and
the path had the textconv filter in effect.
(merge 8518088 ss/blame-textconv-fake-working-tree later to maint).
* Adding many refs to the local repository in one go (e.g. "git fetch"
that fetches many tags) and looking up a ref by name in a repository
with too many refs were unnecessarily slow.
(merge 17d68a54d jp/get-ref-dir-unsorted later to maint).
* Report from "git commit" on untracked files was confused under
core.ignorecase option.
(merge 395c7356 jk/name-hash-dirent later to maint).
* "git merge" did not understand ":/<pattern>" as a way to name a commit.
" "git push" on the receiving end used to call post-receive and post-update
hooks for attempted removal of non-existing refs.
(merge 160b81ed ph/push-to-delete-nothing later to maint).
* Help text for "git remote set-url" and "git remote set-branches"
were misspelled.
(merge c49904e fc/remote-seturl-usage-fix later to maint).
(merge 656cdf0 jc/remote-setbranches-usage-fix later to maint).
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #01; Fri, 2)
From: Junio C Hamano @ 2011-12-02 20:30 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
Now that 1.7.8 is tagged, I'll start planning to rewind 'next' by kicking
topics back to 'pu' and/or dropping them, but let's give the new release a
couple of days of calm.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
- rebase -i: interrupt rebase when "commit --amend" failed during "reword"
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
(this branch uses jc/stream-to-pack.)
* jh/fast-import-notes (2011-11-28) 3 commits
- fast-import: Fix incorrect fanout level when modifying existing notes refs
- t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
- t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
* ld/p4-labels-branches (2011-11-30) 4 commits
- git-p4: importing labels should cope with missing owner
- git-p4: add test for p4 labels
- git-p4: cope with labels with empty descriptions
- git-p4: handle p4 branches and labels containing shell chars
Retracted?
* tj/maint-imap-send-remove-unused (2011-11-23) 2 commits
- Merge branch 'maint' into tj/imap-send-remove-unused
- imap-send: Remove unused 'use_namespace' variable
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Needs an Ack or two from completion folks before going forward.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
See comments on sr/fix-fast-export-tips topic.
* sr/fix-fast-export-tips (2011-11-05) 3 commits
- fast-export: output reset command for commandline revs
- fast-export: do not refer to non-existing marks
- t9350: point out that refs are not updated correctly
The bottom commit from the stalled sr/transport-helper-fix-rfc topic is
fixed with this. It may make sense to drop the other topic and include
that commit in this series.
The command line parser is still too lax and accepts malformed input, but
this is a step in the right direction and tightening the command line now
should be doable without a low level surgery that touches codepaths that
are unrelated to the command line processing like the previous attempt
used to do.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will drop.
* eh/grep-scale-to-cpunum (2011-11-05) 1 commit
- grep: detect number of CPUs for thread spawning
Kills I/O parallelism and needs to be improved or discarded.
* jc/commit-tree-extra (2011-11-12) 2 commits
- commit-tree: teach -C <extra-commit>
- commit-tree: teach -x <extra>
(this branch uses jc/pull-signed-tag; is tangled with jc/signed-commit.)
Not absolutely needed; parked in 'pu' but may drop.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
--------------------------------------------------
[Cooking]
* cn/maint-lf-to-crlf-filter (2011-11-28) 1 commit
- convert: track state in LF-to-CRLF filter
Candidate for early next cycle.
* nd/maint-ignore-exclude (2011-11-28) 1 commit
- checkout,merge: loosen overwriting untracked file check based on info/exclude
(this branch is used by nd/ignore-might-be-precious.)
Candidate for early next cycle.
* vr/git-merge-doc (2011-11-21) 1 commit
- Show error for 'git merge' with unset merge.defaultToUpstream
Candidate for early next cycle.
* jn/branch-move-to-self (2011-11-28) 2 commits
- Allow checkout -B <current-branch> to update the current branch
- branch: allow a no-op "branch -M <current-branch> HEAD"
Candidate for early next cycle.
* jk/credentials (2011-11-28) 20 commits
- fixup! 034c066e
- compat/getpass: add a /dev/tty implementation
- credential: use git_prompt instead of git_getpass
- prompt: add PROMPT_ECHO flag
- stub out getpass_echo function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- t: add test harness for external credential helpers
- credentials: add "store" helper
- strbuf: add strbuf_add*_urlencode
- credentials: add "cache" helper
- docs: end-user documentation for the credential subsystem
- credential: make relevance of http path configurable
- credential: add credential.*.username
- credential: apply helper config
- http: use credential API to get passwords
- credential: add function for parsing url components
- introduce credentials API
- t5550: fix typo
- test-lib: add test_config_global variant
* nd/ignore-might-be-precious (2011-11-28) 2 commits
- checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
- Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-precious
(this branch uses nd/maint-ignore-exclude.)
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
- upload-archive: use start_command instead of fork
* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
- archive: don't let remote clients get unreachable commits
(this branch is used by jk/maint-upload-archive.)
* jk/maint-upload-archive (2011-11-21) 1 commit
- Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
(this branch uses jk/maint-1.6.2-upload-archive.)
* jk/refresh-porcelain-output (2011-11-18) 3 commits
(merged to 'next' on 2011-11-18 at 872f25e)
+ refresh_index: make porcelain output more specific
+ refresh_index: rename format variables
+ read-cache: let refresh_cache_ent pass up changed flags
* ab/enable-i18n (2011-11-18) 1 commit
- i18n: add infrastructure for translating Git with gettext
* gh/userdiff-matlab (2011-11-15) 1 commit
(merged to 'next' on 2011-11-18 at 10cd275)
+ Add built-in diff patterns for MATLAB code
* jc/maint-pack-object-cycle (2011-11-16) 1 commit
(merged to 'next' on 2011-11-18 at 3715a81)
+ pack-object: tolerate broken packs that have duplicated objects
Make the client side more robust against bogus pack stream; the problem
was discovered by accident while repacking a clone obtained from somewhat
buggy test server.
* jc/index-pack-reject-dups (2011-11-16) 1 commit
(merged to 'next' on 2011-11-18 at 2090221)
+ receive-pack, fetch-pack: reject bogus pack that records objects twice
And this is the prevention to reject such pack stream in the first place.
* nd/resolve-ref (2011-11-13) 2 commits
(merged to 'next' on 2011-11-18 at 8e17b34)
+ Copy resolve_ref() return value for longer use
+ Convert many resolve_ref() calls to read_ref*() and ref_exists()
A fix for an error-reporting codepath that is not a regression, that
turned into a patch that touches many callsite.
* vr/msvc (2011-10-31) 3 commits
(merged to 'next' on 2011-11-14 at f46d021)
+ MSVC: Remove unneeded header stubs
+ Compile fix for MSVC: Include <io.h>
+ Compile fix for MSVC: Do not include sys/resources.h
* na/strtoimax (2011-11-05) 3 commits
(merged to 'next' on 2011-11-14 at b64e1cb)
+ Support sizes >=2G in various config options accepting 'g' sizes.
+ Compatibility: declare strtoimax() under NO_STRTOUMAX
+ Add strtoimax() compatibility function.
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
(this branch uses jc/pull-signed-tag; is tangled with jc/commit-tree-extra.)
Rebased on top of jc/pull-signed-tag topic, after reverting the old one
out of 'next'.
* jc/pull-signed-tag (2011-11-12) 15 commits
(merged to 'next' on 2011-11-14 at 25e8838)
+ commit-tree: teach -m/-F options to read logs from elsewhere
+ commit-tree: update the command line parsing
+ commit: teach --amend to carry forward extra headers
+ merge: force edit and no-ff mode when merging a tag object
+ commit: copy merged signed tags to headers of merge commit
+ merge: record tag objects without peeling in MERGE_HEAD
+ merge: make usage of commit->util more extensible
+ fmt-merge-msg: Add contents of merged tag in the merge message
+ fmt-merge-msg: package options into a structure
+ fmt-merge-msg: avoid early returns
+ refs DWIMmery: use the same rule for both "git fetch" and others
+ fetch: allow "git fetch $there v1.0" to fetch a tag
+ merge: notice local merging of tags and keep it unwrapped
+ fetch: do not store peeled tag object names in FETCH_HEAD
+ Split GPG interface into its own helper library
(this branch is used by jc/commit-tree-extra and jc/signed-commit.)
Further updated to allow "commit --amend" to retain the mergetag
headers. I think this is ready for the cycle after upcoming 1.7.8.
* jc/request-pull-show-head-4 (2011-11-09) 12 commits
(merged to 'next' on 2011-11-13 at e473fd2)
+ request-pull: use the annotated tag contents
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements. It also allows requesting for
a signed tag to be pulled and shows the tag message in the generated message.
* ab/clang-lints (2011-11-06) 2 commits
(merged to 'next' on 2011-11-13 at a573aec)
+ cast variable in call to free() in builtin/diff.c and submodule.c
+ apply: get rid of useless x < 0 comparison on a size_t type
* ab/pull-rebase-config (2011-11-07) 1 commit
(merged to 'next' on 2011-11-13 at 72bb2d5)
+ pull: introduce a pull.rebase option to enable --rebase
* nd/fsck-progress (2011-11-06) 4 commits
(merged to 'next' on 2011-11-13 at 8831811)
+ fsck: print progress
+ fsck: avoid reading every object twice
+ verify_packfile(): check as many object as possible in a pack
+ fsck: return error code when verify_pack() goes wrong
* nd/prune-progress (2011-11-07) 3 commits
(merged to 'next' on 2011-11-13 at c5722ac)
+ reachable: per-object progress
+ prune: handle --progress/no-progress
+ prune: show progress while marking reachable objects
* jc/stream-to-pack (2011-12-01) 5 commits
- bulk-checkin: replace fast-import based implementation
- csum-file: introduce sha1file_checkpoint
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* mf/curl-select-fdset (2011-11-04) 4 commits
(merged to 'next' on 2011-11-06 at a49516f)
+ http: drop "local" member from request struct
+ http.c: Rely on select instead of tracking whether data was received
+ http.c: Use timeout suggested by curl instead of fixed 50ms timeout
+ http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
Reduces unnecessary waits.
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
* mh/ref-api-3 (2011-11-16) 26 commits
(merged to 'next' on 2011-11-16 at cc76151)
+ refs: loosen over-strict "format" check
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-2.)
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
* mh/ref-api-2 (2011-11-16) 15 commits
(merged to 'next' on 2011-11-16 at 511457f)
+ refs: loosen over-strict "format" check
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-3.)
^ permalink raw reply
* Re: [PATCH] gitweb: Don't append ';js=(0|1)' to external links
From: Jakub Narebski @ 2011-12-02 20:44 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0UuyH3m0RR2=jk5apFjVMgbD5iWeztR94mE-m7q9dyYKR2Q@mail.gmail.com>
On Tue, 29 Nov 2011, Jürgen Kreileder wrote:
> On Tue, Nov 29, 2011 at 20:28, Jakub Narebski <jnareb@gmail.com> wrote:
> > Jürgen Kreileder <jk@blackdown.de> writes:
> [...]
> > Thanks for this, but I think a better solution would be to explicitly
> > mark the few external links we have e.g. with 'class="external"', and
> > use that to avoid adding ';js=(0|1)' to them.
>
> This won't work because there are more than a few external links. Think of
> links added in the header or footer or via a project specific README.html.
Thanks for noticing that.
> You would have to do it the other way round: Mark all internal links.
In this case your solution is better... provided that you either check
that all internal links generated by gitweb are absolute URLs in all cases
(they always include $my_url), or add ';js=(0|1)' also for relative
URLs (i.e. not starting with http:// or https://).
Well... the "mark external" idea would also work, provided that we rework
how ';js=(0|1)' is generated. Instead of fixing links on load, we could
add an event handler[1] which on clicking the link[2] would add
';js=(0|1)'... and there you can check if we are inside README.html etc.
by examining DOM (perhaps those externally added fragments would need to
be wrapped in div / span with "external" class, though).
[1] You assign event handler to 'html' or 'body' element, and check in
handler where you clicked; that is what we do for JavaScript
timezone stuff.
[2] I am not sure if "Open in new tab" from context menu or Ctrl-Click
would trigger adding ';js=(0|1)' or not... and whether it is a bad
thing or not.
> > This has the advantage that we can use different style to mark
> > outgoing external links.
I think this advantage might be worth it, even without changes to
javascript-detection.js
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] Add MYMETA.yml to perl/.gitignore
From: Sebastian Morr @ 2011-12-02 22:55 UTC (permalink / raw)
To: gitster; +Cc: Jeff King, git
In-Reply-To: <20111201223520.GB4869@sigill.intra.peff.net>
This file is auto-generated by newer versions of ExtUtils::MakeMaker
(presumably starting with the version shipping with Perl 5.14). It just
contains extra information about the environment and arguments to the
Makefile-building process, and can be safely deleted.
Signed-off-by: Sebastian Morr <sebastian@morr.cc>
---
perl/.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/.gitignore b/perl/.gitignore
index 98b2477..9235e73 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,5 +1,6 @@
perl.mak
perl.mak.old
+MYMETA.yml
blib
blibdirs
pm_to_blib
--
1.7.8.rc4.dirty
^ permalink raw reply related
* Re: [PATCH v2] Add MYMETA.yml to perl/.gitignore
From: Junio C Hamano @ 2011-12-02 23:41 UTC (permalink / raw)
To: Sebastian Morr; +Cc: Jeff King, git
In-Reply-To: <20111202225528.GA1176@thinkpad>
Sebastian Morr <sebastian@morr.cc> writes:
> This file is auto-generated by newer versions of ExtUtils::MakeMaker
> (presumably starting with the version shipping with Perl 5.14). It just
> contains extra information about the environment and arguments to the
> Makefile-building process, and can be safely deleted.
"safely deleted" sounds as if you made "make clean" remove it. I do not
mind doing s/and can be.*/and should be ignored./ myself, if you want.
Does running "make clean" actually remove it, by the way?
> Signed-off-by: Sebastian Morr <sebastian@morr.cc>
> ---
> perl/.gitignore | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/perl/.gitignore b/perl/.gitignore
> index 98b2477..9235e73 100644
> --- a/perl/.gitignore
> +++ b/perl/.gitignore
> @@ -1,5 +1,6 @@
> perl.mak
> perl.mak.old
> +MYMETA.yml
> blib
> blibdirs
> pm_to_blib
^ permalink raw reply
* Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-02 23:17 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I have a git repo with about 300k commits, 150k files totaling maybe 7GB.
Locally committing a small change - say touching fewer than 300 bytes
across 4 files - consistently takes over one second, which seems kinda
slow. This is using git 1.7.7.4 on a linux 2.6 box. The time does not
improve after doing a git-gc (my .git dir has maybe 250 files after a git
gc). The same size commit on a brand new repo takes < 10ms. Any thoughts
on why committing a small change seems to take a long time on larger repos?
Fwiw, I also tried doing the same test using libgit2 (via the pygit2
wrapper), and it was ever slower (about 6 seconds to commit the same small
change).
Thanks for any thoughts or places to look.
Cheers,
Josh
^ permalink raw reply
* gitk show only all refs matching pattern
From: Neal Kreitzinger @ 2011-12-03 0:02 UTC (permalink / raw)
To: git
Is there a way to tell gitk to show only all refs matching a pattern (e.g.,
all refs matching refs/heads/neal/*)? (I'm using git 1.7.1)
v/r,
neal
^ permalink raw reply
* Re: [PATCH v2] Add MYMETA.yml to perl/.gitignore
From: Sebastian Morr @ 2011-12-03 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvcpymti3.fsf@alter.siamese.dyndns.org>
On Fri, Dec 02, 2011 at 03:41:24PM -0800, Junio C Hamano wrote:
> Sebastian Morr <sebastian@morr.cc> writes:
>
> > This file is auto-generated by newer versions of ExtUtils::MakeMaker
> > (presumably starting with the version shipping with Perl 5.14). It just
> > contains extra information about the environment and arguments to the
> > Makefile-building process, and can be safely deleted.
>
> "safely deleted" sounds as if you made "make clean" remove it. I do not
> mind doing s/and can be.*/and should be ignored./ myself, if you want.
You're very welcome to do that.
> Does running "make clean" actually remove it, by the way?
Yes, it does. perl/perl.mak (which, in turn, is generated by MakeMaker
via perl/Makefile) takes care of that file explicitly.
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Carlos Martín Nieto @ 2011-12-03 0:23 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CAFE9C7B.2BFEC%joshua.redstone@fb.com>
[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]
On Fri, Dec 02, 2011 at 11:17:10PM +0000, Joshua Redstone wrote:
> Hi,
> I have a git repo with about 300k commits, 150k files totaling maybe 7GB.
> Locally committing a small change - say touching fewer than 300 bytes
> across 4 files - consistently takes over one second, which seems kinda
> slow. This is using git 1.7.7.4 on a linux 2.6 box. The time does not
> improve after doing a git-gc (my .git dir has maybe 250 files after a git
> gc). The same size commit on a brand new repo takes < 10ms. Any thoughts
> on why committing a small change seems to take a long time on larger repos?
By "same size commit" do you mean the same amount of changes, or the
same amount of files? Committing doesn't depend on the size of the
repo (by itself), but on the size of the index, which depends on the
amount of files to be committed (as git is snapshot-based). At one
point, commit forgot how to write the tree cache to the index (a
performance optimisation). Do the times improve if you run 'git
read-tree HEAD' between one commit and another? Note that this will
reset the index to the last commit, though for the tests I image you
use some variation of 'git commit -a'.
Thomas Rast wrote a patch to re-teach commit to store the tree cache,
but there were some issues and never got applied.
>
> Fwiw, I also tried doing the same test using libgit2 (via the pygit2
> wrapper), and it was ever slower (about 6 seconds to commit the same small
> change).
I don't know about the python bindings, but on the (somewhat
unscientific) tests for libgit2's write-tree (the slow part of a
creating a commit), it performs slightly faster than git's (though I
think git's write-tree does update the tree cache, which libgit2
doesn't currently). The speed could just be a side-effect of the small
test repo. From your domain, I assume the data is not for public
consumption, but it'd be great if you could post your code to pygit2's
issue tracker so we can see how much of the slowdown comes from the
bindings or the library.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Suggestion on hashing
From: Bill Zaumen @ 2011-12-03 0:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, Git Mailing List
In-Reply-To: <CACsJy8CO1GtpZVo-oA2eKbQadsXYBEKVLfUH0GONR5jovuvH+Q@mail.gmail.com>
On Fri, 2011-12-02 at 21:22 +0700, Nguyen Thai Ngoc Duy wrote:
> (I'm not sure why you dropped git@vger. I see nothing private here so
> I bring git@vger back)
Oh, I just didn't want to flood the mailing list with too much on
one topic and figured we could summarize a discussion at some point
and post that, but if you'd rather keep it all on the list, that's
fine with me.
I can split the code into a series of smaller patches - smaller than
the set of three I sent, but I'm not sure if the test scripts will work
with all of the intermediate patches if I do that.
I can also make the digest (current a CRC) pluggable. Then you can try
different digests as an experiment and see how that affects performance.
My implementation uses the CRC or new digests only when
the object database is being modified or explicitly verified. Basically
the code provides memoization for an additional hash function, used
for whatever purpose you desire.
If you want to put a digest of message digests into a commit message,
you can do that fairly quickly as one level of digests has been
precomputed. I think Jeff's or your suggestion of putting an additional
digest in the commit message is a good idea. If you want to experiment
with such changes, the code would provide a reasonable start on that.
So, I guess I should make those changes - pluggable digest and
splitting the patches further.
> You'd need to convince git maintainer this is worth doing first,
> before talking how big the changes are ;-)
I'd guess there are several issues: the amount of code, how complex
the changes are, what the performance impacts are, whether the changes
are backwards compatible, and what you get for the effort.
As a start on the last question, "what you get," aside from some extra
checking to detect problems, if you modify commit messages and signed
tags to use better digests, you can make a stronger argument regarding
authentication. For example, suppose you have a project in which your
code is dual-licensed - GPL for free use but a separate license if the
code is used in a proprietary product and there is a legal dispute,
using a better digest than SHA-1 would have some advantages - when they
start calling in expert witnesses, one side will bring in a security
expert who will testify that SHA-1 is too weak to be used for
authentication, citing government publications such
as http://csrc.nist.gov/groups/ST/hash/statement.html as evidence. The
jury is not going to consist of people who can fully understand the
details, so being able to say that git's authentication matches current
best practices would be an additional reason to use git.
^ permalink raw reply
* Re: Suggestion on hashing
From: Bill Zaumen @ 2011-12-03 1:50 UTC (permalink / raw)
To: Jeff King; +Cc: git, pclouds
In-Reply-To: <20111202175444.GB24093@sigill.intra.peff.net>
On Fri, 2011-12-02 at 12:54 -0500, Jeff King wrote:
> On Fri, Dec 02, 2011 at 12:08:39AM -0800, Bill Zaumen wrote:
> I think your code is solving the wrong problem (or solving the right
> problem in a half-way manner). The only things that make sense to me
> are:
>
> 1. Do nothing. SHA-1 is probably not broken yet, even by the NSA, and
> even if it is, an attack is extremely expensive to mount. This may
> change in the future, of course, but it will probably stay
> expensive for a while.
>
> 2. Decouple the object identifier and digest roles, but insert the
> digest into newly created objects, so it can be part of the
> signature chain. I described such a scheme in one of my replies to
> you. It has some complexities, but has the bonus that we can build
> directly on older history, preserving its sha1s.
>
> 3. Replace SHA-1 with a more secure algorithm.
Suppose I make the digest pluggable, something I intended to do
eventually anyway? Then you just use the existing SHA-1 as an
object identifier and the new digest in a signature chain? What I
did was essentially to compute the new digest (using a CRC as the
trivial case) whenever an object's SHA-1 hash is computed, plus
using the new digest for low-cost collision checks.
Then you have everything needed to experiment with your second option.
I got the impression that Nguyen had some interest in that, but could
be mistaken.
The use is simple: if you have the SHA-1 hash of an object, you call
a function, currently named "has_sha1_file_crc" and it returns true if
a CRC is available, writing the hash into the buffer supplied as its
second argument. You can do whatever you like with it. If you want
a digest of digests, you just traverse a commit's tree, and call
has_sha1_file_crc whenever you want to look up a digest. So, the API
is actually very simple if you just use the patch to quickly look up
the digest associated with a SHA-1 ID - everything else it does happens
automatically.
^ permalink raw reply
* Re: git auto-repack is broken...
From: George Spelvin @ 2011-12-03 6:55 UTC (permalink / raw)
To: git; +Cc: linux, peff
Thanks, Jeff, for the life-cycle chart.
A couple of ideas come to mind:
- When unpacking objects from a pack, it should be fine to set their
date to that of the pack. After all, they're at least that old.
- We could put unreferenced objects into packs whose date is the most
recent of any of the contained objects.
- We could then group unreferenced objects into packs based on age,
so their ages sould not be affected too much by the preceding
operations.
That still produces a noticeable number of packs, which isn't
good, but maybe it's better that keeping thousands of loose
objects for a month...
^ permalink raw reply
* Re: gitk show only all refs matching pattern
From: Johannes Sixt @ 2011-12-03 8:11 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jbbouj$p2$1@dough.gmane.org>
Am 03.12.2011 01:02, schrieb Neal Kreitzinger:
> Is there a way to tell gitk to show only all refs matching a pattern (e.g.,
> all refs matching refs/heads/neal/*)? (I'm using git 1.7.1)
That would be
gitk --branches=neal/*
There is also --remotes= which I find quite useful.
-- Hannes
^ permalink raw reply
* Re: Suggestion on hashing
From: Jeff King @ 2011-12-03 15:08 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, pclouds
In-Reply-To: <1322877021.1729.118.camel@yos>
On Fri, Dec 02, 2011 at 05:50:21PM -0800, Bill Zaumen wrote:
> On Fri, 2011-12-02 at 12:54 -0500, Jeff King wrote:
> > On Fri, Dec 02, 2011 at 12:08:39AM -0800, Bill Zaumen wrote:
>
> > I think your code is solving the wrong problem (or solving the right
> > problem in a half-way manner). The only things that make sense to me
> > are:
> >
> > 1. Do nothing. SHA-1 is probably not broken yet, even by the NSA, and
> > even if it is, an attack is extremely expensive to mount. This may
> > change in the future, of course, but it will probably stay
> > expensive for a while.
> >
> > 2. Decouple the object identifier and digest roles, but insert the
> > digest into newly created objects, so it can be part of the
> > signature chain. I described such a scheme in one of my replies to
> > you. It has some complexities, but has the bonus that we can build
> > directly on older history, preserving its sha1s.
> >
> > 3. Replace SHA-1 with a more secure algorithm.
>
> Suppose I make the digest pluggable, something I intended to do
> eventually anyway? Then you just use the existing SHA-1 as an
> object identifier and the new digest in a signature chain? What I
> did was essentially to compute the new digest (using a CRC as the
> trivial case) whenever an object's SHA-1 hash is computed, plus
> using the new digest for low-cost collision checks.
If you make the digest stronger (or pluggable) and include it in the
actual objects themselves, then you have a start on (2).
I'd drop all of the digest-exchange bits from the protocol, as the
actual signatures are the real, trustable verification. I don't think
you can drop the external storage of the digests, which is one of the
ugliest bits. You'll be asking for the digests all the time to create
new commit objects, so you need to have it at hand without rehashing.
And I wouldn't get my hopes up that this will go into git any time soon.
At this point, we're really guessing about how broken SHA-1 will be in
the future, and how much we are going to want to care.
Just my two cents.
-Peff
^ permalink raw reply
* Re: Suggestion on hashing
From: Philip Oakley @ 2011-12-03 15:34 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, pclouds, Jeff King
In-Reply-To: <20111203150842.GA4442@sigill.intra.peff.net>
Had you seen the recent thread by Junio with the footnote link to the paper
on reconcilliation by using multiple hashes?
http://article.gmane.org/gmane.linux.kernel/1214517.
"What's the Difference? Efficient Set Reconciliation without Prior
Context" http://cseweb.ucsd.edu/~fuyeda/papers/sigcomm2011.pdfIt looks to
have a lot of the properties being sought, and links with other git aspects.
Philip
From: "Jeff King" <peff@peff.net>: Saturday, December 03, 2011 3:08 PM
On Fri, Dec 02, 2011 at 05:50:21PM -0800, Bill Zaumen wrote:
> On Fri, 2011-12-02 at 12:54 -0500, Jeff King wrote:
> > On Fri, Dec 02, 2011 at 12:08:39AM -0800, Bill Zaumen wrote:
>
> > I think your code is solving the wrong problem (or solving the right
> > problem in a half-way manner). The only things that make sense to me
> > are:
> >
> > 1. Do nothing. SHA-1 is probably not broken yet, even by the NSA, and
> > even if it is, an attack is extremely expensive to mount. This may
> > change in the future, of course, but it will probably stay
> > expensive for a while.
> >
> > 2. Decouple the object identifier and digest roles, but insert the
> > digest into newly created objects, so it can be part of the
> > signature chain. I described such a scheme in one of my replies to
> > you. It has some complexities, but has the bonus that we can build
> > directly on older history, preserving its sha1s.
> >
> > 3. Replace SHA-1 with a more secure algorithm.
>
> Suppose I make the digest pluggable, something I intended to do
> eventually anyway? Then you just use the existing SHA-1 as an
> object identifier and the new digest in a signature chain? What I
> did was essentially to compute the new digest (using a CRC as the
> trivial case) whenever an object's SHA-1 hash is computed, plus
> using the new digest for low-cost collision checks.
If you make the digest stronger (or pluggable) and include it in the
actual objects themselves, then you have a start on (2).
I'd drop all of the digest-exchange bits from the protocol, as the
actual signatures are the real, trustable verification. I don't think
you can drop the external storage of the digests, which is one of the
ugliest bits. You'll be asking for the digests all the time to create
new commit objects, so you need to have it at hand without rehashing.
And I wouldn't get my hopes up that this will go into git any time soon.
At this point, we're really guessing about how broken SHA-1 will be in
the future, and how much we are going to want to care.
Just my two cents.
-Peff
--
Version: 2012.0.1873 / Virus Database: 2102/4653 - Release Date: 12/02/11
^ permalink raw reply
* [PATCH, v3] git-tag: introduce --[no-]strip options
From: Kirill A. Shutemov @ 2011-12-03 17:12 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kirill A. Shutemov
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Normally git tag stripes tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.
--no-strip is useful if you want to take a tag message as-is, without
any stripping.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
---
Documentation/git-tag.txt | 6 ++++++
builtin/tag.c | 41 +++++++++++++++++++++++++++--------------
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index c83cb13..31463ca 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -99,6 +99,12 @@ OPTIONS
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
is given.
+--strip::
+ Remove from tag message lines starting with '#', trailing spaces from
+ every line and empty lines from the beginning and end. Enabled by
+ default. With `--no-strip`, the tag message given by the user is used
+ as-is.
+
<tagname>::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
diff --git a/builtin/tag.c b/builtin/tag.c
index 9b6fd95..d82774d 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -319,8 +319,14 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
return 0;
}
+struct create_tag_options {
+ unsigned int message;
+ unsigned int sign;
+ unsigned int strip;
+};
+
static void create_tag(const unsigned char *object, const char *tag,
- struct strbuf *buf, int message, int sign,
+ struct strbuf *buf, struct create_tag_options *opt,
unsigned char *prev, unsigned char *result)
{
enum object_type type;
@@ -345,7 +351,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (header_len > sizeof(header_buf) - 1)
die(_("tag header too big."));
- if (!message) {
+ if (!opt->message) {
int fd;
/* write the template message before editing: */
@@ -356,7 +362,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (!is_null_sha1(prev))
write_tag_body(fd, prev);
- else
+ else if (opt->strip)
write_or_die(fd, _(tag_template), strlen(_(tag_template)));
close(fd);
@@ -367,14 +373,15 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
- stripspace(buf, 1);
+ if (opt->strip)
+ stripspace(buf, 1);
- if (!message && !buf->len)
+ if (opt->message && !buf->len)
die(_("no tag message?"));
strbuf_insert(buf, 0, header_buf, header_len);
- if (build_tag_object(buf, sign, result) < 0) {
+ if (build_tag_object(buf, opt->sign, result) < 0) {
if (path)
fprintf(stderr, _("The tag message has been left in %s\n"),
path);
@@ -422,9 +429,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct ref_lock *lock;
-
- int annotate = 0, sign = 0, force = 0, lines = -1,
- list = 0, delete = 0, verify = 0;
+ struct create_tag_options opt;
+ int annotate = 0, force = 0, lines = -1, list = 0,
+ delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
@@ -442,7 +449,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_CALLBACK('m', "message", &msg, "message",
"tag message", parse_msg_arg),
OPT_FILENAME('F', "file", &msgfile, "read message from file"),
- OPT_BOOLEAN('s', "sign", &sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN('s', "sign", &opt.sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN(0, "strip", &opt.strip,
+ "turn off tag message stripping"),
OPT_STRING('u', "local-user", &keyid, "key-id",
"use another key to sign the tag"),
OPT__FORCE(&force, "replace the tag if exists"),
@@ -459,13 +468,16 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
git_config(git_tag_config, NULL);
+ opt.sign = 0;
+ opt.strip = 1;
+
argc = parse_options(argc, argv, prefix, options, git_tag_usage, 0);
if (keyid) {
- sign = 1;
+ opt.sign = 1;
set_signingkey(keyid);
}
- if (sign)
+ if (opt.sign)
annotate = 1;
if (argc == 0 && !(delete || verify))
list = 1;
@@ -523,9 +535,10 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else if (!force)
die(_("tag '%s' already exists"), tag);
+ opt.message = msg.given || msgfile;
+
if (annotate)
- create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ create_tag(object, tag, &buf, &opt, prev, object);
lock = lock_any_ref_for_update(ref.buf, prev, 0);
if (!lock)
--
1.7.7.3
^ permalink raw reply related
* Re: git auto-repack is broken...
From: Brandon Casey @ 2011-12-03 19:42 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Ævar Arnfjörð,
Git Mailing List
In-Reply-To: <20111202174546.GA24093@sigill.intra.peff.net>
On Fri, Dec 2, 2011 at 11:45 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Dec 02, 2011 at 09:35:52AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > When the objects become unreferenced, we eject them from the pack into
>> > loose form again. If they don't become referenced in the 2-week window,
>> > they get pruned then. So yes, you drop the age information, but they do
>> > eventually go away.
>>
>> If you update gc/repack -A to put them in a separate pack, then you would
>> never be able to get rid of them, no? You pack, then eject (which gives
>> them a fresher timestamp), then notice that you are within the 2-week window
>> and pack them again,...
>
> But we shouldn't be packing totally unreferenced objects. Barring bugs,
> the life cycle of such an object should be something like:
>
> 1. Object X is created on branch 'foo'.
>
> 2. Branch 'foo' is deleted, but its commits are still in the HEAD
> reflog, referencing X.
>
> 3. 90 days pass (actually, I think this might be the 30-day
> expire-unreachable time)
>
> 4. "git gc" runs "git repack -Ad", which will eject X from the pack
> into a loose form (because it is not becoming part of the new pack
> we are writing).
Actually, it is right here when the newly loosened unreferenced
objects will be deleted. Objects ejected from a pack _are_ given the
timestamp of the pack they were ejected from. So, if the pack is
older than two weeks (90 days in your example), then so will be the
loosened objects, and git prune will delete them when called by git
gc.
> 5. Two weeks pass.
>
> 6. "git gc" runs "git prune --expire=2.weeks.ago", which removes the
> object.
>
> "gc" runs between (4) and (6) will not re-pack the object, because it
> remains unreferenced.
Correct with the recognition that loose objects get pack mtime, so
step 5 may be less than two weeks.
> I think things might be slowed somewhat by "gc --auto", which will not
> do a "repack -A" until we have too many packs. So steps (3) and (4) are
> really more like "gc runs git-repack without -A" 50 times, and then we
> finally run "git repack -A".
This is correct. This should have the effect of increasing the age of
unreferenced objects when they are finally loosened and make it more
likely that they are pruned during the same git gc operation that
loosens them.
Linus's scenario of fetching a lot of stuff that never actually makes
it into the reflogs is still a valid problem. I'm not sure that
people who don't know what they are doing are going to run into this
problem though. Since he fetches a lot of stuff without ever checking
it out or creating a branch from it, potentially many objects become
unreferenced every time FETCH_HEAD changes. If he does this many
times in a short period of time, he could reach the gc.autopacklimit
and trigger gc --auto and produce more than gc.auto loose objects that
are younger than gc.pruneExpire.
Decreasing gc.pruneExpire as you suggested should make it much less
likely to run into this problem. I wonder if it is worth trying to
limit how often gc --auto is run to not be more often than
gc.pruneExpire or something. If we modified the timestamp that is
assigned to fetched packs, maybe we could use the pack timestamps as
an indicator of how recently git gc has run.
-Brandon
^ permalink raw reply
* Re: [PATCH, v3] git-tag: introduce --[no-]strip options
From: Jeff King @ 2011-12-03 20:04 UTC (permalink / raw)
To: Kirill A. Shutemov; +Cc: git, Junio C Hamano
In-Reply-To: <1322932376-15720-1-git-send-email-kirill@shutemov.name>
On Sat, Dec 03, 2011 at 07:12:56PM +0200, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov" <kirill@shutemov.name>
>
> Normally git tag stripes tag message lines starting with '#', trailing
> spaces from every line and empty lines from the beginning and end.
>
> --no-strip is useful if you want to take a tag message as-is, without
> any stripping.
Perhaps this should mirror the "--clean" option from git-commit, as they
are basically doing the same thing? Besides the name difference, --clean
supports three modes: verbatim, whitespace, and strip. And defaults to
strip or whitespace depending on whether we are actually writing into
the editor.
-Peff
^ permalink raw reply
* [PATCH 1/2] t/t4131-apply-fake-ancestor.sh: fix broken test
From: Brandon Casey @ 2011-12-03 20:35 UTC (permalink / raw)
To: git; +Cc: artem.bityutskiy, Brandon Casey
The third test "apply --build-fake-ancestor in a subdirectory" has been
broken since it was introduced. It intended to modify a tracked file named
'sub/3.t' and then produce a diff which could be git apply'ed, but the file
named 'sub/3.t' does not exist. The file that exists in the repo is called
'sub/3'. Since no tracked files were modified, an empty diff was produced,
and the test succeeded.
Correct this test by supplying the intended name of the tracked file,
'sub/3.t', to test_commit in the first test.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t4131-apply-fake-ancestor.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4131-apply-fake-ancestor.sh b/t/t4131-apply-fake-ancestor.sh
index 94373ca..b1361ce 100755
--- a/t/t4131-apply-fake-ancestor.sh
+++ b/t/t4131-apply-fake-ancestor.sh
@@ -11,7 +11,7 @@ test_expect_success 'setup' '
test_commit 1 &&
test_commit 2 &&
mkdir sub &&
- test_commit 3 sub/3 &&
+ test_commit 3 sub/3.t &&
test_commit 4
'
--
1.7.8
^ permalink raw reply related
* [PATCH 2/2] builtin/apply.c: report error on failure to recognize input
From: Brandon Casey @ 2011-12-03 20:35 UTC (permalink / raw)
To: git; +Cc: artem.bityutskiy, Brandon Casey
In-Reply-To: <1322944550-27344-1-git-send-email-drafnel@gmail.com>
When git apply is passed something that is not a patch, it does not produce
an error message or exit with a non-zero status if it was not actually
"applying" the patch i.e. --check or --numstat etc were supplied on the
command line.
Fix this by producing an error when apply fails to find any hunks whatsoever
while parsing the patch.
This will cause some of the output formats (--numstat, --diffstat, etc) to
produce an error when they formerly would have reported zero changes and
exited successfully. That seems like the correct behavior though. Failure
to recognize the input as a patch should be an error.
Plus, add a test.
Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
Initially, I was reluctant to change the error message, thinking that
error messages for plumbing commands were not supposed to change. But I
think I was wrong in that thought, so I changed the error message so it
was a more descriptive "unrecognized input".
-Brandon
builtin/apply.c | 10 +++++-----
t/t4136-apply-check.sh | 19 +++++++++++++++++++
2 files changed, 24 insertions(+), 5 deletions(-)
create mode 100755 t/t4136-apply-check.sh
diff --git a/builtin/apply.c b/builtin/apply.c
index 84a8a0b..46dcf3c 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3590,15 +3590,12 @@ static int write_out_one_reject(struct patch *patch)
return -1;
}
-static int write_out_results(struct patch *list, int skipped_patch)
+static int write_out_results(struct patch *list)
{
int phase;
int errs = 0;
struct patch *l;
- if (!list && !skipped_patch)
- return error("No changes");
-
for (phase = 0; phase < 2; phase++) {
l = list;
while (l) {
@@ -3724,6 +3721,9 @@ static int apply_patch(int fd, const char *filename, int options)
offset += nr;
}
+ if (!list && !skipped_patch)
+ die("unrecognized input");
+
if (whitespace_error && (ws_error_action == die_on_ws_error))
apply = 0;
@@ -3741,7 +3741,7 @@ static int apply_patch(int fd, const char *filename, int options)
!apply_with_reject)
exit(1);
- if (apply && write_out_results(list, skipped_patch))
+ if (apply && write_out_results(list))
exit(1);
if (fake_ancestor)
diff --git a/t/t4136-apply-check.sh b/t/t4136-apply-check.sh
new file mode 100755
index 0000000..a321f7c
--- /dev/null
+++ b/t/t4136-apply-check.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='git apply should exit non-zero with unrecognized input.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ test_commit 1
+'
+
+test_expect_success 'apply --check exits non-zero with unrecognized input' '
+ test_must_fail git apply --check - <<-\EOF
+ I am not a patch
+ I look nothing like a patch
+ git apply must fail
+ EOF
+'
+
+test_done
--
1.7.8
^ permalink raw reply related
* Re: Suggestion on hashing
From: Bill Zaumen @ 2011-12-03 21:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, pclouds
In-Reply-To: <20111203150842.GA4442@sigill.intra.peff.net>
On Sat, 2011-12-03 at 10:08 -0500, Jeff King wrote:
> >
> > Suppose I make the digest pluggable, something I intended to do
> > eventually anyway? Then you just use the existing SHA-1 as an
> > object identifier and the new digest in a signature chain? What I
> > did was essentially to compute the new digest (using a CRC as the
> > trivial case) whenever an object's SHA-1 hash is computed, plus
> > using the new digest for low-cost collision checks.
>
> If you make the digest stronger (or pluggable) and include it in the
> actual objects themselves, then you have a start on (2).
>
> I'd drop all of the digest-exchange bits from the protocol, as the
> actual signatures are the real, trustable verification. I don't think
> you can drop the external storage of the digests, which is one of the
> ugliest bits. You'll be asking for the digests all the time to create
> new commit objects, so you need to have it at hand without rehashing.
The digest-exchange bits, including the tests and response to errors,
is only 222 lines of new code, so its really a minor part. The rest
takes care of what you referred to as "one of the ugliest bits," so
I think it is useful to have available - you can then try various ways
of improving the authentication of commit objects without having to do
a lot of initial work.
I can make those changes - probably over the next couple of weeks or
so (have some other non-related things to take care of) and then send
a new set of patches.
>
> And I wouldn't get my hopes up that this will go into git any time soon.
> At this point, we're really guessing about how broken SHA-1 will be in
> the future, and how much we are going to want to care.
>
> Just my two cents.
Thanks for the discussion. I might add that it is not just a question
of how broken SHA-1 is. If an IT department is considering adopting Git
as the company's revision control system and authentication is important
to the company, an IT manager may not accept SHA-1 for authentication
purposes because NIST claims SHA-1 is not adequate for authentication in
general and explaining to upper management why NIST's statement is not
applicable given the way SHA-1 is used in Git is much harder than
saying, "Git follows the current best practices regarding
authentication." That statement is a simple check-list item one can
show upper management in comparing alternatives.
Such issues (making technical choices for non-technical reasons) have
come up before - I once worked on a high-speed (for the time) networking
project and our manager mentioned that transferring medical records such
as X-ray pictures was one application - they do not accept lossy data
compression because, even if it is completely adequate, in a malpractice
suit, the plaintiff's lawyer would say, "And they purposely threw away
data critical to my client's health," which would sound pretty damning
to a typical jury. The legal risk outweighed the cost of the additional
bandwidth.
^ permalink raw reply
* Evaluation of ref-api branch status
From: Michael Haggerty @ 2011-12-03 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
Junio,
Now that 1.7.8 is out, I wanted to figure out the status of the
remaining ref-api changes that are in flight, including the differences
between between my tree and yours.
I understand that "next" will soon be re-rolled. Will the re-roll be
based on the current "pu", or will you start from scratch?
AFAIK there are three groups of ref-api patch series in flight, some of
which have gone through multiple iterations:
ref-api-B == mh/ref-api-2
[PATCH v3 00/14] Tidying up references code
ref-api-C == mh/ref-api-3
[PATCH v2 00/12] Use refs API more consistently
ref-api-D == mh/ref-api-take-2
[PATCH 00/28] Store references hierarchically in cache
On 2011-10-28 I sent re-rolled versions of ref-api-B and ref-api-C to
the list followed by the first version of ref-api-D. You committed
these three patch series to your repository as a single branch,
"mh/ref-api-take-2". The mh/ref-api-take-2 branch thus includes the
logical equivalent of all three of the patch series listed above.
Additionally, on 2011-11-15 I sent a fix to patch 26/28 of ref-api-D:
[PATCH] Fix "is_refname_available(): query only possibly-conflicting
references"
I don't see this patch in your tree at all.
Meanwhile, you added the following fix on top of master, mh/ref-api-2,
and ref-api-3:
refs: loosen over-strict "format" check
[Aside: I don't understand why you created three independent commits
rather than create an ur-commit on $(git merge-base master mh/ref-api-2
mh/ref-api-3) then merging it to each of the branches.]
Both mh/ref-api-2 (including your fix) and mh/ref-api-3 (including your
fix) have been merged into "next". You have never merged
mh/ref-api-take-2 anywhere. On the mh/ref-api-take-2 branch:
* ce766d41fa corresponds to mh/ref-api-2 (without your fix)
* 633ebc45c0 corresponds to mh/ref-api-3 (without your fix)
Therefore, your 633ebc45c0..mh/ref-api-take-2 corresponds to my newest
"ref-api-D" patch series. It does not include my fix from 2011-11-15.
Nor does it include any form of your fix "refs: loosen over-strict
"format" check".
What is the difference between the beginning of mh/ref-api-take-2 as
compared to mh/ref-api-2 + mh/ref-api-3? Equivalently, what is the
difference between the last versions of ref-api-B and ref-api-C vs.
earlier versions of those patch series? The differences are relatively
minor:
* A whitespace problem in the earlier version of the series was fixed.
This whitespace problem was introduced in caa80697 and has gotten into
"pu" (in refs.c starting at line 1093).
* resolve_gitlink_packed_ref() was simplified a bit and got a docstring.
* A function do_for_each_ref_in_arrays() was extracted.
* The series were rebased. The changes made to rebase them are roughly
equivalent to the work that you did in merges bea03b2455 and 773b817986.
(BTW, your merges look correct to me.)
* It does *not* include your fix "refs: loosen over-strict "format" check".
SUMMARY:
The patches from mh/ref-api-take-2 through 633ebc45c0 plus your fix are
slightly preferable to the patches in mh/ref-api-2 and mh/ref-api-3, in
the ways listed in the bullet-points above. If you are rewinding "next"
anyway, I suggest that you take the former instead of the latter. If
you prefer to stick with the latter, let me know and I will submit the
remaining differences as patches to be applied on top of mh/ref-api-3.
I hope that this summary is helpful to you. (It certainly helped me
figure out where things stand.)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [RFC PATCH] git-p4: introduce asciidoc documentation
From: Pete Wyckoff @ 2011-12-03 23:53 UTC (permalink / raw)
To: git
Add proper documentation for git-p4. Delete the old .txt
documentation from contrib/fast-import.
---
I'd appreciate review by git-p4 people to make sure I captured
everything from the old documentation, and to catch any errors.
There's a fair amount of new content in here, describing all
the options and variables. I left out some obscure commands
on purpose.
Comments from anyone else would be welcome too. Especially
in the area of generic asciidoc formatting or style in git
command pages.
Thanks,
-- Pete
Documentation/git-p4.txt | 456 ++++++++++++++++++++++++++++++++++++++++
contrib/fast-import/git-p4.txt | 289 -------------------------
2 files changed, 456 insertions(+), 289 deletions(-)
create mode 100644 Documentation/git-p4.txt
delete mode 100644 contrib/fast-import/git-p4.txt
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
new file mode 100644
index 0000000..c555dce
--- /dev/null
+++ b/Documentation/git-p4.txt
@@ -0,0 +1,456 @@
+git-p4(1)
+=========
+
+NAME
+----
+git-p4 - Import from and submit to Perforce repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git p4 clone' [<sync options>] [<clone options>] <p4 depot path>...
+'git p4 sync' [<sync options>] [<p4 depot path>...]
+'git p4 rebase'
+'git p4 submit' [<submit options>] [<master branch name>]
+
+
+DESCRIPTION
+-----------
+This command provides a way to interact with p4 repositories
+using git.
+
+Create a new git repository from an existing p4 repository using
+'git p4 clone', giving it one or more p4 depot paths. Incorporate
+new commits from p4 changes with 'git p4 sync'. The 'sync' command
+is also used to include new branches from other p4 depot paths.
+Submit git changes back to p4 using 'git p4 submit'. The command
+'git p4 rebase' does a sync plus rebases the current branch onto
+the updated p4 remote branch.
+
+
+EXAMPLE
+-------
+* Create an alias for 'git p4', using the full path to the 'git-p4'
+ script if needed:
++
+------------
+$ git config --global alias.p4 '!git-p4'
+------------
+
+* Clone a repository:
++
+------------
+$ git p4 clone //depot/path/project
+------------
+
+* Do some work in the newly created git repository:
++
+------------
+$ cd project
+$ vi foo.h
+$ git commit -a -m "edited foo.h"
+------------
+
+* Update the git repository with recent changes from p4, rebasing your
+ work on top:
++
+------------
+$ git p4 rebase
+------------
+
+* Submit your commits back to p4:
++
+------------
+$ git p4 submit
+------------
+
+
+COMMANDS
+--------
+
+Clone
+~~~~~
+Generally, 'git p4 clone' is used to create a new git directory
+from an existing p4 repository:
+------------
+$ git p4 clone //depot/path/project
+------------
+This:
+
+1. Creates an empty git repository in a subdirectory called 'project'.
++
+2. Imports the full contents of the head revision from the given p4
+depot path into a single commit in the git branch 'refs/remotes/p4/master'.
++
+3. Creates a local branch, 'master' from this remote and checks it out.
+
+To reproduce the entire p4 history in git, use the '@all' modifier on
+the depot path:
+------------
+$ git p4 clone //depot/path/project@all
+------------
+
+
+Sync
+~~~~
+As development continues in the p4 repository, those changes can
+be included in the git repository using:
+------------
+$ git p4 sync
+------------
+This command finds new changes in p4 and imports them as git commits.
+
+P4 repositories can be added to an existing git repository using
+'git p4 sync' too:
+------------
+$ mkdir repo-git
+$ cd repo-git
+$ git init
+$ git p4 sync //path/in/your/perforce/depot
+------------
+This imports the specified depot into
+'refs/remotes/p4/master' in an existing git repository. The
+'--branch' option can be used to specify a different branch to
+be used for the p4 content.
+
+If a git repository includes branches 'refs/remotes/origin/p4', these
+will be fetched and consulted first during a 'git p4 sync'. Since
+importing directly from p4 is considerably slower than pulling changes
+from a git remote, this can be useful in a multi-developer environment.
+
+
+Rebase
+~~~~~~
+A common working pattern is to fetch the latest changes from the p4 depot
+and merge them with local uncommitted changes. Often, the p4 repository
+is the ultimate location for all code, thus a rebase workflow makes
+sense. This command does 'git p4 sync' followed by 'git rebase' to move
+local commits on top of updated p4 changes.
+------------
+$ git p4 rebase
+------------
+
+
+Submit
+~~~~~~
+Submitting changes from a git repository back to the p4 repository
+requires a separate p4 client workspace. This should be specified
+using the 'P4CLIENT' environment variable or the git configuration
+variable 'git-p4.client'. The p4 client must exist, but the client root
+will be created and populated if it does not already exist.
+
+To submit all changes that are in the current git branch but not in
+the 'p4/master' branch, use:
+------------
+$ git p4 submit
+------------
+
+To specify a branch other than the current one, use:
+------------
+$ git p4 submit topicbranch
+------------
+
+The upstream reference is generally 'refs/remotes/p4/master', but can
+be overridden using the '--origin=' command-line option.
+
+The p4 changes will be created as the user invoking 'git p4 submit'. The
+'--preserve-user' option will cause ownership to be modified
+according to the author of the git commit. This option requires admin
+priviliges in p4, which can be granted using 'p4 protect'.
+
+
+OPTIONS
+-------
+
+General options
+~~~~~~~~~~~~~~~
+All commands except clone accept this option.
+
+--git-dir <dir>::
+ Set the 'GIT_DIR' environment variable. See linkgit:git[1].
+
+Sync options
+~~~~~~~~~~~~
+These options can be used in the initial 'clone' as well as in
+subsequent 'sync' operations.
+
+--branch <branch>::
+ Import changes into given branch. If the branch starts with
+ 'refs/', it will be used as is, otherwise the path 'refs/heads/'
+ will be prepended. The default branch is 'master'.
+
+--detect-branches::
+ Use the branch detection algorithm to find new paths in p4. It is
+ documented below in "BRANCH DETECTION".
+
+--changesfile <file>::
+ Import exactly the p4 change numbers listed in 'file', one per
+ line. Normally, 'git p4' inspects the current p4 repository
+ state and detects the changes it should import.
+
+--silent::
+ Do not print any progress information.
+
+--verbose::
+ Provide more progress information.
+
+--detect-labels::
+ Query p4 for labels associated with the depot paths, and add
+ them as tags in git.
+
+--import-local::
+ By default, p4 branches are stored in 'refs/remotes/p4/',
+ where they will be treated as remote-tracking branches by
+ linkgit:git-branch[1] and other commands. This option instead
+ puts p4 branches in 'refs/heads/p4/'.
+
+--max-changes <n>::
+ Limit the number of imported changes to 'n'. Useful to
+ limit the amount of history when using the '@all' p4 revision
+ specifier.
+
+--keep-path::
+ The mapping of file names from the p4 depot path to git, by
+ default, involves removing the entire depot path. With this
+ option, the full p4 depot path is retained in git. For example,
+ path '//depot/main/foo/bar.c', when imported from
+ '//depot/main/', becomes 'foo/bar.c'. With '--keep-path', the
+ git path is instead 'depot/main/foo/bar.c'.
+
+--use-client-spec::
+ Use a client spec to find the list of interesting files in p4.
+ The client spec is discovered using 'p4 client -o' which checks
+ the 'P4CLIENT' environment variable and returns a mapping of
+ depot files to workspace files.
+
+Clone options
+~~~~~~~~~~~~~
+These options can used in an initial 'clone', along with the 'sync'
+options described above.
+
+--destination <directory>::
+ Where to create the git repository. If not provided, the last
+ component in the p4 depot path is used to create a new
+ directory.
+
+--bare::
+ Perform a bare clone. See linkgit:git-clone[1].
+
+-/ <path>::
+ Exclude selected depot paths when cloning.
+
+Submit options
+~~~~~~~~~~~~~~
+These options can be used to modify 'git p4 submit' behavior.
+
+--verbose::
+ Provide more progress information.
+
+--origin <commit>::
+ Upstream location from which commits are identified to submit to
+ p4. By default, this is the most recent p4 commit reachable
+ from 'HEAD'.
+
+-M[<n>]::
+ Detect renames. See linkgit:git-diff[1]. Renames will be
+ represented in p4 using explicit 'move' operations.
+
+--preserve-user::
+ Re-author p4 changes before submitting to p4. This option
+ requires p4 admin priviliges.
+
+
+DEPOT PATH SYNTAX
+-----------------
+The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can
+be one or more space-separated p4 depot paths, with an optional
+p4 revision specifier on the end:
+
+"//depot/my/project"::
+ Import one commit with all files in the '#head' change under that tree.
+
+"//depot/my/project@all"::
+ Import one commit for each change in the history of that depot path.
+
+"//depot/my/project@1,6"::
+ Import only changes 1 through 6.
+
+"//depot/proj1 //depot/proj2@all"::
+ Import all changes from both named depot paths.
+
+See 'p4 help revisions' for the full syntax of p4 revision specifiers.
+
+
+BRANCH DETECTION
+----------------
+P4 does not have the same concept of a branch as git. Instead,
+p4 organizes its content as a directory tree, where by convention
+different logical branches are in different locations in the tree.
+The 'p4 branch' command is used to maintain mappings between
+different areas in the tree, and indicate related content. 'git p4'
+can use these mappings to determine branch relationships.
+
+If you have a repository where all the branches of interest exist as
+subdirectories of a single depot path, you can use '--detect-branches'
+when cloning or syncing to have 'git p4' automatically find
+subdirectories in p4, and to generate these as branches in git.
+
+For example, if the P4 repository structure is:
+----
+//depot/main/...
+//depot/branch1/...
+----
+
+And "p4 branch -o branch1" shows a View line that looks like:
+----
+//depot/main/... //depot/branch1/...
+----
+
+Then this 'git p4 clone' command:
+----
+git p4 clone --detect-branches //depot@all
+----
+produces a separate branch in 'refs/remotes/p4/' for //depot/main,
+called 'master', and one for //depot/branch1 called 'depot/branch1'.
+
+However, it is not necessary to create branches in p4 to be able to use
+them like branches. Because it is difficult to infer branch
+relationships automatically, a git configuration setting
+'git-p4.branchList' can be used to explicitly identify branch
+relationships. It is a list of "source:destination" pairs, like a
+simple p4 branch specification, where the "source" and "destination" are
+the path elements in the p4 repository. The example above relied on the
+presence of the p4 branch. Without p4 branches, the same result will
+occur with:
+----
+git config git-p4.branchList main:branch1
+git p4 clone --detect-branches //depot@all
+----
+
+
+PERFORMANCE
+-----------
+The fast-import mechanism used by 'git p4' creates one pack file for
+each invocation of 'git p4 sync'. Normally, git garbage compression
+(linkgit:git-gc[1]) automatically compresses these to fewer pack files,
+but explicit invocation of 'git repack -adf' may improve performance.
+
+
+CONFIGURATION VARIABLES
+-----------------------
+The following config settings can be used to modify 'git p4' behavior.
+They all are in the 'git-p4' section.
+
+General variables
+~~~~~~~~~~~~~~~~~
+git-p4.user::
+ User specified as an option to all p4 commands, with '-u <user>'.
+ The environment variable 'P4USER' can be used instead.
+
+git-p4.password::
+ Password specified as an option to all p4 commands, with
+ '-P <password>'.
+ The environment variable 'P4PASS' can be used instead.
+
+git-p4.port::
+ Port specified as an option to all p4 commands, with
+ '-p <port>'.
+ The environment variable 'P4PORT' can be used instead.
+
+git-p4.host::
+ Host specified as an option to all p4 commands, with
+ '-h <host>'.
+ The environment variable 'P4HOST' can be used instead.
+
+git-p4.client::
+ Client specified as an option to all p4 commands, with
+ '-c <client>'. This can also be used as a way to find
+ the client spec for the 'useClientSpec' option.
+ The environment variable 'P4CLIENT' can be used instead.
+
+Clone and sync variables
+~~~~~~~~~~~~~~~~~~~~~~~~
+git-p4.syncFromOrigin::
+ Because importing commits from other git repositories is much faster
+ than importing them from p4, a mechanism exists to find p4 changes
+ first in git remotes. If branches exist under 'refs/remote/origin/p4',
+ those will be fetched and used when syncing from p4. This
+ variable can be set to 'false' to disable this behavior.
+
+git-p4.branchUser::
+ One phase in branch detection involves looking at p4 branches
+ to find new ones to import. By default, all branches are
+ inspected. This option limits the search to just those owned
+ by the single user named in the variable.
+
+git-p4.branchList::
+ List of branches to be imported when branch detection is
+ enabled. Each entry should be a pair of branch names separated
+ by a colon (:). This example declares that both branchA and
+ branchB were created from main:
+-------------
+git config git-p4.branchList main:branchA
+git config --add git-p4.branchList main:branchB
+-------------
+
+git-p4.useClientSpec::
+ Specify that the p4 client spec to be used to identify p4 depot
+ paths of interest. This is equivalent to specifying the option
+ '--use-client-spec'. The variable 'git-p4.client' can be used
+ to specify the name of the client.
+
+Submit variables
+~~~~~~~~~~~~~~~
+git-p4.detectRenames::
+ Detect renames. See linkgit:git-diff[1].
+
+git-p4.detectCopies::
+ Detect copies. See linkgit:git-diff[1].
+
+git-p4.detectCopiesHarder::
+ Detect copies harder. See linkgit:git-diff[1].
+
+git-p4.preserveUser::
+ On submit, re-author changes to reflect the git author,
+ regardless of who invokes 'git p4 submit'.
+
+git-p4.allowMissingP4Users::
+ When 'preserveUser' is true, 'git p4' normally dies if it
+ cannot find an author in the p4 user map. This setting
+ submits the change regardless.
+
+git-p4.skipSubmitEdit::
+ The submit process invokes the editor before each p4 change
+ is submitted. If this setting is true, though, the editing
+ step is skipped.
+
+git-p4.skipSubmitEditCheck::
+ After editing the p4 change message, 'git p4' makes sure that
+ the description really was changed by looking at the file
+ modification time. This option disables that test.
+
+git-p4.allowSubmit::
+ By default, any branch can be used as the source for a 'git p4
+ submit' operation. This configuration variable , if set, permits only
+ the named branches to be used as submit sources.
+
+git-p4.skipUserNameCheck::
+ If the user running 'git p4 submit' does not exist in the p4
+ user map, 'git p4' exits. This option can be used to force
+ submission regardless.
+
+
+IMPLEMENTATION DETAILS
+----------------------
+* Changesets from p4 are imported using git fast-import.
+* Cloning or syncing does not require a p4 client; file contents are
+ collected using 'p4 print'.
+* Submitting requires a p4 client, which is not in the same location
+ as the git repository. Patches are applied, one at a time, to
+ this p4 client and submitted from there.
+* Each commit imported by 'git p4' has a line at the end of the log
+ message indicating the p4 depot location and change number. This
+ line is used by later 'git p4 sync' operations to know which p4
+ changes are new.
+
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
deleted file mode 100644
index 52003ae..0000000
--- a/contrib/fast-import/git-p4.txt
+++ /dev/null
@@ -1,289 +0,0 @@
-git-p4 - Perforce <-> Git converter using git-fast-import
-
-Usage
-=====
-
-git-p4 can be used in two different ways:
-
-1) To import changes from Perforce to a Git repository, using "git-p4 sync".
-
-2) To submit changes from Git back to Perforce, using "git-p4 submit".
-
-Importing
-=========
-
-Simply start with
-
- git-p4 clone //depot/path/project
-
-or
-
- git-p4 clone //depot/path/project myproject
-
-This will:
-
-1) Create an empty git repository in a subdirectory called "project" (or
-"myproject" with the second command)
-
-2) Import the head revision from the given Perforce path into a git branch
-called "p4" (remotes/p4 actually)
-
-3) Create a master branch based on it and check it out.
-
-If you want the entire history (not just the head revision) then you can simply
-append a "@all" to the depot path:
-
- git-p4 clone //depot/project/main@all myproject
-
-
-
-If you want more control you can also use the git-p4 sync command directly:
-
- mkdir repo-git
- cd repo-git
- git init
- git-p4 sync //path/in/your/perforce/depot
-
-This will import the current head revision of the specified depot path into a
-"remotes/p4/master" branch of your git repository. You can use the
---branch=mybranch option to import into a different branch.
-
-If you want to import the entire history of a given depot path simply use:
-
- git-p4 sync //path/in/depot@all
-
-
-Note:
-
-To achieve optimal compression you may want to run 'git repack -a -d -f' after
-a big import. This may take a while.
-
-Incremental Imports
-===================
-
-After an initial import you can continue to synchronize your git repository
-with newer changes from the Perforce depot by just calling
-
- git-p4 sync
-
-in your git repository. By default the "remotes/p4/master" branch is updated.
-
-Advanced Setup
-==============
-
-Suppose you have a periodically updated git repository somewhere, containing a
-complete import of a Perforce project. This repository can be cloned and used
-with git-p4. When updating the cloned repository with the "sync" command,
-git-p4 will try to fetch changes from the original repository first. The git
-protocol used with this is usually faster than importing from Perforce
-directly.
-
-This behaviour can be disabled by setting the "git-p4.syncFromOrigin" git
-configuration variable to "false".
-
-Updating
-========
-
-A common working pattern is to fetch the latest changes from the Perforce depot
-and merge them with local uncommitted changes. The recommended way is to use
-git's rebase mechanism to preserve linear history. git-p4 provides a convenient
-
- git-p4 rebase
-
-command that calls git-p4 sync followed by git rebase to rebase the current
-working branch.
-
-Submitting
-==========
-
-git-p4 has support for submitting changes from a git repository back to the
-Perforce depot. This requires a Perforce checkout separate from your git
-repository. To submit all changes that are in the current git branch but not in
-the "p4" branch (or "origin" if "p4" doesn't exist) simply call
-
- git-p4 submit
-
-in your git repository. If you want to submit changes in a specific branch that
-is not your current git branch you can also pass that as an argument:
-
- git-p4 submit mytopicbranch
-
-You can override the reference branch with the --origin=mysourcebranch option.
-
-The Perforce changelists will be created with the user who ran git-p4. If you
-use --preserve-user then git-p4 will attempt to create Perforce changelists
-with the Perforce user corresponding to the git commit author. You need to
-have sufficient permissions within Perforce, and the git users need to have
-Perforce accounts. Permissions can be granted using 'p4 protect'.
-
-If a submit fails you may have to "p4 resolve" and submit manually. You can
-continue importing the remaining changes with
-
- git-p4 submit --continue
-
-Example
-=======
-
-# Clone a repository
- git-p4 clone //depot/path/project
-# Enter the newly cloned directory
- cd project
-# Do some work...
- vi foo.h
-# ... and commit locally to gi
- git commit foo.h
-# In the meantime somebody submitted changes to the Perforce depot. Rebase your latest
-# changes against the latest changes in Perforce:
- git-p4 rebase
-# Submit your locally committed changes back to Perforce
- git-p4 submit
-# ... and synchronize with Perforce
- git-p4 rebase
-
-
-Configuration parameters
-========================
-
-git-p4.user ($P4USER)
-
-Allows you to specify the username to use to connect to the Perforce repository.
-
- git config [--global] git-p4.user public
-
-git-p4.password ($P4PASS)
-
-Allows you to specify the password to use to connect to the Perforce repository.
-Warning this password will be visible on the command-line invocation of the p4 binary.
-
- git config [--global] git-p4.password public1234
-
-git-p4.port ($P4PORT)
-
-Specify the port to be used to contact the Perforce server. As this will be passed
-directly to the p4 binary, it may be in the format host:port as well.
-
- git config [--global] git-p4.port codes.zimbra.com:2666
-
-git-p4.host ($P4HOST)
-
-Specify the host to contact for a Perforce repository.
-
- git config [--global] git-p4.host perforce.example.com
-
-git-p4.client ($P4CLIENT)
-
-Specify the client name to use
-
- git config [--global] git-p4.client public-view
-
-git-p4.allowSubmit
-
- git config [--global] git-p4.allowSubmit false
-
-git-p4.syncFromOrigin
-
-A useful setup may be that you have a periodically updated git repository
-somewhere that contains a complete import of a Perforce project. That git
-repository can be used to clone the working repository from and one would
-import from Perforce directly after cloning using git-p4. If the connection to
-the Perforce server is slow and the working repository hasn't been synced for a
-while it may be desirable to fetch changes from the origin git repository using
-the efficient git protocol. git-p4 supports this setup by calling "git fetch origin"
-by default if there is an origin branch. You can disable this using:
-
- git config [--global] git-p4.syncFromOrigin false
-
-git-p4.useclientspec
-
- git config [--global] git-p4.useclientspec false
-
-The P4CLIENT environment variable should be correctly set for p4 to be
-able to find the relevant client. This client spec will be used to
-both filter the files cloned by git and set the directory layout as
-specified in the client (this implies --keep-path style semantics).
-
-git-p4.skipSubmitModTimeCheck
-
- git config [--global] git-p4.skipSubmitModTimeCheck false
-
-If true, submit will not check if the p4 change template has been modified.
-
-git-p4.preserveUser
-
- git config [--global] git-p4.preserveUser false
-
-If true, attempt to preserve user names by modifying the p4 changelists. See
-the "--preserve-user" submit option.
-
-git-p4.allowMissingPerforceUsers
-
- git config [--global] git-p4.allowMissingP4Users false
-
-If git-p4 is setting the perforce user for a commit (--preserve-user) then
-if there is no perforce user corresponding to the git author, git-p4 will
-stop. With allowMissingPerforceUsers set to true, git-p4 will use the
-current user (i.e. the behavior without --preserve-user) and carry on with
-the perforce commit.
-
-git-p4.skipUserNameCheck
-
- git config [--global] git-p4.skipUserNameCheck false
-
-When submitting, git-p4 checks that the git commits are authored by the current
-p4 user, and warns if they are not. This disables the check.
-
-git-p4.detectRenames
-
-Detect renames when submitting changes to Perforce server. Will enable -M git
-argument. Can be optionally set to a number representing the threshold
-percentage value of the rename detection.
-
- git config [--global] git-p4.detectRenames true
- git config [--global] git-p4.detectRenames 50
-
-git-p4.detectCopies
-
-Detect copies when submitting changes to Perforce server. Will enable -C git
-argument. Can be optionally set to a number representing the threshold
-percentage value of the copy detection.
-
- git config [--global] git-p4.detectCopies true
- git config [--global] git-p4.detectCopies 80
-
-git-p4.detectCopiesHarder
-
-Detect copies even between files that did not change when submitting changes to
-Perforce server. Will enable --find-copies-harder git argument.
-
- git config [--global] git-p4.detectCopies true
-
-git-p4.branchUser
-
-Only use branch specifications defined by the selected username.
-
- git config [--global] git-p4.branchUser username
-
-git-p4.branchList
-
-List of branches to be imported when branch detection is enabled.
-
- git config [--global] git-p4.branchList main:branchA
- git config [--global] --add git-p4.branchList main:branchB
-
-Implementation Details...
-=========================
-
-* Changesets from Perforce are imported using git fast-import.
-* The import does not require anything from the Perforce client view as it just uses
- "p4 print //depot/path/file#revision" to get the actual file contents.
-* Every imported changeset has a special [git-p4...] line at the
- end of the log message that gives information about the corresponding
- Perforce change number and is also used by git-p4 itself to find out
- where to continue importing when doing incremental imports.
- Basically when syncing it extracts the perforce change number of the
- latest commit in the "p4" branch and uses "p4 changes //depot/path/...@changenum,#head"
- to find out which changes need to be imported.
-* git-p4 submit uses "git rev-list" to pick the commits between the "p4" branch
- and the current branch.
- The commits themselves are applied using git diff/format-patch ... | git apply
-
--
1.7.8.rc4.30.g3c9dc
^ permalink raw reply related
* [PATCH, v4] git-tag: introduce --cleanup option
From: Kirill A. Shutemov @ 2011-12-04 4:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Kirill A. Shutemov
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Normally git tag stripes tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.
--cleanup allows to select different cleanup modes for tag message.
It provides the same interface as --cleanup option in git-commit.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
---
Documentation/git-tag.txt | 10 ++++++
builtin/tag.c | 69 +++++++++++++++++++++++++++++++++++---------
2 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index c83cb13..c2d73f3 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -99,6 +99,16 @@ OPTIONS
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
is given.
+--cleanup=<mode>::
+ This option sets how the tag message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
+ and 'default'. The 'default' mode will strip leading and
+ trailing empty lines and #commentary from the tag message
+ only if the message is to be edited. Otherwise only whitespace
+ removed. The 'verbatim' mode does not change message at all,
+ 'whitespace' removes just leading/trailing whitespace lines
+ and 'strip' removes both whitespace and commentary.
+
<tagname>::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
diff --git a/builtin/tag.c b/builtin/tag.c
index 9b6fd95..27a66a3 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -268,6 +268,15 @@ static const char tag_template[] =
N_("\n"
"#\n"
"# Write a tag message\n"
+ "# Lines starting with '#' will be ignored.\n"
+ "#\n");
+
+static const char tag_template_nocleanup[] =
+ N_("\n"
+ "#\n"
+ "# Write a tag message\n"
+ "# Lines starting with '#' will be kept; you may remove them"
+ " yourself if you want to.\n"
"#\n");
static void set_signingkey(const char *value)
@@ -319,8 +328,18 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
return 0;
}
+struct create_tag_options {
+ unsigned int message;
+ unsigned int sign;
+ enum {
+ CLEANUP_NONE,
+ CLEANUP_SPACE,
+ CLEANUP_ALL
+ } cleanup_mode;
+};
+
static void create_tag(const unsigned char *object, const char *tag,
- struct strbuf *buf, int message, int sign,
+ struct strbuf *buf, struct create_tag_options *opt,
unsigned char *prev, unsigned char *result)
{
enum object_type type;
@@ -345,7 +364,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (header_len > sizeof(header_buf) - 1)
die(_("tag header too big."));
- if (!message) {
+ if (!opt->message) {
int fd;
/* write the template message before editing: */
@@ -356,8 +375,12 @@ static void create_tag(const unsigned char *object, const char *tag,
if (!is_null_sha1(prev))
write_tag_body(fd, prev);
+ else if (opt->cleanup_mode == CLEANUP_ALL)
+ write_or_die(fd, _(tag_template),
+ strlen(_(tag_template)));
else
- write_or_die(fd, _(tag_template), strlen(_(tag_template)));
+ write_or_die(fd, _(tag_template_nocleanup),
+ strlen(_(tag_template_nocleanup)));
close(fd);
if (launch_editor(path, buf, NULL)) {
@@ -367,14 +390,15 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
- stripspace(buf, 1);
+ if (opt->cleanup_mode != CLEANUP_NONE)
+ stripspace(buf, opt->cleanup_mode == CLEANUP_ALL);
- if (!message && !buf->len)
+ if (opt->message && !buf->len)
die(_("no tag message?"));
strbuf_insert(buf, 0, header_buf, header_len);
- if (build_tag_object(buf, sign, result) < 0) {
+ if (build_tag_object(buf, opt->sign, result) < 0) {
if (path)
fprintf(stderr, _("The tag message has been left in %s\n"),
path);
@@ -422,9 +446,10 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct ref_lock *lock;
-
- int annotate = 0, sign = 0, force = 0, lines = -1,
- list = 0, delete = 0, verify = 0;
+ struct create_tag_options opt;
+ char *cleanup_arg = NULL;
+ int annotate = 0, force = 0, lines = -1, list = 0,
+ delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
@@ -442,7 +467,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_CALLBACK('m', "message", &msg, "message",
"tag message", parse_msg_arg),
OPT_FILENAME('F', "file", &msgfile, "read message from file"),
- OPT_BOOLEAN('s', "sign", &sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN('s', "sign", &opt.sign, "annotated and GPG-signed tag"),
+ OPT_STRING(0, "cleanup", &cleanup_arg, "default",
+ "how to strip spaces and #comments from message"),
OPT_STRING('u', "local-user", &keyid, "key-id",
"use another key to sign the tag"),
OPT__FORCE(&force, "replace the tag if exists"),
@@ -459,13 +486,15 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
git_config(git_tag_config, NULL);
+ opt.sign = 0;
+
argc = parse_options(argc, argv, prefix, options, git_tag_usage, 0);
if (keyid) {
- sign = 1;
+ opt.sign = 1;
set_signingkey(keyid);
}
- if (sign)
+ if (opt.sign)
annotate = 1;
if (argc == 0 && !(delete || verify))
list = 1;
@@ -523,9 +552,21 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else if (!force)
die(_("tag '%s' already exists"), tag);
+ opt.message = msg.given || msgfile;
+
+ if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
+ opt.cleanup_mode = !opt.message ? CLEANUP_ALL : CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "verbatim"))
+ opt.cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, "whitespace"))
+ opt.cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "strip"))
+ opt.cleanup_mode = CLEANUP_ALL;
+ else
+ die(_("Invalid cleanup mode %s"), cleanup_arg);
+
if (annotate)
- create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ create_tag(object, tag, &buf, &opt, prev, object);
lock = lock_any_ref_for_update(ref.buf, prev, 0);
if (!lock)
--
1.7.7.3
^ permalink raw reply related
* Help with setting up git server
From: git815 @ 2011-12-04 13:22 UTC (permalink / raw)
To: git
After what I thought I have set up a git server under http, I'm getting this
error on client site whenever I issue a git command: "fatal: Not a git
repository (or any of the parent directories): .git".
Here is what I did:
(1) In project directory, clone a git project: "git clone --bare proj.git"
( I noticed no .git subdirectory exists in the cloned directory).
(2) Move the cloned directory proj.git under web server path.
(3) On a separate client machine, clone a local copy of the project: "git
clone http://git-server/proj.git" (This command runs and gives me the actual
source code files and nothing else. The cloned proj.git directories
contains git files and directories).
I'm new and I must have missed something. Can anyone help? Thanks.
--
View this message in context: http://git.661346.n2.nabble.com/Help-with-setting-up-git-server-tp7060154p7060154.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox