What's cooking in git.git (Jun 2013, #03; Thu, 6)

What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* jk/list-objects-sans-blobs (2013-06-06) 4 commits
 - archive: ignore blob objects when checking reachability
 - list-objects: optimize "revs->blob_objects = 0" case
 - upload-archive: restrict remote objects with reachability check
 - clear parsed flag when we free tree buffers

 Attempt to allow "archive --remote=$there $arbitrary_sha1" while
 keeping the reachability safety.

--------------------------------------------------
[Graduated to "master"]

* dm/unbash-subtree (2013-05-21) 1 commit
  (merged to 'next' on 2013-06-03 at 2c9d2fb)
 + contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash

 It turns out that git-subtree script does not have to be run with
 bash.


* fc/cleanups (2013-05-28) 3 commits
  (merged to 'next' on 2013-06-03 at 527cf93)
 + test: rebase: fix --interactive test
 + test: trivial cleanups
 + remote: trivial style cleanup


* fc/makefile (2013-05-26) 5 commits
  (merged to 'next' on 2013-06-03 at d1074e4)
 + build: do not install git-remote-testpy
 + build: add NO_INSTALL variable
 + build: cleanup using $<
 + build: cleanup using $^
 + build: trivial simplification
 (this branch is used by fc/remote-helpers-use-specified-python.)

 Stop installing the git-remote-testpy script that is only used for
 testing.  Also use handy magic variables to simplify rules.


* fc/send-email-chainreplyto-warning (2013-05-28) 1 commit
  (merged to 'next' on 2013-06-03 at e04764f)
 + send-email: remove warning about unset chainreplyto

 An overdue removal of "behaviour changed at 1.7.0; if you were
 living in a cave, here is what you can adjust to it" message.


* fc/show-branch-in-rebase-am (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-03 at 176f6b7)
 + prompt: fix for simple rebase

 The bash prompt code (in contrib/) displayed the name of the branch
 being rebased when "rebase -i/-m/-p" modes are in use, but not the
 plain vanilla "rebase".


* fc/transport-helper-no-refspec (2013-05-21) 2 commits
  (merged to 'next' on 2013-06-03 at 8763bda)
 + transport-helper: check if the dry-run is supported
 + transport-helper: barf when user tries old:new

 With "export" remote-helper protocol, (1) a push that tries to
 update a remote ref whose name is different from the pushing side
 does not work yet, and (2) the helper may not know how to do
 --dry-run, so detect such problematic cases and disable them for
 now.


* jc/core-checkstat (2013-05-06) 1 commit
  (merged to 'next' on 2013-06-03 at 2166cb3)
 + deprecate core.statinfo at Git 2.0 boundary
 (this branch is used by jc/core-checkstat-2.0.)

 The configuration variable core.checkstat was advertised in the
 documentation but the code expected core.statinfo instead.

 For now, we accept both core.checkstat and core.statinfo, but the
 latter will be removed in the longer term.


* ks/difftool-dir-diff-copy-fix (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-03 at ca0cae0)
 + difftool --dir-diff: allow changing any clean working tree file

 "difftool --dir-diff" did not copy back changes made by the
 end-user in the diff tool backend to the working tree in some
 cases.


* nd/clone-connectivity-shortcut (2013-05-28) 4 commits
  (merged to 'next' on 2013-06-03 at 812bd80)
 + clone: open a shortcut for connectivity check
 + index-pack: remove dead code (it should never happen)
 + fetch-pack: prepare updated shallow file before fetching the pack
 + clone: let the user know when check_everything_connected is run

 "git clone" uses a lighter-weight implementation when making sure
 that the history behind refs are complete.


* nd/prune-packed-dryrun-verbose (2013-05-28) 1 commit
  (merged to 'next' on 2013-06-03 at 3445b27)
 + prune-packed: avoid implying "1" is DRY_RUN in prune_packed_objects()


* nd/urls-doc-no-file-hyperlink-fix (2013-05-24) 1 commit
  (merged to 'next' on 2013-06-03 at 54903b2)
 + urls.txt: avoid auto converting to hyperlink

 An entry for "file://" scheme in the enumeration of URL types Git
 can take in the HTML documentation was made into a clickable link
 by mistake.


* rj/mingw-compat-st-mode-bits (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-03 at 2efe84c)
 + path: Fix a sparse warning


* rr/push-head (2013-05-29) 3 commits
  (merged to 'next' on 2013-06-03 at ecd5be7)
 + push: make push.default = current use resolved HEAD
 + push: fail early with detached HEAD and current
 + push: factor out the detached HEAD error message

 "git push $there HEAD:branch" did not resolve HEAD early enough, so
 it was easy to flip it around while push is still going on and push
 out a branch that the user did not originally intended when the
 command was started.


* rr/zsh-color-prompt (2013-05-17) 3 commits
  (merged to 'next' on 2013-06-03 at d011a76)
 + prompt: colorize ZSH prompt
 + prompt: factor out gitstring coloring logic
 + prompt: introduce GIT_PS1_STATESEPARATOR


* rs/commit-m-no-edit (2013-05-28) 1 commit
  (merged to 'next' on 2013-06-03 at 14329fa)
 + commit: don't start editor if empty message is given with -m

 "git commit --allow-empty-message -m ''" should not start an
 editor.


* sb/archive-zip-double-assignment-fix (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-03 at c316eec)
 + archive-zip:write_zip_entry: Remove second reset of size variable to zero.


* tg/maint-zsh-svn-remote-prompt (2013-05-22) 1 commit
  (merged to 'next' on 2013-06-03 at 32a45c0)
 + prompt: fix show upstream with svn and zsh

 zsh prompt script that borrowed from bash prompt script did not
 work due to slight differences in array variable notation between
 these two shells.


* th/bisect-skip-report-range-fix (2013-05-22) 1 commit
  (merged to 'next' on 2013-06-03 at 7bd4656)
 + bisect: Fix log output for multi-parent skip ranges

 Fix for an additional bisect log comments.


* tr/push-no-verify-doc (2013-05-23) 1 commit
  (merged to 'next' on 2013-06-03 at 01737d6)
 + Document push --no-verify

 "git push --[no-]verify" was not documented.

--------------------------------------------------
[Stalled]

* fc/remote-helpers-use-specified-python (2013-05-28) 4 commits
 - remote-helpers: add exec-path links
 - remote-helpers: allow direct test execution
 - remote-helpers: rename tests
 - remote-helpers: generate scripts

 I do not particularly think the second from the bottom is a good
 change, but it takes the remainder of the series hostage.

 Waiting for a reroll.


* jk/packed-refs-race (2013-05-06) 4 commits
 - for_each_ref: load all loose refs before packed refs
 - get_packed_refs: reload packed-refs file when it changes
 - add a stat_validity struct
 - resolve_ref: close race condition for packed refs

 Will be rerolled.


* mg/more-textconv (2013-05-10) 7 commits
 - grep: honor --textconv for the case rev:path
 - grep: allow to use textconv filters
 - t7008: demonstrate behavior of grep with textconv
 - cat-file: do not die on --textconv without textconv filters
 - show: honor --textconv for blobs
 - diff_opt: track whether flags have been set explicitly
 - t4030: demonstrate behavior of show with textconv

 Make "git grep" and "git show" pay attention to --textconv when
 dealing with blob objects.

 I thought this was pretty well designed and executed, but it seems
 there are some doubts on the list; kicking back to 'pu'.


* mh/multimail (2013-04-21) 1 commit
 - git-multimail: a replacement for post-receive-email

 Waiting for the initial history to pull from.
 $gmane/223564


* jc/format-patch (2013-04-22) 2 commits
 - format-patch: --inline-single
 - format-patch: rename "no_inline" field

 A new option to send a single patch to the standard output to be
 appended at the bottom of a message.  I personally have no need for
 this, but it was easy enough to cobble together.  Tests, docs and
 stripping out more MIMEy stuff are left as exercises to interested
 parties.

 Not ready for inclusion.

 Will discard unless we hear from anybody who is interested in
 tying its loose ends.


* jk/gitweb-utf8 (2013-04-08) 4 commits
 - gitweb: Fix broken blob action parameters on blob/commitdiff pages
 - gitweb: Don't append ';js=(0|1)' to external links
 - gitweb: Make feed title valid utf8
 - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch

 Various fixes to gitweb.

 Drew Northup volunteered to take a look into this.
 $gmane/226216


* jk/commit-info-slab (2013-04-19) 3 commits
 - commit-slab: introduce a macro to define a slab for new type
 - commit-slab: avoid large realloc
 - commit: allow associating auxiliary info on-demand
 (this branch is used by jc/show-branch.)

 Technology demonstration to show a way we could use unbound number
 of flag bits on commit objects.


* jc/show-branch (2013-05-21) 5 commits
 - show-branch: use commit slab to represent bitflags of arbitrary width
 - show-branch.c: remove "all_mask"
 - show-branch.c: abstract out "flags" operation
 - show-branch.c: lift all_mask/all_revs to a global static
 - show-branch.c: update comment style
 (this branch uses jk/commit-info-slab.)

 Waiting for the final step to lift the hard-limit before sending it out.

--------------------------------------------------
[Cooking]

* ar/wildmatch-foldcase (2013-06-02) 1 commit
  (merged to 'next' on 2013-06-04 at 3180bcc)
 + wildmatch: properly fold case everywhere

 The wildmatch engine did not honor WM_CASEFOLD option correctly.

 Will merge to 'master'.


* cr/git-work-tree-sans-git-dir (2013-06-03) 1 commit
  (merged to 'next' on 2013-06-04 at bebedca)
 + git.txt: remove stale comment regarding GIT_WORK_TREE

 These days, "git --work-tree=there cmd" without specifying an
 explicit --git-dir=here will do the usual discovery, but we had a
 description of older behaviour in the documentation.

 Will merge to 'master'.


* fc/do-not-use-the-index-in-add-to-index (2013-06-03) 2 commits
  (merged to 'next' on 2013-06-04 at 94e7b60)
 + read-cache: trivial style cleanups
 + read-cache: fix wrong 'the_index' usage

 Will merge to 'master'.


* fc/sequencer-skip-quiet (2013-06-06) 5 commits
 - sequencer: run post-rewrite hook
 - cherry-pick: store rewritten commits
 - cherry-pick: add --skip-empty option
 - sequencer: avoid leaking message buffer when refusing to create an empty commit
 - sequencer: remove useless indentation

 The bottom three looked more or less reasonable.  Execution of
 post-rewrite hook could use a better refactoring from the original
 code copied from builtin/commit.c, though.


* js/test-ln-s-add (2013-06-02) 11 commits
 - t6035: use test_ln_s_add to remove SYMLINKS prerequisite
 - t3509, t4023, t4114: use test_ln_s_add to remove SYMLINKS prerequisite
 - t3100: use test_ln_s_add to remove SYMLINKS prerequisite
 - t3030: use test_ln_s_add to remove SYMLINKS prerequisite
 - t2100: use test_ln_s_add to remove SYMLINKS prerequisite
 - t0000: use test_ln_s_add to remove SYMLINKS prerequisite
 - tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)
 - tests: introduce test_ln_s and test_ln_s_add
 - t3010: modernize style
 - t2100: modernize style and unroll a loop of test cases
 - test-chmtime: Fix exit code on Windows

 Many tests that check the behaviour of symbolic links stored in the
 index or the tree objects do not have to be skipped on a filesystem
 that lack symbolic link support.

 There seem to be some misconversion, mostly around the use of the
 new test_ln_s helper.

 Will be rerolled.
 $gmane/226466,226467


* mt/send-email-cc-match-fix (2013-06-05) 7 commits
  (merged to 'next' on 2013-06-06 at e4d0831)
 + test-send-email: test for pre-sanitized self name
 + t/send-email: test suppress-cc=self with non-ascii
 + t/send-email: add test with quoted sender
 + send-email: make --suppress-cc=self sanitize input
 + t/send-email: test suppress-cc=self on cccmd
 + send-email: fix suppress-cc=self on cccmd
 + t/send-email.sh: add test for suppress-cc=self

 Logic git-send-email used to suppress cc mishandled names like "A
 U. Thor" <author@example.xz>, where the human readable part needs
 to be quoted (the user input may not have the double quotes around
 the name, and comparison was done between quoted and unquoted
 strings).

 Will merge to 'master'.


* rr/complete-difftool (2013-06-03) 2 commits
  (merged to 'next' on 2013-06-04 at 01c7611)
 + completion: clarify ls-tree, archive, show completion
 + completion: difftool takes both revs and files

 Update command line completion (in contrib/) to use a better named
 completion helper function for commands that take revisions and
 paths.

 Will merge to 'master'.


* rr/diffcore-pickaxe-doc (2013-06-03) 2 commits
  (merged to 'next' on 2013-06-04 at 67d1fc7)
 + diffcore-pickaxe doc: document -S and -G properly
 + diffcore-pickaxe: make error messages more consistent

 Update the low-level diffcore documentation on -S/-G and --pickaxe-all.

 Will merge to 'master'.


* tr/sha1-file-silence-loose-object-info-under-prune-race (2013-06-03) 1 commit
  (merged to 'next' on 2013-06-04 at e891bb8)
 + sha1_file: silence sha1_loose_object_info

 Will merge to 'master'.


* bp/mediawiki-credential (2013-06-05) 1 commit
  (merged to 'next' on 2013-06-05 at ea07ec1)
 + git-remote-mediawiki: use Git.pm functions for credentials

 The bridge to MediaWiki has been updated to use the credential
 helper interface in Git.pm, losing its own and the original
 implementation the former was based on.

 Will merge to 'master'.


* mz/rebase-tests (2013-06-03) 7 commits
 - tests: move test for rebase messages from t3400 to t3406
 - t3406: modernize style
 - add tests for rebasing merged history
 - add tests for rebasing root
 - add tests for rebasing of empty commits
 - add tests for rebasing with patch-equivalence present
 - add simple tests of consistency across rebase types

 Will be rerolled.


* fc/completion-less-ls-remote (2013-06-02) 1 commit
  (merged to 'next' on 2013-06-03 at 6624f0b)
 + completion: avoid ls-remote in certain scenarios

 Will merge to 'master'.


* jk/test-exit-code-by-signal (2013-06-06) 2 commits
  (merged to 'next' on 2013-06-06 at 6fdea1b)
 + t0005: skip signal death exit code test on Windows
  (merged to 'next' on 2013-06-03 at 25af892)
 + t0005: test git exit code from signal death

 Will merge to 'master'.


* nd/make-wildmatch-default (2013-06-02) 1 commit
 - Makefile: promote wildmatch to be the default fnmatch implementation

 Will merge to 'next'.


* rr/remove-contrib-some (2013-06-02) 1 commit
  (merged to 'next' on 2013-06-05 at fc15705)
 + contrib: remove continuous/ and patches/

 Remove stale contrib/ material.


* rs/unpack-trees-plug-leak (2013-06-02) 7 commits
  (merged to 'next' on 2013-06-03 at 97e7b6d)
 + unpack-trees: free cache_entry array members for merges
 + diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const
 + diff-lib, read-tree, unpack-trees: mark cache_entry pointers const
 + unpack-trees: create working copy of merge entry in merged_entry
 + unpack-trees: factor out dup_entry
 + read-cache: mark cache_entry pointers const
 + cache: mark cache_entry pointers const

 Will merge to 'master'.


* tr/test-commit-only-on-orphan (2013-06-02) 1 commit
  (merged to 'next' on 2013-06-03 at b1864fd)
 + Test 'commit --only' after 'checkout --orphan'

 Will merge to 'master'.


* ap/diff-ignore-blank-lines (2013-05-29) 1 commit
 - diff: add --ignore-blank-lines option

 "git diff" learned a mode that ignores hunks whose change consists
 only of additions and removals of blank lines, which is the same as
 "diff -B" (ignore blank lines) of GNU diff.

 Will be rerolled.
 $gmane/226394


* rj/mingw-cygwin (2013-05-08) 2 commits
  (merged to 'next' on 2013-06-04 at 308fdb4)
 + cygwin: Remove the CYGWIN_V15_WIN32API build variable
 + mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE

 Update build for Cygwin 1.[57].  Torsten Bögershausen reports that
 this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it
 ahead.

 Will merge to 'master'.


* rr/rebase-autostash (2013-05-29) 7 commits
  (merged to 'next' on 2013-06-04 at 16f7c54)
 + rebase: implement --[no-]autostash and rebase.autostash
 + rebase --merge: return control to caller, for housekeeping
 + rebase -i: return control to caller, for housekeeping
 + am: return control to caller, for housekeeping
 + rebase: prepare to do generic housekeeping
 + rebase -i: don't error out if $state_dir already exists
 + am: tighten a conditional that checks for $dotest

 Will merge to 'master'.


* cb/log-follow-with-combined (2013-05-28) 1 commit
  (merged to 'next' on 2013-06-04 at d5bf4f3)
 + fix segfault with git log -c --follow

 Will merge to 'master'.


* xq/credential-osxkeychain (2013-05-28) 1 commit
  (merged to 'next' on 2013-06-04 at a4ee0e0)
 + credential-osxkeychain: support more protocols

 Will merge to 'master'.


* mh/reflife (2013-06-02) 25 commits
  (merged to 'next' on 2013-06-05 at 291d863)
 + refs: document the lifetime of the args passed to each_ref_fn
 + register_ref(): make a copy of the bad reference SHA-1
 + exclude_existing(): set existing_refs.strdup_strings
 + string_list_add_refs_by_glob(): add a comment about memory management
 + string_list_add_one_ref(): rename first parameter to "refname"
 + show_head_ref(): rename first parameter to "refname"
 + show_head_ref(): do not shadow name of argument
 + add_existing(): do not retain a reference to sha1
 + do_fetch(): clean up existing_refs before exiting
 + do_fetch(): reduce scope of peer_item
 + object_array_entry: fix memory handling of the name field
 + find_first_merges(): remove unnecessary code
 + find_first_merges(): initialize merges variable using initializer
 + fsck: don't put a void*-shaped peg in a char*-shaped hole
 + object_array_remove_duplicates(): rewrite to reduce copying
 + revision: use object_array_filter() in implementation of gc_boundary()
 + object_array: add function object_array_filter()
 + revision: split some overly-long lines
 + cmd_diff(): make it obvious which cases are exclusive of each other
 + cmd_diff(): rename local variable "list" -> "entry"
 + cmd_diff(): use an object_array for holding trees
 + builtin_diff_tree(): make it obvious that function wants two entries
 + add_rev_cmdline(): make a copy of the name argument
 + fetch: make own copies of refnames
 + describe: make own copy of refname

 Define memory ownership and lifetime rules for what for-each-ref
 feeds to its callbacks (in short, "you do not own it, so make a
 copy if you want to keep it").

 Will merge to 'master'.


* mm/mediawiki-https-fail-message (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-04 at fb2671c)
 + git-remote-mediawiki: better error message when HTTP(S) access fails

 Hint users when https:// connection failed to check the
 certificate; it is a good hint if we assumie that it is common
 error for the end users to make.

 Will merge to 'master'.


* rr/die-on-missing-upstream (2013-06-02) 2 commits
  (merged to 'next' on 2013-06-03 at 00847ea)
 + sha1_name: fix error message for @{<N>}, @{<date>}
 + sha1_name: fix error message for @{u}

 When a reflog notation is used for implicit "current branch", we
 did not say which branch and worse said "branch ''".

 Will merge to 'master'.


* fc/remote-bzr (2013-05-28) 8 commits
  (merged to 'next' on 2013-06-04 at a603082)
 + remote-bzr: add fallback check for a partial clone
 + remote-bzr: reorganize the way 'wanted' works
 + remote-bzr: trivial cleanups
 + remote-bzr: change global repo
 + remote-bzr: delay cloning/pulling
 + remote-bzr: simplify get_remote_branch()
 + remote-bzr: fix for files with spaces
 + remote-bzr: recover from failed clones

 Will merge to 'master'.


* jx/clean-interactive (2013-06-03) 15 commits
 - test: add t7301 for git-clean--interactive
 - git-clean: add documentation for interactive git-clean
 - git-clean: add ask each interactive action
 - git-clean: add select by numbers interactive action
 - git-clean: add filter by pattern interactive action
 - git-clean: use a git-add-interactive compatible UI
 - git-clean: add colors to interactive git-clean
 - git-clean: show items of del_list in columns
 - git-clean: add support for -i/--interactive
 - git-clean: refactor git-clean into two phases
 - Refactor write_name_quoted_relative, remove unused params
 - Refactor quote_path_relative, remove unused params
 - quote.c: remove path_relative, use relative_path instead
 - path.c: refactor relative_path(), not only strip prefix
 - test: add test cases for relative_path


* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
 - test-lib: support running tests under valgrind in parallel
 - test-lib: allow prefixing a custom string before "ok N" etc.
 - test-lib: valgrind for only tests matching a pattern
 - test-lib: verbose mode for only tests matching a pattern
 - test-lib: refactor $GIT_SKIP_TESTS matching
 - test-lib: enable MALLOC_* for the actual tests

 Allows N instances of tests run in parallel, each running 1/N parts
 of the test suite under Valgrind, to speed things up.

 The tip one may be useful in practice but is a tad ugly ;-)

 There seem to be some miscounting by toggling the verbose/valgrind
 mode at wrong places?  Cf. $gmane/225735

 Waiting for a reroll.


* fc/contrib-related (2013-06-03) 4 commits
 - contrib: related: parse committish like format-patch
 - contrib: related: add option to parse from committish
 - contrib: related: add support for multiple patches
 - Add new git-related helper to contrib

 Waiting for the design review to settle.


* fc/remote-hg (2013-05-28) 50 commits
  (merged to 'next' on 2013-06-04 at 9ee7dab)
 + remote-hg: add support for --force
 + remote-hg: add support for --dry-run
 + remote-hg: check if a fetch is needed
 + remote-hg: trivial cleanup
 + remote-helpers: improve marks usage
 + remote-hg: add check_push() helper
 + remote-hg: add setup_big_push() helper
 + remote-hg: remove files before modifications
 + remote-hg: improve lightweight tag author
 + remote-hg: use remote 'default' not local one
 + remote-hg: improve branch listing
 + remote-hg: simplify branch_tip()
 + remote-hg: check diverged bookmarks
 + remote-hg: pass around revision refs
 + remote-hg: implement custom checkheads()
 + remote-hg: implement custom push()
 + remote-hg: only update necessary revisions
 + remote-hg: force remote bookmark push selectively
 + remote-hg: reorganize bookmark handling
 + remote-hg: add test for failed double push
 + remote-hg: add test for big push
 + remote-hg: add test for new bookmark special
 + remote-hg: add test for bookmark diverge
 + remote-hg: add test for diverged push
 + remote-hg: add test to push new bookmark
 + remote-hg: add remote tests
 + remote-hg: update bookmarks when using a remote
 + remote-hg: add check_bookmark() test helper
 + remote-bzr: simplify test checks
 + remote-hg: add tests for 'master' bookmark
 + remote-hg: always point HEAD to master
 + remote-hg: improve progress calculation
 + remote-hg: trivial cleanups
 + remote-hg: ensure remote rebasing works
 + remote-hg: upgrade version 1 marks
 + remote-hg: switch from revisions to SHA-1 noteids
 + remote-hg: add version checks to the marks
 + remote-hg: improve node traversing
 + remote-hg: shuffle some code
 + remote-hg: use a shared repository store
 + remote-hg: load all extensions
 + remote-hg: test: simplify previous branch checkout
 + remote-helpers: test: simplify remote URLs
 + remote-helpers: tests: general improvements
 + remote-helpers: test: cleanup style
 + remote-helpers: test: cleanup white-spaces
 + remote-hg: trivial reorganization
 + remote-hg: test: be a little more quiet
 + remote-hg: tests: fix hg merge
 + remote-helpers: tests: use python directly

 Will merge to 'master'.


* hv/config-from-blob (2013-05-12) 5 commits
 - do not die when error in config parsing of buf occurs
 - teach config --blob option to parse config from database
 - config: make parsing stack struct independent from actual data source
 - config: drop cf validity check in get_next_char()
 - config: factor out config file stack management

 Waiting for a reroll.
 $gmane/223964


* kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits
  (merged to 'next' on 2013-06-05 at 193242b)
 + revision.c: make default history consider bottom commits
 + revision.c: don't show all merges for --parents
 + revision.c: discount side branches when computing TREESAME
 + revision.c: add BOTTOM flag for commits
 + simplify-merges: drop merge from irrelevant side branch
 + simplify-merges: never remove all TREESAME parents
 + t6012: update test for tweaked full-history traversal
 + revision.c: Make --full-history consider more merges
 + Documentation: avoid "uninteresting"
 + rev-list-options.txt: correct TREESAME for P
 + t6111: add parents to tests
 + t6111: allow checking the parents as well
 + t6111: new TREESAME test set
 + t6019: test file dropped in -s ours merge
 + decorate.c: compact table when growing

 Major update to a very core part of the revision traversal logic to
 improve culling of irrelevant parents while traversing a mergy
 history.


* mm/color-auto-default (2013-05-15) 2 commits
 - make color.ui default to 'auto'
 - config: refactor management of color.ui's default value

 Flip the default for color.ui to 'auto', which is what many
 tutorials recommend new users to do.  The updated code claims the
 switch happened at Git 2.0 in the past tense, but we might want to
 expedite it, as this change is not all that important to deserve a
 major version bump.

 I'd vote for merging this without waiting for 2.0.  Comments?

 Waiting for a reroll.


* jh/shorten-refname (2013-05-07) 4 commits
 - t1514: refname shortening is done after dereferencing symbolic refs
 - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
 - t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD"
 - t1514: Add tests of shortening refnames in strict/loose mode

 When remotes/origin/HEAD is not a symbolic ref, "rev-parse
 --abbrev-ref remotes/origin/HEAD" ought to show "origin", not
 "origin/HEAD", which is fixed with this series (if it is a symbolic
 ref that points at remotes/origin/something, then it should show
 "origin/something" and it already does).

 Expecting a reroll, as an early part of a larger series.


* nd/warn-ambiguous-object-name (2013-05-29) 1 commit
  (merged to 'next' on 2013-06-04 at e87c9d1)
 + get_sha1: warn about full or short object names that look like refs

 "git cmd <name>", when <name> happens to be a 40-hex string,
 directly uses the 40-hex string as an object name, even if a ref
 "refs/<some hierarchy>/<name>" exists.  This disambiguation order
 is unlikely to change, but we should warn about the ambiguity just
 like we warn when more than one refs/ hierachies share the same
 name.

 Will merge to 'master'.


* fc/at-head (2013-05-08) 13 commits
  (merged to 'next' on 2013-06-04 at f334a2a)
 + sha1_name: compare variable with constant, not constant with variable
 + Add new @ shortcut for HEAD
 + sha1_name: refactor reinterpret()
 + sha1_name: check @{-N} errors sooner
 + sha1_name: reorganize get_sha1_basic()
 + sha1_name: don't waste cycles in the @-parsing loop
 + sha1_name: remove unnecessary braces
 + sha1_name: remove no-op
 + tests: at-combinations: @{N} versus HEAD@{N}
 + tests: at-combinations: increase coverage
 + tests: at-combinations: improve nonsense()
 + tests: at-combinations: check ref names directly
 + tests: at-combinations: simplify setup

 Instead of typing four capital letters "HEAD", you can say "@"
 instead.

 Will merge to 'master'.


* jk/submodule-subdirectory-ok (2013-04-24) 3 commits
 - submodule: fix quoting in relative_path()
 - submodule: drop the top-level requirement
 - rev-parse: add --prefix option

 Allow various subcommands of "git submodule" to be run not from the
 top of the working tree of the superproject.

 Waiting for a reroll.


* jl/submodule-mv (2013-04-23) 5 commits
 - submodule.c: duplicate real_path's return value
 - rm: delete .gitmodules entry of submodules removed from the work tree
 - Teach mv to update the path entry in .gitmodules for moved submodules
 - Teach mv to move submodules using a gitfile
 - Teach mv to move submodules together with their work trees

 "git mv A B" when moving a submodule A does "the right thing",
 inclusing relocating its working tree and adjusting the paths in
 the .gitmodules file.

 Waiting for a reroll.


* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit
 - git add: -u/-A now affects the entire working tree

 Will cook in 'next' until Git 2.0.


* jc/core-checkstat-2.0 (2013-05-06) 1 commit
 - core.statinfo: remove as promised in Git 2.0

 Will cook in 'next' until Git 2.0.


* jc/push-2.0-default-to-simple (2013-04-03) 1 commit
 - push: switch default from "matching" to "simple"

 Will cook in 'next' until Git 2.0.


* jc/add-2.0-ignore-removal (2013-04-22) 1 commit
 - git add <pathspec>... defaults to "-A"

 Updated endgame for "git add <pathspec>" that defaults to "--all"
 aka "--no-ignore-removal".

 Will cook in 'next' until Git 2.0.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
> * rr/complete-difftool (2013-06-03) 2 commits
>   (merged to 'next' on 2013-06-04 at 01c7611)
>  + completion: clarify ls-tree, archive, show completion
>  + completion: difftool takes both revs and files
> 
>  Update command line completion (in contrib/) to use a better named
>  completion helper function for commands that take revisions and
>  paths.
> 
>  Will merge to 'master'.

This should not be merged to master as is; the one at the top because
of the reasons given in $gmane/226272, the one at the bottom because
of the misleading commit message (__git_complete_file() always
completed refs first as part of the ref:file notation, so it worked
just fine except for the ref1...ref2 notation; the real reason for
calling __git_complete_revlist_file() for difftool is to make clear
that difftool takes ref1...ref2:file, too).


Gábor

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
>> * rr/complete-difftool (2013-06-03) 2 commits
>>   (merged to 'next' on 2013-06-04 at 01c7611)
>>  + completion: clarify ls-tree, archive, show completion
>>  + completion: difftool takes both revs and files
>> 
>>  Update command line completion (in contrib/) to use a better named
>>  completion helper function for commands that take revisions and
>>  paths.
>> 
>>  Will merge to 'master'.
>
> This should not be merged to master as is; the one at the top because
> of the reasons given in $gmane/226272, the one at the bottom because
> of the misleading commit message (__git_complete_file() always
> completed refs first as part of the ref:file notation, so it worked
> just fine except for the ref1...ref2 notation; the real reason for
> calling __git_complete_revlist_file() for difftool is to make clear
> that difftool takes ref1...ref2:file, too).

Oops.

It is too late to amend the log messages now, but at least a follow-up
patch can fix the breakage by adding __git_complete_file() back.  Would
you mind doing that?

Thanks.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

Forgot to cc; sorry about that.

Junio C Hamano <gitster@pobox.com> writes:

> SZEDER Gábor <szeder@ira.uka.de> writes:
>
>> On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
>>> * rr/complete-difftool (2013-06-03) 2 commits
>>>   (merged to 'next' on 2013-06-04 at 01c7611)
>>>  + completion: clarify ls-tree, archive, show completion
>>>  + completion: difftool takes both revs and files
>>> 
>>>  Update command line completion (in contrib/) to use a better named
>>>  completion helper function for commands that take revisions and
>>>  paths.
>>> 
>>>  Will merge to 'master'.
>>
>> This should not be merged to master as is; the one at the top because
>> of the reasons given in $gmane/226272, the one at the bottom because
>> of the misleading commit message (__git_complete_file() always
>> completed refs first as part of the ref:file notation, so it worked
>> just fine except for the ref1...ref2 notation; the real reason for
>> calling __git_complete_revlist_file() for difftool is to make clear
>> that difftool takes ref1...ref2:file, too).
>
> Oops.
>
> It is too late to amend the log messages now, but at least a follow-up
> patch can fix the breakage by adding __git_complete_file() back.  Would
> you mind doing that?
>
> Thanks.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

SZEDER Gábor wrote:
> the one at the top because
> of the reasons given in $gmane/226272

Sorry about the delay: I went to sleep for a couple of days :P

> the one at the bottom because
> of the misleading commit message (__git_complete_file() always
> completed refs first as part of the ref:file notation, so it worked
> just fine except for the ref1...ref2 notation; the real reason for
> calling __git_complete_revlist_file() for difftool is to make clear
> that difftool takes ref1...ref2:file, too).

How am I (or anyone else) supposed to know the "intended" meaning
__git_complete_file()?  The implementation is just an alias to
__git_complete_revlist_file(), so I looked at the name and guessed
that it was supposed to complete files; now you tell me that it was
intended to complete any revspec except revision ranges (what does
that have to do with "file" again?).  I suppose digging through the
history would've told me, but I really didn't bother for such a
trivial non-functional change.

If you ask me, you should clamp down on spurious completions
everywhere uniformly, if that is what you want (I personally have no
interest in the topic).  I see no reason to keep a badly named
function around.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> SZEDER Gábor wrote:
>> the one at the top because
>> of the reasons given in $gmane/226272
>
> Sorry about the delay: I went to sleep for a couple of days :P
>
>> the one at the bottom because
>> of the misleading commit message (__git_complete_file() always
>> completed refs first as part of the ref:file notation, so it worked
>> just fine except for the ref1...ref2 notation; the real reason for
>> calling __git_complete_revlist_file() for difftool is to make clear
>> that difftool takes ref1...ref2:file, too).
>
> How am I (or anyone else) supposed to know the "intended" meaning
> __git_complete_file()?

"git log -Gcomplete_file -p contrib/completion" found this one:

commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
Author: SZEDER Gábor <szeder@ira.uka.de>
Date:   Thu Mar 10 19:12:29 2011 +0100

    bash: complete 'git diff ...branc<TAB>'
    
    While doing a final sanity check before merging a topic Bsomething, it
    is a good idea to review what damage Bsomething branch would make, by
    running:
    
        $ git diff ...Bsomething
    
    Unfortunately, our completion script for 'git diff' doesn't offer
    anything after '...'.  This is because 'git diff's completion function
    invokes __git_complete_file() for non-option arguments to complete the
    '<tree>:<path>' extended SHA-1 notation, but this helper function
    doesn't support refs after '...' or '..'.  Completion of refs after
    '...' or '..' is supported by the __git_complete_revlist() helper
    function, but that doesn't support '<tree>:<path>'.
    
    To support both '...<ref>' and '<tree>:<path>' notations for 'git
    diff', this patch, instead of adding yet another helper function,
    joins __git_complete_file() and __git_complete_revlist() into the new
    common function __git_complete_revlist_file().  The old helper
    functions __git_complete_file() and __git_complete_revlist() are
    changed to be a direct wrapper around the new
    __git_complete_revlist_file(), because they might be used in
    user-supplied completion scripts and we don't want to break them.
    
    This change will cause some wrong suggestions for other commands which
    use __git_complete_file() ('git diff' and friends) or
    __git_complete_revlist() ('git log' and friends), e.g. 'git diff
    ...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
    path to 'Documentation/', although neither commands make any sense.
    However, both of these were actively wrong to begin with as soon as
    the user entered the ':', so there is no real harm done.
    
    Suggested-by: Junio C Hamano <gitster@pobox.com>
    Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Now I do not recall suggesting it, and you (and I today after 2
years) may disagree with the rationale, but at least we can read
what was the "intended" meaning, I think.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Fri, Jun 07, 2013 at 11:00:14PM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > the one at the top because
> > of the reasons given in $gmane/226272
> 
> Sorry about the delay: I went to sleep for a couple of days :P
> 
> > the one at the bottom because
> > of the misleading commit message (__git_complete_file() always
> > completed refs first as part of the ref:file notation, so it worked
> > just fine except for the ref1...ref2 notation; the real reason for
> > calling __git_complete_revlist_file() for difftool is to make clear
> > that difftool takes ref1...ref2:file, too).
> 
> How am I (or anyone else) supposed to know the "intended" meaning
> __git_complete_file()?  The implementation is just an alias to
> __git_complete_revlist_file(), so I looked at the name and guessed
> that it was supposed to complete files; now you tell me that it was
> intended to complete any revspec except revision ranges (what does
> that have to do with "file" again?).  I suppose digging through the
> history would've told me, but I really didn't bother for such a
> trivial non-functional change.

Yeah, I suppose it's always wise to do a bit of history digging before
you go on to remove a function you don't know what it is doing, even
though a simple git log -Sfuncname perhaps doesn't even qualifies for
"digging" ;)

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> Now I do not recall suggesting it, and you (and I today after 2
> years) may disagree with the rationale, but at least we can read
> what was the "intended" meaning, I think.

Having spent so much time documenting pickaxe, I should atleast learn
to use it more often :\

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Fri, Jun 07, 2013 at 11:41:07AM -0700, Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
> 
> commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
> Author: SZEDER Gábor <szeder@ira.uka.de>
> Date:   Thu Mar 10 19:12:29 2011 +0100
> 
>     bash: complete 'git diff ...branc<TAB>'

(snip)

>     Suggested-by: Junio C Hamano <gitster@pobox.com>
>     Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> Now I do not recall suggesting it, and you (and I today after 2
> years) may disagree with the rationale, but at least we can read
> what was the "intended" meaning, I think.

See

  http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838

I still agree with the rationale, considering that the new
__git_complete_revlist_file() function for completing ref1...ref2:path
is a nearly straight copy-paste from the then __git_complete_revlist()
and __git_complete_file() including that 12 line long sed script.


Gábor

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Thu, Jun 06, 2013 at 06:05:44PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
> 
> > On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
> >> * rr/complete-difftool (2013-06-03) 2 commits
> >>   (merged to 'next' on 2013-06-04 at 01c7611)
> >>  + completion: clarify ls-tree, archive, show completion
> >>  + completion: difftool takes both revs and files
> >> 
> >>  Update command line completion (in contrib/) to use a better named
> >>  completion helper function for commands that take revisions and
> >>  paths.
> >> 
> >>  Will merge to 'master'.
> >
> > This should not be merged to master as is; the one at the top because
> > of the reasons given in $gmane/226272, the one at the bottom because
> > of the misleading commit message (__git_complete_file() always
> > completed refs first as part of the ref:file notation, so it worked
> > just fine except for the ref1...ref2 notation; the real reason for
> > calling __git_complete_revlist_file() for difftool is to make clear
> > that difftool takes ref1...ref2:file, too).
> 
> Oops.
> 
> It is too late to amend the log messages now, but at least a follow-up
> patch can fix the breakage by adding __git_complete_file() back.  Would
> you mind doing that?

Is it in master already?  Am I missing something?

Wouldn't it be cleaner to revert those two patches from next and apply
this instead?


 -- >8 --

From: SZEDER Gábor <szeder@ira.uka.de>
Subject: [PATCH] completion: be explicit about revlist completion for difftool
 and show

The completion functions for 'git difftool' and 'git show' call
__git_complete_file() to support completion of the 'ref:path' notation.
However, these two commands also understand the 'ref1..ref2:path'
notation, the completion of which we happen to support accidentaly,
because nowadays __git_complete_file() is a wrapper around
__git_complete_revlist_file().

Let's be explicit about it and call __git_complete_revlist_file()
directly.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 56c52c66..fd9a1d5f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1211,7 +1211,7 @@ _git_difftool ()
 		return
 		;;
 	esac
-	__git_complete_file
+	__git_complete_revlist_file
 }
 
 __git_fetch_options="
@@ -2277,7 +2277,7 @@ _git_show ()
 		return
 		;;
 	esac
-	__git_complete_file
+	__git_complete_revlist_file
 }
 
 _git_show_branch ()
-- 
1.8.0.220.g4d14ece

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

>> Now I do not recall suggesting it, and you (and I today after 2
>> years) may disagree with the rationale, but at least we can read
>> what was the "intended" meaning, I think.
>
> See
>
>   http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838
>
> I still agree with the rationale,...

Thanks for a pointer.  I think what I was suggesting was slightly
different in that I was hoping to see a single helper that knows to
complete to object names (possibly including trees/blobs with the
treeish:path notation), ranges, and pathnames (not treeish:path
notation) until it sees a "--" and then complete only to pathnames.

It can be improved by teaching the unified one that some command
like "log" can never take treeish:path but only committishes, some
command take individual object names but never ranges, and/or
details like that.  But I still agree that "git log HEAD:dir<TAB>"
that completes to a blob or a tree object name is not an issue
(because what was before <TAB> cannot possibly name anything "git
log" would appreciate), even though it might not be ideal.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

SZEDER Gábor wrote:
> because nowadays __git_complete_file() is a wrapper around
> __git_complete_revlist_file().

What?  It was never anything different from a poorly-named alias for
__git_complete_revlist_file().  You have already agreed that
__git_complete_file() is a horrible name, so why not deprecate it?
Whom is this confusion benefiting, and how is it any "cleaner"?  If
you're arguing about expanding __git_complete_file(), don't do that:
just write a new function and give it a proper name.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Sat, Jun 08, 2013 at 01:17:28AM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > because nowadays __git_complete_file() is a wrapper around
> > __git_complete_revlist_file().
> 
> What?  It was never anything different from a poorly-named alias for
> __git_complete_revlist_file().

Again: __git_complete_file() has been there since the completion
script was first included in git.

>  You have already agreed that
> __git_complete_file() is a horrible name, so why not deprecate it?

I am not against deprecating it, and by "it" I mean the function name.

> Whom is this confusion benefiting, and how is it any "cleaner"?

It's clearer because of the reasons I gave in my other email in the
discussion of the patch.

Plus it would avoid commits on master with incorrect commit messages.

> If
> you're arguing about expanding __git_complete_file(), don't do that:
> just write a new function and give it a proper name.

I am not arguing about that.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
> Thanks for a pointer.  I think what I was suggesting was slightly
> different in that I was hoping to see a single helper that knows to
> complete to object names (possibly including trees/blobs with the
> treeish:path notation), ranges, and pathnames (not treeish:path
> notation) until it sees a "--" and then complete only to pathnames.

We already got that except the completion of pathnames before "--",
and I don't know how that could be done properly for commands taking
both refs and paths.  Just consider

  git diff git.c
  git diff master git.c
  git diff master next git.c

We can't guess whether the user wants refs or paths when he first hits
tab after 'git diff ', not even after 'git diff master '.  I
definitely don't want to see refs and paths all mixed up.

As for the _single_ helper: I think it has some value that we have
different helper functions and we can indicate whether a certain git
command can take a ref or ref:path or ref1...ref2 or even
ref1..ref2:path by calling the appropriate helper function (however
badly it might have been named), even if all these functions happen to
boil down to a single implementation.


Gábor

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
>> Thanks for a pointer.  I think what I was suggesting was slightly
>> different in that I was hoping to see a single helper that knows to
>> complete to object names (possibly including trees/blobs with the
>> treeish:path notation), ranges, and pathnames (not treeish:path
>> notation) until it sees a "--" and then complete only to pathnames.
>
> We already got that except the completion of pathnames before "--",
> and I don't know how that could be done properly for commands taking
> both refs and paths.
> ...
>   git diff git.c
>   git diff master git.c
>   git diff master next git.c

It is somewhat annoying that "git diff gi<TAB>" stops at expanding
it to "git diff git" and then upon another "git diff git<TAB>"
offers tags whose names begin with "git" (e.g. gitgui-0.10.0) but
the pathname git.c is not included in the choices.  My wish was to
take the union in such a fairly limited case.  I tend to agree with
you that "git diff <TAB>" that expands to all refs and pathnames
would be useless, but so is expansion to all pathnames (or refnames
for that matter).

In any case, I wouldn't insist on AI perfection in the first place
;-).  As long as it works reasonably well, I am happy (and I think
the current completion code already works better than reasonably
well, at least for me).

Thanks.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

On Fri, Jun 07, 2013 at 02:53:02PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
> 
> > On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
> >> Thanks for a pointer.  I think what I was suggesting was slightly
> >> different in that I was hoping to see a single helper that knows to
> >> complete to object names (possibly including trees/blobs with the
> >> treeish:path notation), ranges, and pathnames (not treeish:path
> >> notation) until it sees a "--" and then complete only to pathnames.
> >
> > We already got that except the completion of pathnames before "--",
> > and I don't know how that could be done properly for commands taking
> > both refs and paths.
> > ...
> >   git diff git.c
> >   git diff master git.c
> >   git diff master next git.c
> 
> It is somewhat annoying that "git diff gi<TAB>" stops at expanding
> it to "git diff git" and then upon another "git diff git<TAB>"
> offers tags whose names begin with "git" (e.g. gitgui-0.10.0) but
> the pathname git.c is not included in the choices.  My wish was to
> take the union in such a fairly limited case.  I tend to agree with
> you that "git diff <TAB>" that expands to all refs and pathnames
> would be useless, but so is expansion to all pathnames (or refnames
> for that matter).

... or trying to complete a branch name starting with a 'v', and then
getting all the vx.y.z tags.

If you know you want git.c, then you can force filename completion
either by entering "--" before hitting tab or by using the Alt-/ Bash
(readline?) keybinding, otherwise you'll get refs.  I think this is
more than adequate, as it brings the best of both worlds: you can
quickly and easily get both ref-only and file-only completion.
Training your fingers to type "--" is perhaps better, just in case
we'll ever do tracked-file-aware filename completion for e.g. 'git log
-- g<TAB>' in the future.


Best,
Gábor

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> * mm/color-auto-default (2013-05-15) 2 commits
>  - make color.ui default to 'auto'
>  - config: refactor management of color.ui's default value
>
>  Flip the default for color.ui to 'auto', which is what many
>  tutorials recommend new users to do.  The updated code claims the
>  switch happened at Git 2.0 in the past tense, but we might want to
>  expedite it, as this change is not all that important to deserve a
>  major version bump.
>
>  I'd vote for merging this without waiting for 2.0.  Comments?

Yes, please merge.  The commit message looks good as well: it doesn't
say anything about waiting for 2.0.

>  Waiting for a reroll.

The one in pu looks fine to me.  What am I missing?

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Yes, please merge.  The commit message looks good as well: it doesn't
> say anything about waiting for 2.0.

The commit message doesn't, but the doc does. I'll resend without the
2.0 mention.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

>> It is somewhat annoying that "git diff gi<TAB>" stops at expanding
>> it to "git diff git" and then upon another "git diff git<TAB>"
>> offers tags whose names begin with "git" (e.g. gitgui-0.10.0) but
>> the pathname git.c is not included in the choices.  My wish was to
>> take the union in such a fairly limited case.  I tend to agree with
>> you that "git diff <TAB>" that expands to all refs and pathnames
>> would be useless, but so is expansion to all pathnames (or refnames
>> for that matter).
>
> ... or trying to complete a branch name starting with a 'v', and then
> getting all the vx.y.z tags.
>
> If you know you want git.c, then you can force filename completion
> either by entering "--" before hitting tab...

Yes, that is exactly why I said "the current completion code already
works better than reasonably well, at least for me" in the
concluding part of my message.

Regarding that rr/complete-difftool topic, let's revert the tip 2
commits (the "ls-tree, archive and show" one, and the follow-up
resurrection of __git_complete_file) with this:

    Revert 77c1305 and 3c3b46b
    
    As explained by SZEDER Gábor in $gmane/226272, git_complete_file
    helper is about completing <tree-ish>, taking <commit> at the tips
    of refs and also understanding <tree-ish>:<path> notation, and
    changing "archive" and "ls-tree" to use git_complete_revlist_file
    that in addition is meant to expand A..B range notation was a
    mistake.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

and then queue this on top of d8517cc6670d (completion: difftool
takes both revs and files, 2013-06-02), so that the attached and
d8517cc6670d will be the only two commits that graduate to 'master'
from this topic.

-- >8 --
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sun, 2 Jun 2013 19:33:42 +0530
Subject: [PATCH] completion: show can take both revlist and paths

The 'git show' completion uses __git_complete_file (aliased to
__git_complete_revlist_file), because accepts <tree-ish>:<path> as
well as <commit-ish>.  But the command also accepts range of commits
in A..B notation, so using __git_complete_revlist_file is more
appropriate.

There still remain two users of __git_complete_file, completions for
"archive" and "ls-tree".  As these commands do not take range
notation, and "git show" no longer uses __git_complete_file, the
implementation of can be updated not to complete ranges, but that is
a separate topic.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1b4b0f9..b9dfc3b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2360,7 +2360,7 @@ _git_show ()
 		return
 		;;
 	esac
-	__git_complete_file
+	__git_complete_revlist_file
 }
 
 _git_show_branch ()
-- 
1.8.3-477-gc2fede3

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[SZEDER Gábor]

Hi,


On Sun, Jun 09, 2013 at 02:20:33PM -0700, Junio C Hamano wrote:
> Regarding that rr/complete-difftool topic, let's revert the tip 2
> commits (the "ls-tree, archive and show" one, and the follow-up
> resurrection of __git_complete_file) with this:
> 
>     Revert 77c1305 and 3c3b46b
>     
>     As explained by SZEDER Gábor in $gmane/226272, git_complete_file
>     helper is about completing <tree-ish>, taking <commit> at the tips
>     of refs and also understanding <tree-ish>:<path> notation, and
>     changing "archive" and "ls-tree" to use git_complete_revlist_file
>     that in addition is meant to expand A..B range notation was a
>     mistake.
>     
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> and then queue this on top of d8517cc6670d (completion: difftool
> takes both revs and files, 2013-06-02), so that the attached and
> d8517cc6670d will be the only two commits that graduate to 'master'
> from this topic.

That's fine with me, except ...

> -- >8 --
> From: Ramkumar Ramachandra <artagnon@gmail.com>
> Date: Sun, 2 Jun 2013 19:33:42 +0530
> Subject: [PATCH] completion: show can take both revlist and paths
> 
> The 'git show' completion uses __git_complete_file (aliased to
> __git_complete_revlist_file), because accepts <tree-ish>:<path> as
> well as <commit-ish>.  But the command also accepts range of commits
> in A..B notation, so using __git_complete_revlist_file is more
> appropriate.
> 
> There still remain two users of __git_complete_file, completions for
> "archive" and "ls-tree".  As these commands do not take range
> notation, and "git show" no longer uses __git_complete_file, the
> implementation of can be updated not to complete ranges, but that is

"the implementation of" what?  A word missing perhaps?  Or "the
implementation can be updated"?


Best,
Gábor

> a separate topic.
> 
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  contrib/completion/git-completion.bash | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 1b4b0f9..b9dfc3b 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2360,7 +2360,7 @@ _git_show ()
>  		return
>  		;;
>  	esac
> -	__git_complete_file
> +	__git_complete_revlist_file
>  }
>  
>  _git_show_branch ()
> -- 
> 1.8.3-477-gc2fede3

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

>> There still remain two users of __git_complete_file, completions for
>> "archive" and "ls-tree".  As these commands do not take range
>> notation, and "git show" no longer uses __git_complete_file, the
>> implementation of can be updated not to complete ranges, but that is
>
> "the implementation of" what?  A word missing perhaps?

it.

Thanks.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
>     Revert 77c1305 and 3c3b46b

The core of the argument seems to be that
__git_complete_revlist_file() is a misleading name for the completion
done by archive and ls-tree, but __git_complete_file() is somehow a
less misleading name?  Irrespective of what the valid completions of
the various commands are, I want to know which completion function
will be _used_ when I'm reading the script.  And that is
__git_complete_revlist_file().

To me, it looks like mega-bikeshedding; a huge amount of time and
effort going behind a non-functional variable rename (and the best
part? the rename isn't getting us a "better" name; just a "historical"
name).  But whatever.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>>     Revert 77c1305 and 3c3b46b
>
> The core of the argument seems to be that
> __git_complete_revlist_file() is a misleading name for the completion
> done by archive and ls-tree, but __git_complete_file() is somehow a
> less misleading name?  Irrespective of what the valid completions of
> the various commands are, I want to know which completion function
> will be _used_ when I'm reading the script.  And that is
> __git_complete_revlist_file().
>
> To me, it looks like mega-bikeshedding; a huge amount of time and
> effort going behind a non-functional variable rename (and the best
> part? the rename isn't getting us a "better" name; just a "historical"
> name).  But whatever.

To me the most important part is that we have two separate functions
that are used consistently by how the completion is to be done for
their users.  The complete-file variant can then lose the A..B range
completion, and then be given a better name than FILE to express
what it does if somebody can find one.  When it happens, the same
better name should be used to rename complete-revlist-FILE by
replacing the "FILE" part.

I initially thought that FILE referred to the pathspecs (i.e. the
last part in "log <rev> <file>"), and felt it was strange to call it
FILE.  Perhaps that (i.e. it not being pathspec) is what you find it
misnamed).

But it turns out that in the context of these functions it refers to
"what users consider paths in objects stored in the object database"
(as opposed to working tree paths).  That is what ls-tree would take
(i.e. <tree-ish> and <tree-ish>:<path>).  And I do not offhand think
of a better name myself to strongly oppose to using the word FILE to
refer to what it does.

Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> But it turns out that in the context of these functions it refers to
> "what users consider paths in objects stored in the object database"
> (as opposed to working tree paths).  That is what ls-tree would take
> (i.e. <tree-ish> and <tree-ish>:<path>).  And I do not offhand think
> of a better name myself to strongly oppose to using the word FILE to
> refer to what it does.

__git_complete_treeish().  Write a new patch with a proper comment
saying why it is aliased to __git_complete_revlist_file().