* What's cooking in git.git (Sep 2011, #01; Fri, 2)
From: Junio C Hamano @ 2011-09-02 22:06 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Some of the recent patches are fixes to new feature topics already merged
to "master" and are being fast tracked for 1.7.7-rc1, but otherwise
patches for new features and fixes to longstanding issues will stay in
'pu' or 'next' until the 1.7.7 final.
--------------------------------------------------
[New Topics]
* mh/check-ref-format-print-normalize (2011-08-27) 2 commits
(merged to 'next' on 2011-08-30 at e827410)
+ Forbid DEL characters in reference names
+ check-ref-format --print: Normalize refnames that start with slashes
Will merge to "master".
* bk/ancestry-path (2011-08-25) 3 commits
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
The topic came up a bit too late in the cycle.
Will cook for a while.
* mg/branch-list (2011-08-28) 5 commits
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
Not urgent; the topic came up a bit too late in the cycle.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
Not urgent; the topic came up a bit too late in the cycle.
* jk/default-attr (2011-08-26) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Not urgent; I fixed up the test breakage just for fun.
* hv/submodule-merge-search (2011-08-26) 4 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(this branch uses fg/submodule-auto-push.)
Not urgent; the topic came up a bit too late in the cycle.
The bottom one needs to be replaced with a properly written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
- git-remote-mediawiki: allow push to set MediaWiki metadata
- Add a remote helper to interact with mediawiki (fetch & push)
Fun.
Not urgent; the topic came up a bit too late in the cycle.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
Not urgent; will not be in 1.7.7.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
Not urgent; the topic came up a bit too late in the cycle.
* cb/maint-ls-files-error-report (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at b606e19)
+ t3005: do not assume a particular order of stdout and stderr of git-ls-files
Will merge to "master".
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
Not urgent; the topic came up a bit too late in the cycle.
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
Will cook for a while.
* jn/remote-helpers-doc (2011-09-01) 3 commits
- (short) documentation for the testgit remote helper
- Documentation/git-remote-helpers: explain how import works with multiple refs
- Documentation/remote-helpers: explain capabilities first
Not urgent.
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
Not urgent; the topic came up a bit too late in the cycle.
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
Not urgent; the topic came up a bit too late in the cycle.
* fg/submodule-auto-push (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is used by hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/fetch-verify (2011-09-01) 4 commits
- NEEDSWORK: rev-list --verify-objects: run fsck_objects() on all objects listed
- fetch: verify we have everything we need before updating our ref
- rev-list --verify-object
- list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list.)
Make "git fetch" verify what it received a bit more carefully before
updating the refs in the receiving end.
Not urgent; the topic came up a bit too late in the cycle.
* rc/histogram-diff (2011-08-31) 1 commit
(merged to 'next' on 2011-09-02 at be4d245)
+ xdiff/xprepare: initialise xdlclassifier_t cf in xdl_prepare_env()
Will merge to "master".
--------------------------------------------------
[Graduated to "master"]
* ac/describe-dirty-refresh (2011-08-11) 1 commit
(merged to 'next' on 2011-08-23 at b873611)
+ describe: Refresh the index when run with --dirty
* bc/bisect-test-use-shell-path (2011-08-30) 1 commit
(merged to 'next' on 2011-08-30 at c090151)
+ t6030: use $SHELL_PATH to invoke user's preferred shell instead of bare sh
* bg/t5540-osx-grep (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at 894af05)
+ t5540-http-test: shorten grep pattern
* bw/doc-repo-layout (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 605c730)
+ Mark http-fetch without -a as deprecated
+ Documentation: Grammar correction, wording fixes and cleanup
* ci/forbid-unwanted-current-branch-update (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 1e93b67)
+ Show interpreted branch name in error messages
+ Prevent force-updating of the current branch
* da/difftool-mergtool-refactor (2011-08-19) 4 commits
(merged to 'next' on 2011-08-23 at a1cc3be)
+ mergetools/meld: Use '--output' when available
+ mergetool--lib: Refactor tools into separate files
+ mergetool--lib: Make style consistent with git
+ difftool--helper: Make style consistent with git
* di/fast-import-blob-tweak (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 52eef2a)
+ fast-import: treat cat-blob as a delta base hint for next blob
+ fast-import: count and report # of calls to diff_delta in stats
* di/fast-import-deltified-tree (2011-08-14) 2 commits
(merged to 'next' on 2011-08-23 at ee30265)
+ fast-import: prevent producing bad delta
+ fast-import: add a test for tree delta base corruption
* di/fast-import-doc (2011-08-17) 1 commit
(merged to 'next' on 2011-08-23 at dab4088)
+ doc/fast-import: document feature import-marks-if-exists
* di/fast-import-ident (2011-08-11) 5 commits
(merged to 'next' on 2011-08-23 at 9b86391)
+ fsck: improve committer/author check
+ fsck: add a few committer name tests
+ fast-import: check committer name more strictly
+ fast-import: don't fail on omitted committer name
+ fast-import: add input format tests
* di/fast-import-tagging (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 67e0937)
+ fast-import: allow to tag newly created objects
+ fast-import: add tests for tagging blobs
* di/parse-options-split (2011-08-11) 2 commits
(merged to 'next' on 2011-08-23 at 6cd667f)
+ Reduce parse-options.o dependencies
+ parse-options: export opterr, optbug
* en/merge-recursive-2 (2011-08-14) 57 commits
(merged to 'next' on 2011-08-23 at ba6ad0d)
+ merge-recursive: Don't re-sort a list whose order we depend upon
+ merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest
+ t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify
+ merge-recursive: Avoid unnecessary file rewrites
+ t6022: Additional tests checking for unnecessary updates of files
+ merge-recursive: Fix spurious 'refusing to lose untracked file...' messages
+ t6022: Add testcase for spurious "refusing to lose untracked" messages
+ t3030: fix accidental success in symlink rename
+ merge-recursive: Fix working copy handling for rename/rename/add/add
+ merge-recursive: add handling for rename/rename/add-dest/add-dest
+ merge-recursive: Have conflict_rename_delete reuse modify/delete code
+ merge-recursive: Make modify/delete handling code reusable
+ merge-recursive: Consider modifications in rename/rename(2to1) conflicts
+ merge-recursive: Create function for merging with branchname:file markers
+ merge-recursive: Record more data needed for merging with dual renames
+ merge-recursive: Defer rename/rename(2to1) handling until process_entry
+ merge-recursive: Small cleanups for conflict_rename_rename_1to2
+ merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
+ merge-recursive: Introduce a merge_file convenience function
+ merge-recursive: Fix modify/delete resolution in the recursive case
+ merge-recursive: When we detect we can skip an update, actually skip it
+ merge-recursive: Provide more info in conflict markers with file renames
+ merge-recursive: Cleanup and consolidation of rename_conflict_info
+ merge-recursive: Consolidate process_entry() and process_df_entry()
+ merge-recursive: Improve handling of rename target vs. directory addition
+ merge-recursive: Add comments about handling rename/add-source cases
+ merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
+ merge-recursive: Fix deletion of untracked file in rename/delete conflicts
+ merge-recursive: Split update_stages_and_entry; only update stages at end
+ merge-recursive: Allow make_room_for_path() to remove D/F entries
+ string-list: Add API to remove an item from an unsorted list
+ merge-recursive: Split was_tracked() out of would_lose_untracked()
+ merge-recursive: Save D/F conflict filenames instead of unlinking them
+ merge-recursive: Fix code checking for D/F conflicts still being present
+ merge-recursive: Fix sorting order and directory change assumptions
+ merge-recursive: Fix recursive case with D/F conflict via add/add conflict
+ merge-recursive: Avoid working directory changes during recursive case
+ merge-recursive: Remember to free generated unique path names
+ merge-recursive: Consolidate different update_stages functions
+ merge-recursive: Mark some diff_filespec struct arguments const
+ merge-recursive: Correct a comment
+ merge-recursive: Make BUG message more legible by adding a newline
+ t6022: Add testcase for merging a renamed file with a simple change
+ t6022: New tests checking for unnecessary updates of files
+ t6022: Remove unnecessary untracked files to make test cleaner
+ t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
+ t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
+ t6036: tests for criss-cross merges with various directory/file conflicts
+ t6036: criss-cross with weird content can fool git into clean merge
+ t6036: Add differently resolved modify/delete conflict in criss-cross test
+ t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
+ t6042: Ensure rename/rename conflicts leave index and workdir in sane state
+ t6042: Add tests for content issues with modify/rename/directory conflicts
+ t6042: Add a testcase where undetected rename causes silent file deletion
+ t6042: Add a pair of cases where undetected renames cause issues
+ t6042: Add failing testcase for rename/modify/add-source conflict
+ t6042: Add a testcase where git deletes an untracked file
I've taken advantage of the end-of-summer lull and reproduced all 16000+
two-head merges in the Linux kernel repository with and without this
series to make sure they get the identical results (either cleanly merged,
or getting conflicted the same way).
* fg/submodule-ff-check-before-push (2011-08-20) 2 commits
(merged to 'next' on 2011-08-24 at 398e764)
+ push: Don't push a repository with unpushed submodules
(this branch is used by hv/submodule-merge-search.)
This is only the "check" part, which was sensible. The "auto-push" patch
has been moved to its own topic.
* fk/use-kwset-pickaxe-grep-f (2011-08-28) 6 commits
(merged to 'next' on 2011-08-28 at 3be2039)
+ obstack: Fix portability issues
(merged to 'next' on 2011-08-23 at 93ba509)
+ Use kwset in grep
+ Use kwset in pickaxe
+ Adapt the kwset code to Git
+ Add string search routines from GNU grep
+ Add obstack.[ch] from EGLIBC 2.10
* gb/maint-am-patch-format-error-message (2011-08-29) 1 commit
(merged to 'next' on 2011-08-30 at ed01a1d)
+ am: format is in $patch_format, not parse_patch
* gb/maint-am-stgit-author-to-from-fix (2011-08-29) 1 commit
(merged to 'next' on 2011-08-30 at 0740010)
+ am: fix stgit patch mangling
* jc/clean-exclude-doc (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at 79dd173)
+ Documentation: clarify "git clean -e <pattern>"
* jc/combine-diff-callback (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 9f9b42d)
+ combine-diff: support format_callback
(this branch is used by fg/submodule-ff-check-before-push and hv/submodule-merge-search.)
* jc/maint-autofix-tag-in-head (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at 18cee02)
+ commit: reduce use of redundant global variables
* jc/maint-clone-alternates (2011-08-23) 2 commits
(merged to 'next' on 2011-08-23 at 7280deb)
+ clone: clone from a repository with relative alternates
+ clone: allow more than one --reference
* jc/merge-reword (2011-05-25) 1 commit
(merged to 'next' on 2011-08-24 at aa5cf7b)
+ merge: reword the final message
* jk/color-and-pager (2011-08-19) 10 commits
(merged to 'next' on 2011-08-23 at cbb9495)
+ want_color: automatically fallback to color.ui
+ diff: don't load color config in plumbing
+ config: refactor get_colorbool function
+ color: delay auto-color decision until point of use
+ git_config_colorbool: refactor stdout_is_tty handling
+ diff: refactor COLOR_DIFF from a flag into an int
+ setup_pager: set GIT_PAGER_IN_USE
+ t7006: use test_config helpers
+ test-lib: add helper functions for config
+ t7006: modernize calls to unset
(this branch is used by jk/pager-with-alias and jk/pager-with-external-command.)
* jk/pager-with-external-command (2011-08-19) 1 commit
(merged to 'next' on 2011-08-24 at 083f5da)
+ support pager.* for external commands
(this branch is used by jk/pager-with-alias and jk/pager-with-alias; uses jk/color-and-pager.)
* jn/plug-empty-tree-leak (2011-08-16) 2 commits
(merged to 'next' on 2011-08-23 at aee2184)
+ merge-recursive: take advantage of hardcoded empty tree
+ revert: plug memory leak in "cherry-pick root commit" codepath
* js/i18n-scripts (2011-08-08) 5 commits
(merged to 'next' on 2011-08-23 at a1b5529)
+ submodule: take advantage of gettextln and eval_gettextln.
+ stash: take advantage of eval_gettextln
+ pull: take advantage of eval_gettextln
+ git-am: take advantage of gettextln and eval_gettextln.
+ gettext: add gettextln, eval_gettextln to encode common idiom
* js/i18n-scripts-2 (2011-08-30) 1 commit
(merged to 'next' on 2011-08-30 at 5a144a2)
+ bisect: take advantage of gettextln, eval_gettextln.
* mg/branch-set-upstream-previous (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at acef0b6)
+ branch.c: use the parsed branch name
* mg/maint-notes-C-doc (2011-08-25) 1 commit
(merged to 'next' on 2011-08-30 at 6f3281a)
+ git-notes.txt: clarify -C vs. copy and -F
* mh/attr (2011-08-14) 7 commits
(merged to 'next' on 2011-08-23 at 22faa6e)
+ Unroll the loop over passes
+ Change while loop into for loop
+ Determine the start of the states outside of the pass loop
+ Change parse_attr() to take a pointer to struct attr_state
+ Increment num_attr in parse_attr_line(), not parse_attr()
+ Document struct match_attr
+ Add a file comment
* ms/daemon-timeout-is-in-seconds (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at 2462eb0)
+ git-daemon.txt: specify --timeout in seconds
* nd/decorate-grafts (2011-08-25) 6 commits
(merged to 'next' on 2011-08-25 at 44967e7)
+ log: Do not decorate replacements with --no-replace-objects
(merged to 'next' on 2011-08-23 at 475d27e)
+ log: decorate "replaced" on to replaced commits
+ log: decorate grafted commits with "grafted"
+ Move write_shallow_commits to fetch-pack.c
+ Add for_each_commit_graft() to iterate all grafts
+ decoration: do not mis-decorate refs with same prefix
* nd/maint-clone-gitdir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at cbf052b)
+ clone: allow to clone from .git file
+ read_gitfile_gently(): rename misnamed function to read_gitfile()
* nk/branch-v-abbrev (2011-07-01) 1 commit
(merged to 'next' on 2011-08-24 at e9152cf)
+ branch -v: honor core.abbrev
(this branch is used by mg/branch-list.)
* rc/diff-cleanup-records (2011-08-17) 2 commits
(merged to 'next' on 2011-08-23 at b8414f5)
+ Merge branch 'rc/histogram-diff' into HEAD
+ xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
* tr/maint-format-patch-empty-output (2011-08-29) 4 commits
(merged to 'next' on 2011-08-30 at 078c522)
+ Document negated forms of format-patch --to --cc --add-headers
+ t4014: "no-add-headers" is actually called "no-add-header"
+ t4014: invoke format-patch with --stdout where intended
+ t4014: check for empty files from git format-patch --stdout
* tr/maint-ident-to-git-memmove (2011-08-29) 1 commit
(merged to 'next' on 2011-08-30 at 9395a9b)
+ Use memmove in ident_to_git
* tr/maint-strbuf-grow-nul-termination (2011-08-29) 1 commit
(merged to 'next' on 2011-08-30 at dc87192)
+ strbuf_grow(): maintain nul-termination even for new buffer
* tr/maint-t3903-misquoted-command (2011-08-30) 1 commit
(merged to 'next' on 2011-08-30 at f533857)
+ t3903: fix misquoted rev-parse invocation
* va/p4-branch-import (2011-08-22) 4 commits
(merged to 'next' on 2011-08-24 at f67f8af)
+ git-p4: Add simple test case for branch import
+ git-p4: Allow branch definition with git config
+ git-p4: Allow filtering Perforce branches by user
+ git-p4: Correct branch base depot path detection
(this branch uses va/p4-rename-copy.)
* va/p4-branch-import-test-update (2011-08-29) 1 commit
(merged to 'next' on 2011-08-30 at 5c54fb3)
+ git-p4: simple branch tests edits
* va/p4-rename-copy (2011-08-22) 5 commits
(merged to 'next' on 2011-08-24 at f1faa94)
+ git-p4: Process detectCopiesHarder with --bool
+ git-p4: Add test case for copy detection
+ git-p4: Add test case for rename detection
+ git-p4: Add description of rename/copy detection options
+ git-p4: Allow setting rename/copy detection threshold
(this branch is used by va/p4-branch-import.)
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates, tests, and integration with the higher level
callers, e.g. "git add -p".
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* 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
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify.)
Not urgent; will not be in 1.7.7.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ 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. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
--------------------------------------------------
[Discarded]
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #01; Fri, 2)
From: Junio C Hamano @ 2011-09-02 22:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vbov21tvi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' while commits prefixed with '+' are in 'next'.
>
> Some of the recent patches are fixes to new feature topics already merged
> to "master" and are being fast tracked for 1.7.7-rc1, but otherwise
> patches for new features and fixes to longstanding issues will stay in
> 'pu' or 'next' until the 1.7.7 final.
I pushed the result of this week's intergration out, but not to the k.org
repository. You should be able to fetch from any of the following places
in the meantime:
[remote "repo"]
url = git://repo.or.cz/alt-git.git
[remote "github"]
url = https://github.com/gitster/git
[remote "gph"]
url = https://code.google.com/p/git-core/
[remote "sf.net"]
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
[remote "sfjp"]
url = git://git.sourceforge.jp/gitroot/git-core/git.git
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] fetch: verify we have everything we need before updating our ref
From: Junio C Hamano @ 2011-09-02 23:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <7v8vq7muzi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> What about receive-pack? Does it have the same breakage?
>
> I didn't look---you tell me ;-)
I looked. It needs a similar check, and I'd need to refactor the
check_everything_connected() function a bit to take an iterator.
Will send a follow-up series this weekend.
^ permalink raw reply
* Retrieving logs matching pattern for all time.
From: Jeremy Nickurak @ 2011-09-03 0:03 UTC (permalink / raw)
To: git
I have a glob pattern of files, and I'd like to get git logs for every
commit that touched those files. 'git log filesmatchingglob*' is
pretty close.
Unfortunately, because the * is interpreted by bash, it doesn't catch
logs for files that don't exist anymore.
Protecting the * from bash was my next thought, but that doesn't seem to help:
> user@host:~$ mkdir something
> user@host:~$ cd something
> user@host:~/something$ git init
> Initialized empty Git repository in /home/nickuj/something/.git/
> user@host:~/something$ echo hello > hello.txt
> user@host:~/something$ git add hello.txt
> user@host:~/something$ git commit -m hello hello.txt
> [master (root-commit) ca4b223] hello
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 hello.txt
> user@host:~/something$ git log -- 'hel*'
> user@host:~/something$
IE, git doesn't seem to interpret globs itself in patterns.
http://stackoverflow.com/questions/543346/git-list-all-the-files-that-ever-existed
suggests a means to get a list of all files that ever existed, and I
could certainly iterate across that, find the files that match the
pattern, and then run git-log against that.... but it seems like a
problem somebody's already solved more elegantly.
Any thoughts?
--
Jeremy Nickurak
^ permalink raw reply
* [RFCv2] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-09-03 1:43 UTC (permalink / raw)
To: git
Cc: Ævar Arnfjörð Bjarmason, Phil Hord, Jens Lehmann,
Heiko Voigt
This is last call for feedback (comments) on contents of this year
Git User's Survey.
Thanks to generocity of Survs.com, we have been gifted with premium
annual plan (last year Git User's Survey had more than 8000
responses!). This plan will last till 26 October 2011, so I am
planning on having the survey for 4 weeks, in September:
5 September 2011 -- 2 October 2011
You can see test version of survey at
https://www.survs.com/survey/VEBXFGJ9B0
Note that all answers in this test channel will be deleted!
Below there is the content of the proposed survey.
New questions include:
* List git tools that you use (optional)
* What do you use submodules for?
* Do you use paid git hosting, and if so, why?
* If you self-host git repositories, what tools do you use?
* What other version control systems do you use beside Git?
* What gave you most trouble learning, understanding and using Git?
* Did you give help about Git? What medium did you use?
* What gave you most trouble explaining and teaching Git?
= Git User's Survey 2011 (proposal) =
== About you ==
=== 01. What country do you live in? ===
(Country of residence)
(free-form single line)
NOTES:
^^^^^^
This question originally read "What country are you from?"
=== 02. How old are you (in years)? ===
(Single number)
(free-form single line)
=== 03. Does Git include code or documentation by you? ===
(Are you a Git developer?)
(single choice)
* Yes
* No
NOTES:
^^^^^^
This is here to correlate other responses with Git developers.
== Getting started with Git ==
=== 04. Have you found Git easy to learn? ===
(single choice)
* Very easy
* Easy
* Reasonably easy
* Hard
* Very hard
=== 05. Have you found Git easy to use? ===
(single choice)
* Very easy
* Easy
* Reasonably easy
* Hard
* Very hard
NOTES:
^^^^^^
Those two questions, considered alone, doesn't tell us much. If one use
git, then usually one does not think it is too hard to use (unless forced to
use git by external circumstances, like project he/she works on using git).
On the other hand those two questions together give us some mesaure of git
learning curve, telling us if people consider git easy to use but hard to
learn, or vice versa ;-)
=== 06. Which Git version(s) are you using? ===
(multiple choice, with other)
+ pre 1.3
+ 1.3.x
+ 1.4.x
+ 1.5.x
+ 1.6.x
+ 1.7.x
+ 1.7.x-rcN version (release candidate)
+ minor (maintenance) release 1.x.y.z
+ 'master' branch of official git repository
+ 'next' branch of official git repository
+ 'pu' branch of official git repository
+ version from msysGit / Git for Windows fork repository
+ JGit implementation (e.g. via Eclipse plugin, EGit)
+ other, please specify
Description:
~~~~~~~~~~~~
You can find git version by using `git --version` or `git version`.
"Minor release" is additional specification, so if you for example use
git version 1.7.4.5, please check both "1.7.x" and "minor release"; if
you use "v1.7.6-rc3" please check both "1.7.x" and "-rcN version"
NOTES:
^^^^^^
The "-rcN version" is new option.
=== 07. Rate your own proficiency with Git: ===
(single choice)
* 1. novice
* 2. casual, needs advice
* 3. everyday use
* 4. can offer advice
* 5. know it very well
Description:
~~~~~~~~~~~~
You can think of it as 1-5 numerical grade of your proficiency in Git.
NOTES:
^^^^^^
This question tell us penetration of announcements of Git User's Survey 2011;
did we get to all, or only to git gurus? It is also useful for correlating
with other responses, for example to know which features are used by
novices, and which by gurus.
Note that the answers are here to stay because of "backwards
compatibility", i.e. to be able to easy compare with earlier surveys.
== How you use Git ==
=== 08. I use Git for (check all that apply): ===
(multiple choice, with other)
NOTES:
^^^^^^
Answers to this question probe different direction.
+ work projects
+ unpaid projects
+ proprietary projects
+ OSS development (also public domain, and published & unlicensed)
+ private (unpublished), in house
+ code (programming) and its documentation
+ data, documents (also e.g. static website)
+ sharing data or sync
+ managing configuration files
+ backup
+ backend for wiki, blog, or other web app
+ bugtracker / issue tracker
+ frontend to other SCM (e.g. git-svn)
+ other (please specify)
Description:
~~~~~~~~~~~~
Note that above choices are neither orthogonal nor exclusive.
You might want to check multiple answers even for a single repository.
=== 09. How do/did you obtain Git (install and/or upgrade)? ===
(multiple choice, with other)
Note that this question is multiple choices question because one can
install Git in different ways on different machines or on different
operating systems.
+ binary package
+ source package or script (automatic compiling)
+ source tarball (extract, make, make install)
+ pull from (main) repository
+ preinstalled / sysadmin job
+ other - please specify (if none of the above apply)
Description:
~~~~~~~~~~~~
Explanation: "binary package" covers pre-compiled binary (e.g. from
rpm or deb binary packages); "source package" covers things like
deb-src and SRPMS / *.src.rpm; "source script" is meant to cover
installation in source-based distributions, like 'emerge' in Gentoo.
Automatic update (apt, yum, etc.) in most cases means binary package
install; unless one uses source-based distribution like Gentoo, CRUX,
or SourceMage, where automatic update means using source package (or
source script).
The option named "preinstalled / sysadmin job" means that either you
didn't need to install git because it was preinstalled (and you didn't
upgrade); or that you have to ask system administrator to have git
installed or upgraded.
Note that this question is multiple choices question because one can
install Git in different ways on different machines or on different
operating systems.
NOTES:
^^^^^^
What I didn't take into account in above explanation is operating
systems with packaging systems different that the one used by various
Linux distributions.
In short: if to have git installed you compile it, you use source
package or source tarball. If the installation onvolves anything more
than 'make install' (or manual copying), then it is most probably
source package or script.
This for example means that "msysGit" installer is source package, and
"Git for Windows" is binary package, if I understand it correctly.
=== 10. On which operating system(s) do you use Git? ===
(multiple choice, with other)
+ GNU/Linux (includes MeeGo)
+ MacOS X (Darwin)
+ MS Windows/msysGit (MINGW)
+ MS Windows/Cygwin
+ some MS Windows (unknown or other)
+ FreeBSD, OpenBSD, NetBSD, etc.
+ Solaris / OpenSolaris / Illuminati / IllumOS
+ other Unix
+ Other, please specify
Description:
~~~~~~~~~~~~
On Unix-based operating system you can get the name of operation
system by running `uname` (or `uname -o`).
NOTES:
^^^^^^
How to detect if it is msysGit or Cygwin from within? Perhaps we
should have just "MS Windows"...
=== 11. What Git interfaces, implementations and frontends do you use? ===
(multiple choice, with other)
+ JGit (Java implementation), e.g. via Eclipse plugin
+ NGit or Git# (C# implementation)
+ Dulwich (pure-Python implementation)
+ Git::PurePerl (Perl implementation)
+ git.js (JavaScript)
+ libgit2 bindings
+ git (core) commandline
? Cogito (DEPRECATED)
+ Easy Git
+ Pyrite
+ I don't know, I only use (graphical) tools
? pg aka Patchy Git (DEPRECATED)
+ StGIT
+ Guilt
+ TopGit
+ Zit
+ other (please specify)
NOTES:
^^^^^^
This version is going back to split from 2008 survey, rather than
having everything put together like in 2009 one. There are, of
course, problems with both choices.
The problem with split part is that people can have troubls with
distinguising between interfaces, implementations, frontends and tools
(although "I don't know ..." answer should, I think, help here). The
problem with having it everything together is that the list of
possible answers gets long and a bit unwieldy.
BTW are there any implementations and frontends that should be added
to the list above?
=== 12. What kind of Git tools do you use? ===
(multiple choice, with other)
If a tool is both history viewer, and commit tool, please choose the
option that corresponds to how do you use this tool.
+ editor/IDE VC integration (e.g. EGit (for Eclipse), TextMate bundle, magit (for GNU Emacs))
+ build tool integration (e.g. git plugin for Maven, gitbuilder, Parabuild)
+ filemanager / shell extension (e.g. git-cheetah, TortoiseGit)
+ filesystem interface (e.g. gitfs, figfs)
+ graphical history viewer/browser (e.g. gitk)
+ graphical commit tool (e.g. git-gui)
+ graphical diff and/or merge tool (e.g. Kompare, Meld)
+ graphical blame or pickaxe tool (e.g. 'git gui blame')
+ tool to manage git repositories (e.g. Gitosis, Gitolite)
+ git-instaweb, or self-hosted web interface (e.g. gitweb, cgit)
+ self-hosted code review system (e.g. Gerrit)
+ self-hosted git software forge (e.g. Gitorious, GitHub:FI, InDefero)
+ patch management interface (e.g. StGit, Guilt)
+ tracking some files out-of-band (e.g. git-annex, git-media)
+ storing metadata (e.g. metastore, gitperms, git-cache-meta)
+ managing composite repositories (e.g. git-subtree, gitslave, repo)
+ my own scripts (for daily use)
+ my own scripts (for special tasks)
+ other kind (please specify)
Description:
~~~~~~~~~~~~
Here graphics diff tool means tools such as Kompare, and graphical
merge tool means tools such as Meld and KDiff3. Those answers include
graphical merge and diff tools used by programmers editors and IDEs.
"graphical history browser (any)" covers tools such as gitk, QGit,
Giggle, tig etc., but also built-in git commands such as "git log
--graph" and "git show-branch". If you use one of mentioned tools
*as* history browser, mark both a tool and "graphical history
browser (any)"; if you use some graphical history viewer not listed
here, please both mark this answer and specify it in the "other tool"
answer.
Similarly for other answers marked "(any)".
=== 13. List git tools that you use (optional) ===
(free form, essay)
Description:
~~~~~~~~~~~~
Please include only frontends, interfaces and tools that have support
for Git (so e.g. EGit applies, but Eclipse doesn't).
Please either use comma separated list of tools, or put each tool in a
separate line. That would make analysis of answers simpler. Thanks
in advance.
NOTES:
^^^^^^
Replaced list of tools from 2009 with free-form question.
=== 14. What do you use submodules for? ===
(multiple choice, with other)
+ I don't use submodules at all
+ I use submodules
+ I use repo
+ I use git-subtree
+ I use gitslave
+ to import repositories maintained by others
+ for your own (or your organization's) code shared between different projects
+ to separate large and/or many files for performance reasons
+ to separate data which you don't want (or aren't allowed) to disclose
+ Other, please specify
NOTES:
^^^^^^
New. Requested by Jens Lehmann.
=== 15. Which of the following Git features do you use? ===
(multiple choice, with other)
+ git bundle (off-line transport)
+ eol conversion (crlf or eol)
+ gitattributes (any)
+ custom diff/merge driver
+ word diff
+ merge strategy options (e.g. -Xrenormalize)
+ textconv
+ submodules (subprojects)
+ subtree merge (optionally git-subtree)
+ partial (sparse) checkout,
+ assume-unchanged bit
+ separate worktree / core.worktree
+ multiple worktrees (e.g. git-new-worktree)
+ gitdir mechanism (.git file pointing to repository)
+ remote helpers (e.g. <transport>::<address> URLs)
+ alternates mechanism (sharing object database)
+ stash (optionally "git stash --keep-index")
+ shallow clone (e.g. "git clone --depth=<n>")
+ detaching HEAD (e.g. "git checkout --detach")
+ commit message templates
+ interactive commit / per-hunk comitting / partial commit
+ interactive rebase (small scale history editing)
+ git-filter-branch or equivalent (large history rewriting)
+ bisect (optionally "git bisect run <script>")
+ tracking code movement with git-blame ("git blame -M" etc.)
+ advanced history examination (pickaxe search, ancestor only, etc.)
+ committing with dirty tree (keeping some changes uncommitted)
+ non-default hooks (from contrib/hooks/ or other)
+ shell completion of commands
+ git-aware shell prompt
+ git aliases, shell aliases for git, or own git scripts
+ one-way interaction with other SCMs (from SCM to git)
+ two-way interaction with other SCMs (from SCM to git, from git to SCM)
+ git-cvsserver
+ git notes
+ replace meachanism (git replace)
+ grafts (not only as a way to do filter-branch)
+ Other, please specify
NOTES:
^^^^^^
The problem is come up not with exhaustive list of features: there are
too many of them to list. The problem is coming up with list of
important and used enough often features.
So: what features should be included in this list? What features
should be removed from above list of answers?
=== 16. Which of the following features would you like to see implemented in git? ===
(multiple choice)
+ localization of command-line messages (i18n)
+ better support for big files (large media)
+ resumable clone/fetch (and other remote operations)
+ GitTorrent Protocol, or git-mirror
+ lazy clone / on-demand fetching of object
+ support for tracking empty directories
+ improved submodule support (and user-interface)
+ environmental variables in config
+ better undo/abort/continue, and for more commands
+ '-n' like option for each command, which describes what would happen
+ side-by-side diffs and/or color-words diff in gitweb
+ admin and/or write features in gitweb
+ graphical history view in gitweb
+ GUI for rebase in git-gui
+ GUI for creating repository in git-gui
+ filename encoding (in repository vs in filesystem)
+ git push --create
+ wholesame directory rename detection
+ graphical merge tool integrated with git-gui
+ union checkouts (some files from one branch, some from other)
+ advisory locking / "this file is being edited"
+ "commands issued" (or "command equivalents") in git-gui / gitk
+ warn before/when rewriting published history
+ built-in gitjour/bananajour support
+ syntax highlighting in git-gui
+ other (describe below)
NOTES:
^^^^^^
What features should be mentioned besides those above? What criteria
should we have for including features in this list?
=== 17. Describe what features would you like to have in Git, if it is
not on the list above? ===
(free form, essay length)
== Interacting with other repositories ==
=== 18. Which git hosting site(s) do you use for your project(s)? ===
Please check only hosting sites where you publish/push to (with git)
(multiple choice, with other)
+ [http://repo.or.cz repo.or.cz]
+ [http://github.com GitHub]
+ [http://gitorious.org Gitorious]
+ [http://code.google.com/hosting Google Code]
+ [http://www.indefero.net InDefero]
+ [http://savannah.gnu.org Savannah]
+ [http://sourceforge.net SourceForge]
+ [http://developer.berlios.de BerliOS]
+ [http://www.assembla.com Assembla]
+ [http://codebasehq.com Codebase]
+ [http://unfuddle.com Unfuddle]
- [http://codesion.com Codesion]
- [http://gitfarm.appspot.com GitFarm]
- [http://www.projectlocker.com ProjectLocker]
- [http://thechaw.com The Chaw]
+ [http://git.kernel.org kernel.org]
+ [http://www.freedesktop.org/wiki/ freedesktop.org]
+ [http://alioth.debian.org Alioth] (Debian)
+ [http://hosted.fedoraproject.org Fedora Hosted]
+ company internal
+ git hosting site for related projects (e.g. OLPC)
+ generic site without git support
+ self hosted
+ Other (please specify)
Description:
~~~~~~~~~~~~
You can find those and other git hosting sites listed on GitHosting
page on Git Wiki.
NOTES:
^^^^^^
I think this question is here to stay.
Google Code is new; they support Git only recently. The "company
internal" answer was added in survey from 2010.
=== 19. Do you use paid git hosting, and if so, why? ===
(multiple choice, with other)
+ N/A (don't use paid git hosting)
+ private repositories
+ increased limits
+ paid support / help
+ extra features
+ other (please specify)
NOTES:
^^^^^^
New.
=== 20. If you self-host git repositories, what tools do you use? ===
(multiple choice, with other)
+ gitosis
+ gitolite
+ Gitblit
+ SCM Manager
+ gitweb
+ cgit
+ Gitalist
+ ViewGit
+ GitHub:FI
+ Gitorious
+ InDefero
+ Girocco
+ repo
+ Gerrit
+ other management / collaboration git tool
NOTES:
^^^^^^
New.
=== 21. How do you fetch/get changes from upstream repositories? ===
(multiple choice, with other)
+ git protocol (e.g. git://git.example.com/repo.git)
+ ssh (e.g. ssh+git://git.example.com/repo.git,
git.example.com:/srv/scm/repo.git)
+ http (e.g. http://git.example.com/repo.git)
+ rsync (DEPRECATED) (e.g. rsync://git.example.com/repo.git)
+ filesystem (e.g. /path/to/repo.git, file:///path/to/repo.git)
+ via git-bundle
+ foreign SCM (e.g. git-svn)
+ Other, please specify
Description:
~~~~~~~~~~~~
This question asks about how do you get changes (updates) from
projects you follow into your local repository. It is not about how do
you get latest version of Git.
Fetching (or rather cloning) via bundle could mean that project
publishes ready for download bundles to reduce traffic and load on
server (HTTP download [of bundle] can be resumed, git-clone currently
cannot; one can also distribute bundle using P2P).
NOTES:
^^^^^^
What is new are examples of URLs / URIs for each protocol.
Did I miss anything? Is this question interesting, and should it
stay, or should it be removed?
=== 22. How do you publish/propagate your changes? ===
(multiple choice, with other)
+ push via SSH
+ push via HTTP / HTTPS
+ push via git protocol
+ push (unknown)
+ pull request (+ any form of announcement / notification)
+ format-patch + email
+ format-patch + other (e.g. reviewboard, issue tracker or forum)
+ git bundle
+ git-svn (to Subversion repository)
+ git-p4 (to Perforce repository)
+ foreign SCM interface (other than mentioned above)
+ other - please specify
Description:
~~~~~~~~~~~~
Publishing via bundle could mean sending bundle via email, or posting
it on review board (or forum).
Instead of git-format-patch there can be utilized other way of
generating patch (e.g. git-show, git-diff, 'patch' view from gitweb,
etc.)
NOTES:
^^^^^^
Splitting push into transports is new in this survey.
== Other version control systems ==
=== 23. What other version control systems do you use beside Git? ===
(multiple choice, with other)
+ PVCS
+ SCCS
+ RCS
+ CVS
+ Subversion
+ Perforce
+ ClearCase
+ AccuRev SCM
+ StarTeam
+ Visual SourceSafe
+ Team Foundation Server
+ Visual Studio Team System / ALM
+ Rational Team Concert
+ Bazaar
+ Mercurial
+ Monotone
+ Darcs
+ SVK
+ Fossil
+ Veracity
+ BitKeeper
+ Code Co-op
+ TeamWare
+ Plastic SCM
+ by hand / own scripts / custom
+ other, please specify
NOTES:
^^^^^^
What SCM should be removed, which should be added?
== What you think of Git ==
=== 24. Overall, how happy are you with Git? ===
(single choice)
* unhappy
* not so happy
* happy
* very happy
* completely ecstatic
NOTES:
^^^^^^
There is a problem, that the current wording is considered biased
by some, but on the other hand changing wording of answers would make
it impossible to compare it to answers from previous surveys...
=== 25. In your opinion, which areas in Git need improvement? ===
Please state your preference.
(matrix)
Columns: don't know / don't need / a little / some / much
+ user-interface
+ documentation
+ performance
+ portability
+ more features
+ tools (e.g. GUI)
+ localization (translation)
NOTES:
^^^^^^
Are there any general areas that are missing from this list?
What are they?
== Changes in Git (since year ago, or since you started using it) ==
=== 26. Did you participate in previous Git User's Surveys? ===
(multiple choice)
+ in 2006
+ in 2007
+ in 2008
+ in 2009
+ in 2010
+ I don't remember, but I have participated in the past
+ none of the above (this is my first Git User's Survey)
NOTES:
^^^^^^
This might be quite useful comparing with previous surveys.
=== 27. How do you compare the current Git version with the version from one year ago? ===
(single choice)
* better
* no changes
* worse
* cannot say
Description:
~~~~~~~~~~~~
The version from approximately one year ago is 1.7.2 from 21-07-2011
(1.7.3 is from 18-09-2010).
Changes since 1.7.2 include:
* passing extra options to merge strategy via "-X" in more places
* -Xrename-threshold and -Xignore-space-at-eol
for recursive merge strategy
* "exec" instruction support in interactive rebase
* system-wide attributes file /etc/gitattributes and
`core.attributesfile`
* completion of commands for bash 4 and zsh
* [<tree>]:./<path> to use path relative to current directory
* ":/<path>" to use path relative to root of working tree hierarchy
* ":/" magic pathspec to work on entire working tree
* "git log -G"
* globbing pathspecs in "git log"
* git log --cherry and --cherry-mark
* "git notes merge" and --notes option to "git log" and friends
* extending "git shell" with custom set of commands
* beginnings of i18n/l10n and translations
* "git checkout --detach"
* "git cherry-pick" and "git revert" improvements
* "git merge" and "git rebase" now DWIMs to upstream
* "git merge -" to merge the previous branch
* `merge.ff` configuration variable
* selecting common timezone in gitweb with JavaScript
* updated (faster and more robust) content tags (labels) in gitweb
* GIT_PREFIX in "[alias] <name> = !process"
* git diff --dirstat=0 and --dirstat=lines
* and more...
NOTES:
^^^^^^
This question is mainly excuse for providing list of main changes
from the year ago.
== Documentation. Getting help. ==
=== 28. How useful have you found the following forms of Git documentation? ===
(matrix)
Columns: never used / not useful / somewhat / useful
+ Git Wiki
+ Git Reference site
+ other on-line help
+ help distributed with git
+ printed books (or ebooks)
Description:
~~~~~~~~~~~~
* Git Wiki was to be found at http://git.wiki.kernel.org
* Git Reference site can be found at http://gitref.org
* on-line help includes, among others, Git Homepage (http://git-scm.com),
"Git Community Book" (http://book.git-scm.com), "Pro Git" book
(http://progit.org) and Git-related help pages on git hosting sites
* help distributed with git include manpages, manual, tutorials, HOWTO,
release notes, technical documentation, contrib/examples/
=== 29. What channel(s) do you use to request help about Git (if any)? ===
(multiple choice, with other)
+ N/A (didn't request help about Git)
+ git mailing list (git@vger.kernel.org)
+ "Git for Human Beings" Google Group
+ msysGit mailing list / Google Group
+ IRC (#git)
+ IRC (other git/SCM related, e.g. #github)
+ IRC (other than above)
+ request in blog post or on wiki
+ asking git guru/colleague/friend
+ project mailing list, or IRC, or forum
+ Twitter or other microblogging platform
+ instant messaging (IM) like XMPP/Jabber
+ StackOverflow or other StackExchange site
+ other (please specify)
=== 30. What gave you most trouble learning, understanding and using Git? ===
(free form, essay)
NOTES:
^^^^^^
New / resurrected.
=== 31. Which communication channel(s) do you use? ===
Do you read the mailing list, or watch IRC channel?
(multiple choice, with other)
+ git@vger.kernel.org (main)
+ Git for Human Beings (Google Group)
+ msysGit
+ #git IRC channel
+ #git-devel IRC channel
+ #github or #gitorious IRC channel
+ #revctrl IRC channel
+ other (please specify)
=== 32. Did you give help about Git? What medium did you use? ===
(multiple choice, with other)
+ N/A (didn't give help about Git)
+ talk / private explanation
+ IRC channel
+ talk / presentation / seminar
+ workshop or other form of schooling / training
+ blog post / webpage
+ article in magazine
+ book or ebook
+ git mailing list
+ other mailing list
+ email
+ Usenet (newsgroup)
+ instant messaging (IM) like XMPP/Jabber
+ forum
+ StackOverflow or similar
+ remote aid / control tool, like FogCreek Copilot
+ other, please specify
=== 33. What gave you most trouble explaining and teaching Git? ===
(free-form, essay)
== About this survey. Open forum. ==
=== 34. How did you hear about this Git User's Survey? ===
(single choice, with other)
* git mailing list
* git-related mailing list (e.g. msysGit, Git for Human Beings)
* mailing list or forum of some project
* #git IRC channel topic
* announcement on IRC channel
* git homepage
* git wiki
* git hosting site (or blog related to such site)
* software-related web site
* news or social news site (e.g. Digg, Reddit)
* blog (or blog planet)
* other kind of web site
* Twitter or other microblogging platform
* other - please specify
NOTES:
^^^^^^
This list would of course be updated to reflect the list of (planned)
announcement channels.
There of course will be announcement on Git Mailing List, and perhaps
also on msysGit list / Google Group, and on Git For Human Beings
Google Group (if it exists). I'll announce it on #git, and ask op to
put short announcement in channel description, and I can announce it
on other IRC channels. I would add announcement to main page of Git
Wiki, and as Git Homepage administrator to put announcement about Git
User's Survey.
I usually tried to contact administrators of git hosting sites,
including git.kernel.org, repo.or.cz, GitHub, Gitorious, Assembla,
Codebase and Unfuddle, asking them to put announcement about
Git User's Survey either somewhere on the site, or in their blog
(if there is any). What git hosting sites it is worth to ask?
I would like to have announcement of Git User's Survey 2010 at
LWN.net, but this would need to be send at least two weeks in advance,
if I remember correctly. Is it worth it? What other news site should
I (or you) send announcement to?
If you can Digg / Reddit announcment on some site, please do. I can
announce Git User's Survey 2-1- at Twitter, Identi.ca and Plurk, but I
don't have wide area of followers. So please RT.
Should we contact some bloggers (besides asking Junio to put
announcement on his blog) to post an anouncement? Which bloggers
would respond positively (perhaps Linus...)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [BUG] git-svn: --no-metadata related bug
From: DaveAbrahams @ 2011-09-03 7:01 UTC (permalink / raw)
To: git
In-Reply-To: <20110406181234.GB667@kytes>
I am reproducing the problem here. Unfortunately I can't share the
repository with you but I'm willing to try debugging it a bit.
--
View this message in context: http://git.661346.n2.nabble.com/BUG-git-svn-no-metadata-related-bug-tp6243475p6756044.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: David Aguilar @ 2011-09-03 8:45 UTC (permalink / raw)
To: Phil Hord, Jakub Narebski; +Cc: git
In-Reply-To: <4E2DE708.8050805@cisco.com>
On Mon, Jul 25, 2011 at 05:58:32PM -0400, Phil Hord wrote:
> On 07/25/2011 04:33 PM, Jakub Narebski wrote:
> > === 11. What Git interfaces, implementations and frontends do you use? ===
> > (multiple choice, with other)
> >
> > + JGit (Java implementation), e.g. via Eclipse plugin
> > + NGit or Git# (C# implementation)
> > + Dulwich (pure-Python implementation)
> > + Git::PurePerl (Perl implementation)
> > + git.js (JavaScript)
> > + libgit2 bindings
> >
> > + git (core) commandline
> > + Cogito (DEPRECATED)
> > + Easy Git
> > + Pyrite
> > + I don't know, I only use (graphical) tools
> >
> > + pg aka Patchy Git (DEPRECATED)
> > + StGIT
> > + Guilt
> > + TopGit
> >
> > + Zit
> >
> > + other (please specify)
>
> You can probably drop pg and Cogito now, yes?
I would drop Pyrite too. The last activity was in 2008 and it
never went beyond pre-alpha.
> Looking at the 2010 results, I would add these GUIs to the main list:
> git-gui (core)
> gitk (core)
> gitX
> gitg
> git-cola
> TortoiseGit
> SmartGit
> Git Extensions
> Giggle
This is a better list ;-)
--
David
^ permalink raw reply
* Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo
From: Eric Wong @ 2011-09-03 8:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Bryan Jacobs, git
In-Reply-To: <4E614AE7.7090706@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> On 9/2/11 12:42 PM, Bryan Jacobs wrote:
> >On Fri, 02 Sep 2011 12:01:09 -0700
> >Sam Vilain<sam@vilain.net> wrote:
> >
> >>That's one way to do it; in fact, if the trees match you don't need
> >>to do anything complicated like cherry-pick.
> >>
> >>ie, say you're committing
> >>
> >> r1---A---B---C---D
> >>
> >>and it blows up at
> >>
> >> r1--r2--r3--C---D
> >>
> >>So long as the tree from the fetched r3 == the tree from B, then you
> >>can just go ahead and write out new commits for C and D without doing
> >>any merging (ie cherry-pick or rebase). You could also put merge
> >>commits back the way they were, too.
> >When you say "write out new commits" you mean create a commit object
> >with the same contents, but a different parent? Does git-svn do this
> >somewhere already?
>
> I guess it doesn't, but if it did it would certainly make this
> easier. I'm not sure why it would need to modify the WC at all.
> Eric, is this just historical or is there a better reason for that?
dcommit needs to continually rebase because it's possible somebody else
may make a commit to the SVN repo while a git-svn user is dcommiting
and cause a conflict the user would need to resolve in the working tree.
At least I think that was the reason... There is also the "commit-diff"
command in git-svn. It was the precursor to dcommit which requires no
changes to the working tree.
--
Eric Wong
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-09-03 9:00 UTC (permalink / raw)
To: David Aguilar; +Cc: Phil Hord, git
In-Reply-To: <20110903084530.GA20905@gmail.com>
On Sat, 3 Sep 2011, David Aguilar wrote:
> On Mon, Jul 25, 2011 at 05:58:32PM -0400, Phil Hord wrote:
> > On 07/25/2011 04:33 PM, Jakub Narebski wrote:
> > > === 11. What Git interfaces, implementations and frontends do you use? ===
> > > (multiple choice, with other)
[...]
> > Looking at the 2010 results, I would add these GUIs to the main list:
> > git-gui (core)
> > gitk (core)
> > gitX
> > gitg
> > git-cola
> > TortoiseGit
> > SmartGit
> > Git Extensions
> > Giggle
>
> This is a better list ;-)
Because of huge number of Git GUIs and tools instead of providing a long
list of tools to choose from, I went for free-form question:
=== 13. List git tools that you use (optional) ===
(free form, essay)
Description:
~~~~~~~~~~~~
Please include only frontends, interfaces and tools that have support
for Git (so e.g. EGit applies, but Eclipse doesn't).
Please either use comma separated list of tools, or put each tool in a
separate line. That would make analysis of answers simpler. Thanks
in advance.
Even though it is free-form question, it shouldn't be hard to analyse,
though it wouldn't be completely automatical.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] completion: fix completion after 'git --option <TAB>'
From: SZEDER Gábor @ 2011-09-03 10:32 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: git, SZEDER Gábor
Git's bash completion currently doesn't work when certain git options
are specified, e.g. 'git --no-pager <TAB>' errors out with "error:
invalid key: alias.--no-pager".
The main _git() completion function finds out the git command name by
looping through all the words on the command line and searching for
the first word that is not a known option for the git command.
Unfortunately the list of known git options was not updated in a long
time, and newer options are not skipped but mistaken for a git
command. Such a misrecognized "command" is then passed to
__git_aliased_command(), which in turn passes it to a 'git config'
query, hence the error.
Currently the following options are misrecognized for a git command:
-c --no-pager --exec-path --html-path --man-path --info-path
--no-replace-objects --work-tree= --namespace=
To fix this we could just update the list of options to be skipped,
but the same issue will likely arise, if the git command learns a new
option in the future. Therefore, to make it more future proof against
new options, this patch changes that loop to skip all option-looking
words, i.e. words starting with a dash.
We also have to handle the '-c' option specially, because it takes a
configutation parameter in a separate word, which must be skipped,
too.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8648a36..8b0c695 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2622,8 +2622,9 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|-p|--paginate) ;;
--help) command="help"; break ;;
+ -c) c=$((++c)) ;;
+ -*) ;;
*) command="$i"; break ;;
esac
c=$((++c))
--
1.7.6.596.gedbca
^ permalink raw reply related
* Re: [PATCH] git-remote-helpers.txt: explain how import works with multiple refs
From: Matthieu Moy @ 2011-09-03 10:35 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, gitster, Sverre Rabbelier, Jeff King, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <20110901231734.GA21945@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> + is followed by a blank line). For example, the following would
>> + be two batches of 'push', the first asking the remote-helper
>> + to push the local ref 'master' to the remote ref 'master' and
>> + the local 'HEAD' to the remote 'branch', and the second
>> + asking to push ref 'foo' to ref 'bar' (forced update requested
>> + by the '+').
>> ++
>> +------------
>> +push refs/heads/master:refs/heads/master
>> +push HEAD:refs/heads/branch
>> +\n
>> +push +refs/heads/foo:refs/heads/bar
>> +\n
>> +------------
>
> Probably examples like this could go in a later EXAMPLES section.
I think having a few examples within the explanations helps the reader
visualize what commands look like, and understand better further
explanations.
Plus, the example explains quickly the + which isn't documented
otherwise (but people reading this probably already know what a refspec
is and what the + normally means in this context so it's probably
sufficient to explain it as a side remark in an example)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [BUG] git push --quiet fails with older versions
From: Tobias Ulmer @ 2011-09-03 10:57 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher
Hi guys,
my distro updated git to 1.7.6.1. Now git push --quiet, used in various
scripts, blows up against 1.7.6. I don't know how backwards compatible
git tries to be, but in my opinion that seems like a regression for a
patchlevel release.
The problem seems to be that the remote git receive-pack does not
understand --quiet. Maybe it is possible to check for the remote version
before sending incompatible commandline parameters?
Quick demo:
lead:ssh$ git version
git version 1.7.6.1
lead:ssh$ git push
Everything up-to-date
lead:ssh$ git push -q
usage: git receive-pack <git-dir>
fatal: The remote end hung up unexpectedly
The remote uses:
radon:~$ git version
git version 1.7.6
Please keep me in CC, I'm not subscribed.
Tobias
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Felipe Contreras @ 2011-09-03 12:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201107252233.02088.jnareb@gmail.com>
2011/7/25 Jakub Narebski <jnareb@gmail.com>:
> I am planning doing annual Git User's Survey, and I'd like to ask for
> feedback.
Do you have an updated version somewhere?
--
Felipe Contreras
^ permalink raw reply
* Re: Special characters in file name
From: Jonathan Nieder @ 2011-09-03 14:46 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Tajti Ákos
In-Reply-To: <loom.20110902T143646-347@post.gmane.org>
Hi Alexey,
Alexey Shumkin wrote:
> Tajti Ákos writes:
>> I have a file named "árvíz.txt" in my repository. When modify that file
>> and execute git diff, the first line looks like this:
>> diff --git "a/\303\241rv\303\255z.txt" "b/\303\241rv\303\255z.txt"
>>
>> Is there an option that (if specified) will get git to print "árvíz.txt"
>> instead of this escaped string?
[...]
> please, refresh your memory )))
> http://comments.gmane.org/gmane.comp.version-control.git/177849
>
> see my comment
> http://permalink.gmane.org/gmane.comp.version-control.git/177857
Cc-ing Ákos so he can actually get your message this time. :) (FWIW
the convention on this list is always to reply-to-all.)
Thanks,
Jonathan
^ permalink raw reply
* [PATCHv2 3/2] remote rename: warn when refspec was not updated
From: Martin von Zweigbergk @ 2011-09-03 15:26 UTC (permalink / raw)
To: git, Jeff King; +Cc: Junio C Hamano, Martin von Zweigbergk
In-Reply-To: <20110902160333.GB19690@sigill.intra.peff.net>
When renaming a remote, we also try to update the fetch refspec
accordingly, but only if it has the default format. For others, such
as refs/heads/master:refs/heads/origin, we are conservative and leave
it untouched. Let's give the user a warning about refspecs that are
not updated, so he can manually update the config if necessary.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
This addresses the first part of your email. I'm not sure what should
happen when only some refspecs can be updated. I can't think of any
sensible examples with mixed default and non-default refspecs, so for
me it's hard to see whether we would make things better or worse by
making it all-or-nothing. I have more or less always used the default
ones myself. Do you have any good examples?
builtin/remote.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 0df6ab0..61326cb 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -672,6 +672,12 @@ static int mv(int argc, const char **argv)
ptr-buf2.buf + strlen(":refs/remotes/"),
strlen(rename.old), rename.new,
strlen(rename.new));
+ else
+ warning("Not updating non-default fetch respec\n"
+ "\t%s\n"
+ "\tPlease update the configuration manually if necessary.",
+ buf2.buf);
+
if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
return error("Could not append '%s'", buf.buf);
}
--
1.7.6.51.g07e0e
^ permalink raw reply related
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-09-03 15:38 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s0N6pCUe_nop66yTwWitP6LhJXsnaVNwYH46OaxRbdVKg@mail.gmail.com>
On Sat, 3 Sep 2011, Felipe Contreras wrote:
> 2011/7/25 Jakub Narebski <jnareb@gmail.com>:
> > I am planning doing annual Git User's Survey, and I'd like to ask for
> > feedback.
>
> Do you have an updated version somewhere?
You can preview test version of survey at
https://www.survs.com/survey/VEBXFGJ9B0
Note that all answers in this test channel will be deleted!
Up to date version was sent to git mailing list as
[RFCv2] Questions for "Git User's Survey 2011"
http://article.gmane.org/gmane.comp.version-control.git/180643
and can be found on Git Wiki:
http://git.wiki.kernel.org/index.php/GitSurvey2011
P.S. If I remember correctly you wanted some question about "staging area"
terminology, or something like that. Do you have concrete proposal for
question and list of answers?
I was thinking about
xx. How do you include changes in new commit?
(multiple choice, with other)
[ ] commit -a
[ ] commit <file>
[ ] commit -i <file>
[ ] git add
[ ] git stage
[ ] git update-index
[ ] incremental add / commit
[ ] other, please specify __________________________
(it is not in current version of survey, but can be added before it starts
for real)... though it is only small subset of "stage" vs "the index"
terminology. If you have something better...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [BUG] git push --quiet fails with older versions
From: Clemens Buchacher @ 2011-09-03 16:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, tobiasu
In-Reply-To: <20110903105723.GA16304@tin.tmux.org>
Hello Tobias,
On Sat, Sep 03, 2011 at 12:57:23PM +0200, Tobias Ulmer wrote:
>
> my distro updated git to 1.7.6.1. Now git push --quiet, used in various
> scripts, blows up against 1.7.6. I don't know how backwards compatible
> git tries to be, but in my opinion that seems like a regression for a
> patchlevel release.
Yes, that's a good point. I did not consider that.
> The problem seems to be that the remote git receive-pack does not
> understand --quiet. Maybe it is possible to check for the remote version
> before sending incompatible commandline parameters?
Indeed, that's what we must do. I am sending three patches in reply
to this email:
[PATCH 1/3] tests for push --quiet
[PATCH 2/3] fix push --quiet via http
[PATCH 3/3] push: old receive-pack does not understand --quiet
The third one fixes this issue on the client side. It does not
depend on the first two. It applies to v1.7.6.1, maint, and master.
Would be great if you could test.
Thanks,
Clemens
^ permalink raw reply
* [PATCH 1/3] tests for push --quiet
From: Clemens Buchacher @ 2011-09-03 16:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, tobiasu, Clemens Buchacher
In-Reply-To: <1315067656-2846-1-git-send-email-drizzd@aon.at>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
t/t5523-push-upstream.sh | 7 +++++++
t/t5541-http-push.sh | 8 ++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
index c229fe6..9ee52cf 100755
--- a/t/t5523-push-upstream.sh
+++ b/t/t5523-push-upstream.sh
@@ -108,4 +108,11 @@ test_expect_failure TTY 'push --no-progress suppresses progress' '
! grep "Writing objects" err
'
+test_expect_success TTY 'quiet push' '
+ ensure_fresh_upstream &&
+
+ test_terminal git push --quiet --no-progress upstream master 2>&1 | tee output &&
+ test_cmp /dev/null output
+'
+
test_done
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index a73c826..0dcb8df 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -5,6 +5,7 @@
test_description='test smart pushing over http via http-backend'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-terminal.sh
if test -n "$NO_CURL"; then
skip_all='skipping test, git built without http support'
@@ -154,5 +155,12 @@ test_expect_success 'push (chunked)' '
test $HEAD = $(git rev-parse --verify HEAD))
'
+test_expect_failure TTY 'quiet push' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ test_commit quiet &&
+ test_terminal git push --quiet --no-progress 2>&1 | tee output &&
+ test_cmp /dev/null output
+'
+
stop_httpd
test_done
--
1.7.6.1
^ permalink raw reply related
* [PATCH 2/3] fix push --quiet via http
From: Clemens Buchacher @ 2011-09-03 16:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, tobiasu, Clemens Buchacher
In-Reply-To: <1315067656-2846-1-git-send-email-drizzd@aon.at>
A verbosity of 0 means quiet for remote helpers.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
remote-curl.c | 2 +-
t/t5541-http-push.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 5798aa5..2341106 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -762,7 +762,7 @@ static int push_git(struct discovery *heads, int nr_spec, char **specs)
argv[argc++] = "--thin";
if (options.dry_run)
argv[argc++] = "--dry-run";
- if (options.verbosity < 0)
+ if (options.verbosity == 0)
argv[argc++] = "--quiet";
else if (options.verbosity > 1)
argv[argc++] = "--verbose";
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 0dcb8df..e756a08 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -155,7 +155,7 @@ test_expect_success 'push (chunked)' '
test $HEAD = $(git rev-parse --verify HEAD))
'
-test_expect_failure TTY 'quiet push' '
+test_expect_success TTY 'quiet push' '
cd "$ROOT_PATH"/test_repo_clone &&
test_commit quiet &&
test_terminal git push --quiet --no-progress 2>&1 | tee output &&
--
1.7.6.1
^ permalink raw reply related
* [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Clemens Buchacher @ 2011-09-03 16:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, tobiasu, Clemens Buchacher
In-Reply-To: <1315067656-2846-1-git-send-email-drizzd@aon.at>
Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack)
introduced the --quiet option to receive-pack and made send-pack
pass that option. Older versions of receive-pack do not recognize
the option, however, and terminate immediately.
This change restores backwards compatibility by adding a 'quiet'
capability to receive-pack.
Reported-by: Tobias Ulmer <tobiasu@tmux.org>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin/receive-pack.c | 10 ++++++----
builtin/send-pack.c | 16 +++++++---------
transport.c | 10 +++-------
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 60260d0..06c481a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -31,6 +31,7 @@ static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
static int use_sideband;
+static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
@@ -114,7 +115,7 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
else
packet_write(1, "%s %s%c%s%s\n",
sha1_to_hex(sha1), path, 0,
- " report-status delete-refs side-band-64k",
+ " report-status delete-refs side-band-64k quiet",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
return 0;
@@ -636,6 +637,8 @@ static struct command *read_head_info(void)
report_status = 1;
if (strstr(refname + reflen + 1, "side-band-64k"))
use_sideband = LARGE_PACKET_MAX;
+ if (strstr(refname + reflen + 1, "quiet"))
+ quiet = 1;
}
cmd = xcalloc(1, sizeof(struct command) + len - 80);
hashcpy(cmd->old_sha1, old_sha1);
@@ -669,7 +672,7 @@ static const char *parse_pack_header(struct pack_header *hdr)
static const char *pack_lockfile;
-static const char *unpack(int quiet)
+static const char *unpack()
{
struct pack_header hdr;
const char *hdr_err;
@@ -788,7 +791,6 @@ static void add_alternate_refs(void)
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
- int quiet = 0;
int advertise_refs = 0;
int stateless_rpc = 0;
int i;
@@ -855,7 +857,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
const char *unpack_status = NULL;
if (!delete_only(commands))
- unpack_status = unpack(quiet);
+ unpack_status = unpack();
execute_commands(commands, unpack_status);
if (pack_lockfile)
unlink_or_warn(pack_lockfile);
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 40a1675..a8d6b4c 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -263,6 +263,8 @@ int send_pack(struct send_pack_args *args,
args->use_ofs_delta = 1;
if (server_supports("side-band-64k"))
use_sideband = 1;
+ if (!server_supports("quiet"))
+ args->quiet = 0;
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
@@ -301,11 +303,12 @@ int send_pack(struct send_pack_args *args,
char *old_hex = sha1_to_hex(ref->old_sha1);
char *new_hex = sha1_to_hex(ref->new_sha1);
- if (!cmds_sent && (status_report || use_sideband)) {
- packet_buf_write(&req_buf, "%s %s %s%c%s%s",
+ if (!cmds_sent && (status_report || use_sideband || args->quiet)) {
+ packet_buf_write(&req_buf, "%s %s %s%c%s%s%s",
old_hex, new_hex, ref->name, 0,
status_report ? " report-status" : "",
- use_sideband ? " side-band-64k" : "");
+ use_sideband ? " side-band-64k" : "",
+ args->quiet ? " quiet" : "");
}
else
packet_buf_write(&req_buf, "%s %s %s",
@@ -492,13 +495,8 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
fd[0] = 0;
fd[1] = 1;
} else {
- struct strbuf sb = STRBUF_INIT;
- strbuf_addstr(&sb, receivepack);
- if (args.quiet)
- strbuf_addstr(&sb, " --quiet");
- conn = git_connect(fd, dest, sb.buf,
+ conn = git_connect(fd, dest, receivepack,
args.verbose ? CONNECT_VERBOSE : 0);
- strbuf_release(&sb);
}
memset(&extra_have, 0, sizeof(extra_have));
diff --git a/transport.c b/transport.c
index 98c5778..c9c8056 100644
--- a/transport.c
+++ b/transport.c
@@ -482,18 +482,14 @@ static int set_git_option(struct git_transport_options *opts,
static int connect_setup(struct transport *transport, int for_push, int verbose)
{
struct git_transport_data *data = transport->data;
- struct strbuf sb = STRBUF_INIT;
if (data->conn)
return 0;
- strbuf_addstr(&sb, for_push ? data->options.receivepack :
- data->options.uploadpack);
- if (for_push && transport->verbose < 0)
- strbuf_addstr(&sb, " --quiet");
- data->conn = git_connect(data->fd, transport->url, sb.buf,
+ data->conn = git_connect(data->fd, transport->url,
+ for_push ? data->options.receivepack :
+ data->options.uploadpack,
verbose ? CONNECT_VERBOSE : 0);
- strbuf_release(&sb);
return 0;
}
--
1.7.6.1
^ permalink raw reply related
* [PATCH] send-email: add option -h
From: Clemens Buchacher @ 2011-09-03 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Most other git commands print a synopsis when passed -h. Make
send-email do the same.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
git-send-email.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..4ac6931 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -275,7 +275,9 @@ $SIG{INT} = \&signal_handler;
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
-my $rc = GetOptions("sender|from=s" => \$sender,
+my $help;
+my $rc = GetOptions("help|H|h" => \$help,
+ "sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
"to=s" => \@initial_to,
@@ -313,6 +315,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"force" => \$force,
);
+usage() if $help;
unless ($rc) {
usage();
}
--
1.7.6.1
^ permalink raw reply related
* Re: Special characters in file name
From: Jakub Narebski @ 2011-09-03 19:57 UTC (permalink / raw)
To: Tajti Ákos; +Cc: git@vger.kernel.org
In-Reply-To: <4E60C6D0.7090609@intland.com>
Tajti Ákos <akos.tajti@intland.com> writes:
> I have a file named "árvíz.txt" in my repository. When modify that
> file and execute git diff, the first line looks like this:
> diff --git "a/\303\241rv\303\255z.txt" "b/\303\241rv\303\255z.txt"
>
> Is there an option that (if specified) will get git to print
> "árvíz.txt" instead of this escaped string?
Yes, there is, namely `core.quotepath`.
This probably should make it into FAQ on Git Wiki, and into git-diff
manpage...
--
Jakub Narębski
^ permalink raw reply
* Re: Special characters in file name
From: Alexey Shumkin @ 2011-09-03 20:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tajti Ákos
In-Reply-To: <20110903144617.GA17893@elie>
> Hi Alexey,
>
> Alexey Shumkin wrote:
> > Tajti Ákos writes:
>
> >> I have a file named "árvíz.txt" in my repository. When modify that
> >> file and execute git diff, the first line looks like this:
> >> diff --git "a/\303\241rv\303\255z.txt" "b/\303\241rv\303\255z.txt"
> >>
> >> Is there an option that (if specified) will get git to print
> >> "árvíz.txt" instead of this escaped string?
> [...]
> > please, refresh your memory )))
> > http://comments.gmane.org/gmane.comp.version-control.git/177849
> >
> > see my comment
> > http://permalink.gmane.org/gmane.comp.version-control.git/177857
>
> Cc-ing Ákos so he can actually get your message this time. :) (FWIW
> the convention on this list is always to reply-to-all.)
Yes, I know, but I replied with the gmane.org site form, and it did not
CC-ed
^ permalink raw reply
* Re: Rebase & Trailing Whitespace
From: Clemens Buchacher @ 2011-09-03 20:18 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Philip Oakley, Hilco Wijbenga, Git Users
In-Reply-To: <20110902082851.GA17703@sigill.intra.peff.net>
On Fri, Sep 02, 2011 at 04:28:51AM -0400, Jeff King wrote:
>
> Yeah, there are a lot. Because of the potential disruption to patches in
> progress, though, we tend not to do big bulk updates of style changes.
> But it may be worth using the
>
> rm foo.c
> git diff -R | git apply --whitespace=fix
I am looking at the output of:
git diff --check 4b825 -- $(git ls-files '*.[ch]'|grep -v ^compat)
Most of those are false positives from multiline function argument
lists, which are aligned with the first line. So the above command
would break more than it would fix.
I don't care either way, but for future reference: Do we or do we
not want indentation with spaces in this case?
Clemens
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: David Aguilar @ 2011-09-03 23:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Phil Hord, git@vger.kernel.org
In-Reply-To: <201109031100.54775.jnareb@gmail.com>
On Sep 3, 2011, at 2:00 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 3 Sep 2011, David Aguilar wrote:
>> On Mon, Jul 25, 2011 at 05:58:32PM -0400, Phil Hord wrote:
>>> On 07/25/2011 04:33 PM, Jakub Narebski wrote:
>>>> === 11. What Git interfaces, implementations and frontends do you use? ===
>>>> (multiple choice, with other)
> [...]
>
>>> Looking at the 2010 results, I would add these GUIs to the main list:
>>> git-gui (core)
>>> gitk (core)
>>> gitX
>>> gitg
>>> git-cola
>>> TortoiseGit
>>> SmartGit
>>> Git Extensions
>>> Giggle
>>
>> This is a better list ;-)
>
> Because of huge number of Git GUIs and tools instead of providing a long
> list of tools to choose from, I went for free-form question:
okay, that makes sense.
nevertheless, we are advertising cogito (deprecated) and pyrite (never made it past pre-alpha in 2008). why? these should be removed. if you need a replacement, might I suggest git-cola? ;-)I think removing (and thus not advertising) dead tools is more important than coming up with replacements. this is on page 4/10 on the survs.com link you sent elsewhere in this thread.
> === 13. List git tools that you use (optional) ===
> (free form, essay)
>
> Description:
> ~~~~~~~~~~~~
> Please include only frontends, interfaces and tools that have support
> for Git (so e.g. EGit applies, but Eclipse doesn't).
>
> Please either use comma separated list of tools, or put each tool in a
> separate line. That would make analysis of answers simpler. Thanks
> in advance.
>
> Even though it is free-form question, it shouldn't be hard to analyse,
> though it wouldn't be completely automatical.
> --
> Jakub Narebski
> Poland
^ 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