From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:33
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are in the post-1.8.3 cycle. As promised, 'next' has been
rewound. A few stalled topics have been ejected and bunch of new
topics that have been cooking are now in it. I expect these on
'next' to graduate to 'master' soonish, as I picked relatively easy
ones in this round.
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
--------------------------------------------------
[Graduated to "master"]
* kb/status-ignored-optim-2 (2013-06-02) 1 commit
(merged to 'next' on 2013-06-02 at 88ee588)
+ dir.c: fix ignore processing within not-ignored directories
Fix 1.8.3 regressions in the .gitignore path exclusion logic.
--------------------------------------------------
[New Topics]
* 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-03) 8 commits
- revert/cherry-pick: add --skip option
- revert/cherry-pick: add --quiet option
- sequencer: run post-rewrite hook
- cherry-pick: store rewritten commits
- SQUASH???
- cherry-pick: add --skip-empty option
- sequencer: trivial fix
- sequencer: remove useless indentation
I think the post-rewrite hook should not apply to revert, and
revert should be taught about --skip-empty. The "copy-notes"
change was nak'ed, and I agree with Thomas that the external
interface to the mechanism should be aligned with existing
notes.rewrite.<command>.
Waiting for a reroll.
$gmane/225676, $gmane/226263, $gmane/226271
* 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.
Waiting for responses to reviews.
$gmane/226417 and others.
* mt/send-email-cc-match-fix (2013-06-03) 6 commits
- 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
It may want to have an additional test case for --from='"A U. Thor"
[off-list ref]' to make sure we do not doubly escape what is
already escaped.
Some changes in patch 2/6 and a later patch may need to be flipped
around.
* 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-04) 1 commit
- 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.
Minor review comments sent.
* 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
--------------------------------------------------
[Stalled]
* 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]
* 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-02) 1 commit
(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
- contrib: remove continuous/ and patches/
Will merge to 'next'.
* 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
* 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".
Will merge to 'master'.
* 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.
Will merge to 'master'.
* 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.
Will merge to 'master'.
* 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.
Will merge to 'master'.
* 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'.
* 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
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'.
* 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
Will merge to 'master'.
* 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.)
Will merge to 'master'.
* 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
(this branch uses fc/makefile.)
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.
* 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 od "behaviour changed at 1.7.0; if you were
living in a cave, here is what you can adjust to it" message.
Will merge to 'master'.
* 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()
Will merge to 'master'.
* 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
Will merge to 'master'.
* 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.
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'.
* 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.)
Will merge to 'master'.
* mh/reflife (2013-06-02) 25 commits
- 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 'next'.
* 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.
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'.
* 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.
Will merge to 'master'.
* 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.
Will merge 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.
Will merge to 'master'.
* 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.
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.
* 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
Will merge to 'master'.
* 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
* 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
Will merge to 'master'.
* kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits
- 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 system to improve culling
of irrelevant parents while traversing a mergy history.
Will not be a 1.8.3 material, but is an important topic.
Will merge to 'next'.
* 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'.
* 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
What is the status of this thing?
* 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
(this branch uses jc/core-checkstat.)
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.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:33
Junio C Hamano [off-list ref] writes:
* 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.
As people may have seen in the discussion on the earlier iteration,
something like this (there may be a room for bikeshedding the name,
though) that takes either a range of changes or set of patches and
finds people who may be able to review them may be a good addition
to our official toolchest.
http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796
Right now, "related" is in contrib/ primarily because its design
review phase is not yet finished and because it is in Ruby, which
the rest of the system does not depend on.
I have some administrative comments on two issues as the maintainer.
* Do we want to add Ruby dependency?
* Do we want to keep expanding contrib/?
These have been triggered by "related", but the comments in this
message are not limited to the specific topic (e.g. you can read it
with s/Ruby/<any language we currently do not depend on>/).
On Ruby:
Assuming "related" is a good idea, to make it as the proper part of
the system out of contrib/ when its design review phase is finished,
one of these things has to happen:
1. Find a volunteer to rewrite it in one of the languages that we
know the platforms our current users use already support, which
means either C (not a good match), POSIX shell (not the best
match), or Perl.
2. Promote Ruby to the first-class citizen status, which involves
making sure people on platforms that matter do not have problem
adding dependency on it (I am primarily worried about MinGW
folks), and also making sure core developers do not mind
reviewing code written in it.
As long as we can get as high quality reviews on changes written in
Ruby as we do for the current codebase, it is OK to go route #2, and
that may hopefully happen in the longer term as and there will be
some people, among competent Ruby programmers, who have understood
how the pieces of entire Git are designed to fit together by the
time it happens.
I however do not know how much extra burden it would place to add
dependencies to platform folks, so obviously the safer approach is 1
at least in the immediate future. My understanding is that msysgit
folks are already having trouble with Python, and we do not want to
go route #2 at least for now. Having to ship a variant of Git with
NO_PYTHON is already bad enough. And that is why the option 1 above
does not list Python as a possible candidate.
On contrib/:
Back when Git was very young, it made sense to bundle third-party
tools in our tree's "contrib/" section to give them visibility and
users convenience. Now Git ecosystem has grown to have many users
who know Git and who do not necessarily come to this list, and with
easy-to-use hosting sites where anybody can publish their ware and
collaborate with their contributors, "giving more visibility" angle
of contrib/ has outlived its usefulness. When there are multiple
third-party tools that address similar needs, there is not much
point picking one at random and ship it over others, and shipping
all of them is simply crazy. In an ecosystem with flourishing
third-party add-ons, their products should and will stand on their
own.
As the maintainer, I've been thinking about closing contrib/ area
for new stuff, and shrinking existing ones, either by moving stuff
that are only useful within the context of Git to main part of the
tree (e.g. "contrib/workdir" may move to a new directory "addons/",
some of remote-helpers in contrib/ may move to "remote-helpers/",
etc.), and removing others from contrib/, for this reason. Of
course, interested folks can take the last version of the removed
ones and continue improving them as standalone projects.
And that is why the list of possible actions in the previous part
does not have "3. Keep it in contrib/ forever" as an option.
That is all for the "administrative comments" as the maintainer.
The rest is just a personal opinion.
If we were looking at a compelling and sizeable web application that
depends on Rails, it is very likely that it would not make much
sense to rewrite it in other languages only to avoid a new language
dependency on Ruby.
But "related" is "read and extract some info out of text files,
spawn a 'blame' (or two) based on that info, read to collect further
info and summarize", for which Ruby does not especially shine
compared to Perl, which is the language we already depend on.
Because of this, I am moderately reluctant to add Ruby dependency
only for this script. Unless I know people who regularly give us
high quality reviews, and those who support various platforms, are
fine with it, that is.
In the shorter term (read: up to 2.0), I am inclined to vote that we
should go route #1 (i.e. rewrite in Perl once the design settles).
My "personal opinion" above of course assumes that everybody agrees
that "related" is a good addition. If not, there is "3. not add it
to contrib/ and leave it as an out-of-tree third-party project"
option.
From: David Lang <hidden> Date: 2016-06-15 22:57:33
On Tue, 4 Jun 2013, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
On Ruby:
Assuming "related" is a good idea, to make it as the proper part of
the system out of contrib/ when its design review phase is finished,
one of these things has to happen:
1. Find a volunteer to rewrite it in one of the languages that we
know the platforms our current users use already support, which
means either C (not a good match), POSIX shell (not the best
match), or Perl.
2. Promote Ruby to the first-class citizen status, which involves
making sure people on platforms that matter do not have problem
adding dependency on it (I am primarily worried about MinGW
folks), and also making sure core developers do not mind
reviewing code written in it.
As long as we can get as high quality reviews on changes written in
Ruby as we do for the current codebase, it is OK to go route #2, and
that may hopefully happen in the longer term as and there will be
some people, among competent Ruby programmers, who have understood
how the pieces of entire Git are designed to fit together by the
time it happens.
I however do not know how much extra burden it would place to add
dependencies to platform folks, so obviously the safer approach is 1
at least in the immediate future. My understanding is that msysgit
folks are already having trouble with Python, and we do not want to
go route #2 at least for now. Having to ship a variant of Git with
NO_PYTHON is already bad enough. And that is why the option 1 above
does not list Python as a possible candidate.
As someone who builds minimalist builds (firewalls, openwrt, raspberry pi, etc),
having to pull in a full ruby install to get git installed would not be
something I'd like to see.
Yes, openwrt (and I) can build our own version, but that's a pain. I tend to
build my tight systems from Debian and it's nice to be able to use stock
packages.
I tend to use git for sysadmin type functions as much as for development, so
it's very useful even on such small and slow platforms.
On contrib/:
Back when Git was very young, it made sense to bundle third-party
tools in our tree's "contrib/" section to give them visibility and
users convenience. Now Git ecosystem has grown to have many users
who know Git and who do not necessarily come to this list, and with
easy-to-use hosting sites where anybody can publish their ware and
collaborate with their contributors, "giving more visibility" angle
of contrib/ has outlived its usefulness. When there are multiple
third-party tools that address similar needs, there is not much
point picking one at random and ship it over others, and shipping
all of them is simply crazy. In an ecosystem with flourishing
third-party add-ons, their products should and will stand on their
own.
As the maintainer, I've been thinking about closing contrib/ area
for new stuff, and shrinking existing ones, either by moving stuff
that are only useful within the context of Git to main part of the
tree (e.g. "contrib/workdir" may move to a new directory "addons/",
some of remote-helpers in contrib/ may move to "remote-helpers/",
etc.), and removing others from contrib/, for this reason. Of
course, interested folks can take the last version of the removed
ones and continue improving them as standalone projects.
If you can, you should leave just enough of a stub in place so that people who
don't know about the change and try to run the stuff that used to be in contrib/
get a message pointing them to the new home.
David Lang
From: Michael Haggerty <hidden> Date: 2016-06-15 22:57:33
On 06/05/2013 02:04 AM, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
* 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.
As people may have seen in the discussion on the earlier iteration,
something like this (there may be a room for bikeshedding the name,
though) that takes either a range of changes or set of patches and
finds people who may be able to review them may be a good addition
to our official toolchest.
http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796
Right now, "related" is in contrib/ primarily because its design
review phase is not yet finished and because it is in Ruby, which
the rest of the system does not depend on.
I have some administrative comments on two issues as the maintainer.
* Do we want to add Ruby dependency?
* Do we want to keep expanding contrib/?
These have been triggered by "related", but the comments in this
message are not limited to the specific topic (e.g. you can read it
with s/Ruby/<any language we currently do not depend on>/).
On Ruby:
[...]
I don't have an opinion on allowing Ruby into the core, except to say
that I would personally prefer *some* alternative that is more capable
than shell and more modern and self-consistent than Perl. Python, Ruby,
and Lua would seem to be the obvious candidates, with the latter being
easiest for packagers.
On contrib/:
Back when Git was very young, it made sense to bundle third-party
tools in our tree's "contrib/" section to give them visibility and
users convenience. Now Git ecosystem has grown to have many users
who know Git and who do not necessarily come to this list, and with
easy-to-use hosting sites where anybody can publish their ware and
collaborate with their contributors, "giving more visibility" angle
of contrib/ has outlived its usefulness. When there are multiple
third-party tools that address similar needs, there is not much
point picking one at random and ship it over others, and shipping
all of them is simply crazy. In an ecosystem with flourishing
third-party add-ons, their products should and will stand on their
own.
For completeness, let me point out two other small advantages of contrib:
* a tool in contrib can assume that it is being bundled with the
corresponding version of Git, and therefore doesn't necessarily have to
go to the effort of supporting older versions of Git.
* at the source-code level, a tool in contrib can take advantage of some
of the Git build/test infrastructure, though I don't know whether they
currently do.
But my main point is that I think it would be easier to phase out
contrib/ if there were a good alternate way of providing visibility to
"satellite" projects. The relevant Git wiki page [1] is the most likely
candidate, but it is a bit overwhelming due to its size, it has fallen
into disuse because it was broken for such a long time, and it is not
prominently linked to from git-scm.com. If it were curated a bit, it
would help users find the best ancillary tools quickly. Perhaps ranking
the tools based on the results of the Git user surveys would help bring
the most popular to the top of each category.
Michael
[1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Johannes Sixt <hidden> Date: 2016-06-15 22:57:33
Am 6/5/2013 1:45, schrieb Junio C Hamano:
* jk/test-exit-code-by-signal (2013-06-02) 1 commit
(merged to 'next' on 2013-06-03 at 25af892)
+ t0005: test git exit code from signal death
Will merge to 'master'.
I haven't gotten around to run this new test on Windows. I've reason to
believe that it won't pass as is. Please don't let it graduate, yet.
-- Hannes
From: Jeff King <hidden> Date: 2016-06-15 22:57:33
On Wed, Jun 05, 2013 at 08:59:15AM +0200, Johannes Sixt wrote:
Am 6/5/2013 1:45, schrieb Junio C Hamano:
quoted
* jk/test-exit-code-by-signal (2013-06-02) 1 commit
(merged to 'next' on 2013-06-03 at 25af892)
+ t0005: test git exit code from signal death
Will merge to 'master'.
I haven't gotten around to run this new test on Windows. I've reason to
believe that it won't pass as is. Please don't let it graduate, yet.
Yeah, I sort of assumed that we would need to check for either "3" or
"131" on Windows, but I wasn't sure which. I don't think there is any
rush on it.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:33
On Tue, Jun 4, 2013 at 10:02 PM, David Lang [off-list ref] wrote:
On Tue, 4 Jun 2013, Junio C Hamano wrote:
quoted
Junio C Hamano [off-list ref] writes:
On Ruby:
Assuming "related" is a good idea, to make it as the proper part of
the system out of contrib/ when its design review phase is finished,
one of these things has to happen:
1. Find a volunteer to rewrite it in one of the languages that we
know the platforms our current users use already support, which
means either C (not a good match), POSIX shell (not the best
match), or Perl.
2. Promote Ruby to the first-class citizen status, which involves
making sure people on platforms that matter do not have problem
adding dependency on it (I am primarily worried about MinGW
folks), and also making sure core developers do not mind
reviewing code written in it.
As long as we can get as high quality reviews on changes written in
Ruby as we do for the current codebase, it is OK to go route #2, and
that may hopefully happen in the longer term as and there will be
some people, among competent Ruby programmers, who have understood
how the pieces of entire Git are designed to fit together by the
time it happens.
I however do not know how much extra burden it would place to add
dependencies to platform folks, so obviously the safer approach is 1
at least in the immediate future. My understanding is that msysgit
folks are already having trouble with Python, and we do not want to
go route #2 at least for now. Having to ship a variant of Git with
NO_PYTHON is already bad enough. And that is why the option 1 above
does not list Python as a possible candidate.
As someone who builds minimalist builds (firewalls, openwrt, raspberry pi,
etc), having to pull in a full ruby install to get git installed would not
be something I'd like to see.
You wouldn't _have_ to, just like you don't _have_ to install Python right now.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:33
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
I however do not know how much extra burden it would place to add
dependencies to platform folks, so obviously the safer approach is 1
at least in the immediate future. My understanding is that msysgit
folks are already having trouble with Python, and we do not want to
go route #2 at least for now. Having to ship a variant of Git with
NO_PYTHON is already bad enough. And that is why the option 1 above
does not list Python as a possible candidate.
This rests on the assumption that Ruby would be as difficult to
distribute as Python, which might not be the case.
As the maintainer, I've been thinking about closing contrib/ area
for new stuff, and shrinking existing ones, either by moving stuff
that are only useful within the context of Git to main part of the
tree (e.g. "contrib/workdir" may move to a new directory "addons/",
some of remote-helpers in contrib/ may move to "remote-helpers/",
etc.), and removing others from contrib/, for this reason. Of
course, interested folks can take the last version of the removed
ones and continue improving them as standalone projects.
This does make sense, however, I do think some parts of Git might be
more maintainable if they have their own Makefile (e.g. bash
completion), where it's clear where they should be installed by
default.
Either way, the user might want to do 'install-all' or
'install-addons', to install all these things, and I think a good rule
of thumb is that if we don't want 'install-all' to install certain
script (eventually), then that script probably doesn't belong in
'contrib' (or anywhere in Git).
The rest is just a personal opinion.
If we were looking at a compelling and sizeable web application that
depends on Rails, it is very likely that it would not make much
sense to rewrite it in other languages only to avoid a new language
dependency on Ruby.
But "related" is "read and extract some info out of text files,
spawn a 'blame' (or two) based on that info, read to collect further
info and summarize", for which Ruby does not especially shine
compared to Perl, which is the language we already depend on.
Because of this, I am moderately reluctant to add Ruby dependency
only for this script. Unless I know people who regularly give us
high quality reviews, and those who support various platforms, are
fine with it, that is.
In the shorter term (read: up to 2.0), I am inclined to vote that we
should go route #1 (i.e. rewrite in Perl once the design settles).
That might make sense for the shorter term, but in longer term I see
Perl as declining in favor of other languages. It's only a matter of
time before Ruby surpasses Perl in popularity, and soon enough new
contributors to the Git project will have problems trying to improve
Git because parts of it are written in a language they are not
familiar with, and have trouble learning (isn't that already
happening?).
The Ruby vs. Python is another question altogether, I could go into
detail about why I think Ruby is a better choice, but my point right
now is that Perl is not a good choice for the future.
--
Felipe Contreras
From: Johannes Sixt <hidden> Date: 2016-06-15 22:57:34
From: Johannes Sixt <redacted>
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Microsoft C runtime
(and probably not even possible).
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
We could check for exit code 3 in addition to 143, but that would miss
the point of the test entirely. Hence, just skip it on Windows.
Signed-off-by: Johannes Sixt <redacted>
---
t/t0005-signals.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -20,7 +20,7 @@ test_expect_success 'sigchain works' 'test_cmpexpectactual'-test_expect_success'signals are propagated using shell convention''+test_expect_success!MINGW'signals are propagated using shell convention''# we use exec here to avoid any sub-shell interpretation# of the exit codegitconfigalias.sigterm"!exec test-sigchain"&&
From: Jeff King <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:
From: Johannes Sixt <redacted>
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Microsoft C runtime
(and probably not even possible).
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
We could check for exit code 3 in addition to 143, but that would miss
the point of the test entirely. Hence, just skip it on Windows.
Thanks. I wasn't quite clear on how the signal handling worked on
Windows, but from your description, I agree there is not any point in
running the test at all.
Acked-by: Jeff King <redacted>
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 1:37 AM, Jeff King [off-list ref] wrote:
On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:
quoted
From: Johannes Sixt <redacted>
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Microsoft C runtime
(and probably not even possible).
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
We could check for exit code 3 in addition to 143, but that would miss
the point of the test entirely. Hence, just skip it on Windows.
Thanks. I wasn't quite clear on how the signal handling worked on
Windows, but from your description, I agree there is not any point in
running the test at all.
Shouldn't we clarify that Git exit codes only work on UNIX-like
operating systems?
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:
quoted
Thanks. I wasn't quite clear on how the signal handling worked on
Windows, but from your description, I agree there is not any point in
running the test at all.
Shouldn't we clarify that Git exit codes only work on UNIX-like
operating systems?
Clarify where? My impression is that this issue is well-known in the
msys world, and it is a platform issue, not a git issue. If somebody
wants to write a note somewhere in the git documentation, that's fine
with me, but I'm not clear on exactly what it would even say.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 1:44 AM, Jeff King [off-list ref] wrote:
On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:
quoted
quoted
Thanks. I wasn't quite clear on how the signal handling worked on
Windows, but from your description, I agree there is not any point in
running the test at all.
Shouldn't we clarify that Git exit codes only work on UNIX-like
operating systems?
Clarify where?
Documentation/technical/api-run-command.txt
My impression is that this issue is well-known in the
msys world, and it is a platform issue, not a git issue. If somebody
wants to write a note somewhere in the git documentation, that's fine
with me, but I'm not clear on exactly what it would even say.
That the exit code is not the same in Windows (not msys).
--
Felipe Contreras
On 5 June 2013 16:45, Felipe Contreras [off-list ref] wrote:
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano [off-list ref] wrote:
That might make sense for the shorter term, but in longer term I see
Perl as declining in favor of other languages. It's only a matter of
time before Ruby surpasses Perl in popularity, and soon enough new
contributors to the Git project will have problems trying to improve
Git because parts of it are written in a language they are not
familiar with, and have trouble learning (isn't that already
happening?).
The Ruby vs. Python is another question altogether, I could go into
detail about why I think Ruby is a better choice, but my point right
now is that Perl is not a good choice for the future.
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Yves
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 2:26 AM, demerphq [off-list ref] wrote:
On 5 June 2013 16:45, Felipe Contreras [off-list ref] wrote:
quoted
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano [off-list ref] wrote:
That might make sense for the shorter term, but in longer term I see
Perl as declining in favor of other languages. It's only a matter of
time before Ruby surpasses Perl in popularity, and soon enough new
contributors to the Git project will have problems trying to improve
Git because parts of it are written in a language they are not
familiar with, and have trouble learning (isn't that already
happening?).
The Ruby vs. Python is another question altogether, I could go into
detail about why I think Ruby is a better choice, but my point right
now is that Perl is not a good choice for the future.
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
None of that has anything to do with Perl's popularity.
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Perl has been going away for the last decade [1], and will continue to
go away. Perl is going away, and that an undeniable fact, and if you
are not interested in discussing on the basis of reality, I'm not
interested in discussing with you.
[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
--
Felipe Contreras
From: Barry Fishman <hidden> Date: 2016-06-15 22:57:34
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
On Thu, Jun 6, 2013 at 2:26 AM, demerphq [off-list ref] wrote:
quoted
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
None of that has anything to do with Perl's popularity.
quoted
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Perl has been going away for the last decade [1], and will continue to
go away. Perl is going away, and that an undeniable fact, and if you
are not interested in discussing on the basis of reality, I'm not
interested in discussing with you.
[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
I don't think the usefulness of a language should be judged by hits on a
web site.
Personally I would like the Git client to be packaged with as few
dependencies as possible. Right now that seems to require Shell, Sed,
Awk and Perl. The documentation has other requirements, but a prebuild
tar file is available.
I would have the rest of the distribution be bundled as something
like "git-utils" which could have a subdirectory for each support
language. Then one could even make available alternative
implementations of higher level utilities and people could decide if
support of a specific language was useful to them.
Most such extension code is simple, although more complex than suitable
for just Shell/Sed/Awk. People in each language community could provide
code which meets the needs of their community, and the Git project
itself would not need to make (Solomon like) decisions about what
extension languages to support.
--
Barry Fishman
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman [off-list ref] wrote:
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
quoted
On Thu, Jun 6, 2013 at 2:26 AM, demerphq [off-list ref] wrote:
quoted
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
None of that has anything to do with Perl's popularity.
quoted
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Perl has been going away for the last decade [1], and will continue to
go away. Perl is going away, and that an undeniable fact, and if you
are not interested in discussing on the basis of reality, I'm not
interested in discussing with you.
[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
I don't think the usefulness of a language should be judged by hits on a
web site.
Nobody is judging the usefulness of a language, I have plenty of
arguments for that, but this is about popularity.
Personally I would like the Git client to be packaged with as few
dependencies as possible. Right now that seems to require Shell, Sed,
Awk and Perl. The documentation has other requirements, but a prebuild
tar file is available.
I would be perfectly fine with replacing shell, sed, awk and perl with
ruby. But that's not what you are arguing, is it?
--
Felipe Contreras
From: Barry Fishman <hidden> Date: 2016-06-15 22:57:34
On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman [off-list ref] wrote:
quoted
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
quoted
On Thu, Jun 6, 2013 at 2:26 AM, demerphq [off-list ref] wrote:
quoted
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
None of that has anything to do with Perl's popularity.
quoted
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Perl has been going away for the last decade [1], and will continue to
go away. Perl is going away, and that an undeniable fact, and if you
are not interested in discussing on the basis of reality, I'm not
interested in discussing with you.
[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
I don't think the usefulness of a language should be judged by hits on a
web site.
Nobody is judging the usefulness of a language, I have plenty of
arguments for that, but this is about popularity.
I used "usefulness" in its general vague sense. It is useful to be popular,
I don't make choices solely on that or I would be writing everything in
Java.
quoted
Personally I would like the Git client to be packaged with as few
dependencies as possible. Right now that seems to require Shell, Sed,
Awk and Perl. The documentation has other requirements, but a prebuild
tar file is available.
I would be perfectly fine with replacing shell, sed, awk and perl with
ruby. But that's not what you are arguing, is it?
I'm talking about porcelain code and not core functionality which should
be left in C. I'm saying that you should be free to provide Ruby
implementations of all such superstructure. And the same can be done by
(but not required by) the Perl, Python, Tcl and even C, Haskel, Guile
and whatever communities. Most such higher level code is fairly
trivial, and if the file names are kept the same, the same test
procedures could be run.
I don't think the cost of duplication of code functionality is that
significant, since it would bring new people to the project. After all
this is a free project and not a commerical venture. It certainly helps
porting to new platforms. Separate language communities would be
maintaining their own contributions, with their own experimental
directories.
Translating the same functionality to multiple languages requires
careful reading which can help identify some hidden bugs.
--
Barry Fishman
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 8:46 AM, Barry Fishman [off-list ref] wrote:
On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
quoted
Nobody is judging the usefulness of a language, I have plenty of
arguments for that, but this is about popularity.
I used "usefulness" in its general vague sense. It is useful to be popular,
I don't make choices solely on that or I would be writing everything in
Java.
Straw man.
quoted
quoted
Personally I would like the Git client to be packaged with as few
dependencies as possible. Right now that seems to require Shell, Sed,
Awk and Perl. The documentation has other requirements, but a prebuild
tar file is available.
I would be perfectly fine with replacing shell, sed, awk and perl with
ruby. But that's not what you are arguing, is it?
I don't know what you are saying, but it clearly has nothing to do
with the point.
Perl is declining, and it would be wise to use another language instead of it.
--
Felipe Contreras
From: Barry Fishman <hidden> Date: 2016-06-15 22:57:34
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:
I don't know what you are saying, but it clearly has nothing to do
with the point.
Perl is declining, and it would be wise to use another language
instead of it.
You want a simple statement. I don't particulary like Perl, but it has
worked well for the project.
If you have a better solution, then write all the code to replace it,
and demonstrate with a significant number of active users that your
solution works out better in practice.
Wasn't that how Git started?
--
Barry Fishman
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:34
On Thu, Jun 6, 2013 at 9:41 AM, Barry Fishman [off-list ref] wrote:
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:
quoted
I don't know what you are saying, but it clearly has nothing to do
with the point.
Perl is declining, and it would be wise to use another language
instead of it.
You want a simple statement. I don't particulary like Perl, but it has
worked well for the project.
It would serve it less and less as the years go by.
If you have a better solution, then write all the code to replace it,
False dichotomy fallacy. I don't need to do that.
--
Felipe Contreras
From: Thomas Ferris Nicolaisen <hidden> Date: 2016-06-15 22:57:34
On Wed, Jun 5, 2013 at 6:13 AM, Michael Haggerty [off-list ref] wrote:
But my main point is that I think it would be easier to phase out
contrib/ if there were a good alternate way of providing visibility to
"satellite" projects. The relevant Git wiki page [1] is the most likely
candidate, but it is a bit overwhelming due to its size, it has fallen
into disuse because it was broken for such a long time, and it is not
prominently linked to from git-scm.com. If it were curated a bit, it
would help users find the best ancillary tools quickly. Perhaps ranking
the tools based on the results of the Git user surveys would help bring
the most popular to the top of each category.
One idea here could be to mirror what the libgit2 project [1] (and many
others) are doing on GitHub. Use the organization unit [2] as an umbrella
for the contrib projects. If necessary, put a pretty web-page on top [3].
Of course you don't have to tie it to GitHub, but they do have some nice
mechanisms for showing off popularity (stars and forks).
I heard that clojure/contrib [4] went through a big clean-up recently,
although I'm not sure if there was an equivalent reasoning behind it. But
their guide-lines on what should go into contrib may have some good
ideas [5].
[1] https://github.com/libgit2
[2] https://github.com/git
[3] http://libgit2.github.com/
[4] http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go
[5] http://dev.clojure.org/pages/viewpage.action?pageId=5767464
From: Charles McGarvey <hidden> Date: 2016-06-15 22:57:34
On 06/06/2013 01:46 AM, Felipe Contreras wrote:
On Thu, Jun 6, 2013 at 2:26 AM, demerphq [off-list ref] wrote:
quoted
Good thing you are being objective and leaving out the Python 3.0
mess, the long legacy of backwards compatibility in the Perl
community, the active community behind it, its extensive portability
support, and fail to mention the lack of an equivalent to CPAN. We
wouldn't want facts to get in the way of a personal bias would we?
None of that has anything to do with Perl's popularity.
quoted
Just thought I'd push back on the FUD. People have been saying Perl is
going away for decades...
Perl has been going away for the last decade [1], and will continue to
go away. Perl is going away, and that an undeniable fact, and if you
are not interested in discussing on the basis of reality, I'm not
interested in discussing with you.
[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
The linchpin of your argument is that Perl is dying. Let's assume that the
TIOBE index is a reliable basis for making business decisions--it's not, but
let's pretend--the graph you linked to doesn't even seem to support your
conclusion (or am I missing something?). It looks like Perl's popularity has
pretty much been constant for at least two years. It's apparently not
increasing in popularity, but this isn't an electrocardiogram (i.e.
flat-lining is not dead or even dying). The same graph shows that Ruby's
popularity also hasn't changed very much since 2007 after its initial surge.
Now, it's probably too off-topic to pick apart TIOBE's methodology here, but
suffice it to say that, like any trend indicator, it's only as useful as your
knowledge of its limitations, and this has been discussed enough elsewhere.
It's true that Perl isn't soon going to win any trendiness awards, but the
same reasons that made Perl a good choice for git so many years ago are still
there and then some. You would probably also be surprised at the number of
new kids learning Perl.
I guess I just denied the "undeniable fact" that Perl is going away, so maybe
I'm one of those with whom you do not want to discuss this, but, for my part,
I am willing to consider other evidence for the claim. As I pointed out, the
evidence shown so far (one reference to the TIOBE index) isn't nearly enough
to settle the matter. I also apologize for dragging this out if this thread
is judged to not be worth a whole lot.
--
Charles McGarvey
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:57:35
On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt [off-list ref] wrote:
From: Johannes Sixt <redacted>
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Microsoft C runtime
(and probably not even possible).
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
We could check for exit code 3 in addition to 143, but that would miss
the point of the test entirely. Hence, just skip it on Windows.
Huh? We do "exit(128 + sigint);" in mingw_raise these days, no?
Or is the signal triggered from a non-git process?
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:57:35
On Fri, Jun 7, 2013 at 12:01 PM, Erik Faye-Lund [off-list ref] wrote:
On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt [off-list ref] wrote:
quoted
From: Johannes Sixt <redacted>
The test case depends on that test-sigchain can commit suicide by a call
to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
as death through a signal. There are no POSIX signals on Windows, and a
sufficiently close emulation is not available in the Microsoft C runtime
(and probably not even possible).
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
We could check for exit code 3 in addition to 143, but that would miss
the point of the test entirely. Hence, just skip it on Windows.
Huh? We do "exit(128 + sigint);" in mingw_raise these days, no?
Or is the signal triggered from a non-git process?