All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Dec 2010, #06; Tue, 21)
@ 2010-12-22  1:59 Junio C Hamano
  2010-12-22 11:05 ` Thiago Farina
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Junio C Hamano @ 2010-12-22  1:59 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

I'd like to merge nd/setup, nd/struct-pathspec, and everything in
tonight's 'next' soon and tag 1.7.4-rc1 but I might be being a bit too
ambitious.
--------------------------------------------------
[Graduated to "master"]

* jk/maint-decorate-01-bool (2010-12-18) 1 commit
  (merged to 'next' on 2010-12-20 at 72471ca)
 + handle arbitrary ints in git_config_maybe_bool

* jk/t2107-now-passes (2010-12-18) 1 commit
  (merged to 'next' on 2010-12-20 at c9156b5)
 + t2107: mark passing test as success

* jn/maint-gitweb-pathinfo-fix (2010-12-14) 1 commit
  (merged to 'next' on 2010-12-14 at 1af8cca)
 + gitweb: Fix handling of whitespace in generated links

* ks/blame-worktree-textconv-cached (2010-12-18) 2 commits
  (merged to 'next' on 2010-12-20 at 459c940)
 + fill_textconv(): Don't get/put cache if sha1 is not valid
 + t/t8006: Demonstrate blame is broken when cachetextconv is on

* nd/oneline-sha1-name-from-specific-ref (2010-12-15) 4 commits
  (merged to 'next' on 2010-12-20 at 553cf37)
 + get_sha1: handle special case $commit^{/}
 + get_sha1: support $commit^{/regex} syntax
 + get_sha1_oneline: make callers prepare the commit list to traverse
 + get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable

* tc/completion-reflog (2010-12-16) 1 commit
  (merged to 'next' on 2010-12-20 at 2fa91e0)
 + bash completion: add basic support for git-reflog

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

* jk/commit-die-on-bogus-ident (2010-12-20) 2 commits
  (merged to 'next' on 2010-12-21 at 7785c31)
 + commit: die before asking to edit the log message
 + ident: die on bogus date format

* jc/maint-am-abort-safely (2010-12-21) 1 commit
  (merged to 'next' on 2010-12-21 at 81602bc)
 + am --abort: keep unrelated commits since the last failure and warn

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

* mg/cvsimport (2010-11-28) 3 commits
 - cvsimport.txt: document the mapping between config and options
 - cvsimport: fix the parsing of uppercase config options
 - cvsimport: partial whitespace cleanup

I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other
people injected sanity to the discussion.  Weatherbaloon patch sent, but
not queued here.

* nd/index-doc (2010-09-06) 1 commit
 - doc: technical details about the index file format

Half-written but it is a good start.  I may need to give some help in
describing more recent index extensions.

* cb/ignored-paths-are-precious (2010-08-21) 1 commit
 - checkout/merge: optionally fail operation when ignored files need to be overwritten

This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.

It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.

* jk/tag-contains (2010-07-05) 4 commits
 - Why is "git tag --contains" so slow?
 - default core.clockskew variable to one day
 - limit "contains" traversals based on commit timestamp
 - tag: speed up --contains calculation

The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.

* tr/config-doc (2010-10-24) 2 commits
 . Documentation: complete config list from other manpages
 . Documentation: Move variables from config.txt to separate file

This unfortunately heavily conflicts with patches in flight...

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

* rj/maint-difftool-cygwin-workaround (2010-12-14) 1 commit
  (merged to 'next' on 2010-12-21 at 74b9069)
 + difftool: Fix failure on Cygwin

* rj/maint-test-fixes (2010-12-14) 5 commits
  (merged to 'next' on 2010-12-21 at 8883a0c)
 + t9501-*.sh: Fix a test failure on Cygwin
 + lib-git-svn.sh: Add check for mis-configured web server variables
 + lib-git-svn.sh: Avoid setting web server variables unnecessarily
 + t9142: Move call to start_httpd into the setup test
 + t3600-rm.sh: Don't pass a non-existent prereq to test #15

* rj/test-fixes (2010-12-14) 4 commits
 - t4135-*.sh: Skip the "backslash" tests on cygwin
 - t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
 - t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
 - t6038-*.sh: Pass the -b (--binary) option to sed on cygwin

* tr/maint-branch-no-track-head (2010-12-14) 1 commit
 - branch: do not attempt to track HEAD implicitly

Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...).  The latter feels
safer and saner.

* by/log-l (2010-12-14) 8 commits
 . log -L: implement move/copy detection (-M/-C)
 . log -L: add --full-line-diff option
 . log -L: add --graph prefix before output
 . log -L: support parent rewriting
 . Implement line-history search (git log -L)
 . Export rewrite_parents() for 'log -L'
 . Export three functions from diff.c
 . Refactor parse_loc

Seems to have some bad interactions with nd/struct-pathspec.

* hv/mingw-fs-funnies (2010-12-14) 5 commits
 - mingw_rmdir: set errno=ENOTEMPTY when appropriate
 - mingw: add fallback for rmdir in case directory is in use
 - mingw: make failures to unlink or move raise a question
 - mingw: work around irregular failures of unlink on windows
 - mingw: move unlink wrapper to mingw.c

Can somebody remind me what the status of this series is?

* tf/commit-list-prefix (2010-11-26) 1 commit
  (merged to 'next' on 2010-12-21 at 16e1351)
 + commit: Add commit_list prefix in two function names.

This churn already introduced an unnecessary conflict.  It is not by
itself a biggie, but these things tend to add up.

* pd/bash-4-completion (2010-12-15) 3 commits
  (merged to 'next' on 2010-12-21 at dbf80ff)
 + Merge branch 'master' (early part) into pd/bash-4-completion
 + bash: simple reimplementation of _get_comp_words_by_ref
 + bash: get --pretty=m<tab> completion to work with bash v4

* jn/svn-fe (2010-12-06) 18 commits
 - vcs-svn: Allow change nodes for root of tree (/)
 - vcs-svn: Implement Prop-delta handling
 - vcs-svn: Sharpen parsing of property lines
 - vcs-svn: Split off function for handling of individual properties
 - vcs-svn: Make source easier to read on small screens
 - vcs-svn: More dump format sanity checks
 - vcs-svn: Reject path nodes without Node-action
 - vcs-svn: Delay read of per-path properties
 - vcs-svn: Combine repo_replace and repo_modify functions
 - vcs-svn: Replace = Delete + Add
 - vcs-svn: handle_node: Handle deletion case early
 - vcs-svn: Use mark to indicate nodes with included text
 - vcs-svn: Unclutter handle_node by introducing have_props var
 - vcs-svn: Eliminate node_ctx.mark global
 - vcs-svn: Eliminate node_ctx.srcRev global
 - vcs-svn: Check for errors from open()
 - vcs-svn: Allow simple v3 dumps (no deltas yet)
 - vcs-svn: Error out for v3 dumps

Some RFC patches, to give them early and wider exposure.

* nd/maint-fix-add-typo-detection (2010-11-27) 5 commits
  (merged to 'next' on 2010-12-21 at 87c702b)
 + Revert "excluded_1(): support exclude files in index"
 + unpack-trees: fix sparse checkout's "unable to match directories"
 + unpack-trees: move all skip-worktree checks back to unpack_trees()
 + dir.c: add free_excludes()
 + cache.h: realign and use (1 << x) form for CE_* constants

* jh/gitweb-caching (2010-12-03) 4 commits
 . gitweb: Minimal testing of gitweb caching
 . gitweb: File based caching layer (from git.kernel.org)
 . gitweb: add output buffering and associated functions
 . gitweb: Prepare for splitting gitweb

Previous iteration; dropped.

* jh/gitweb-caching-8 (2010-12-09) 18 commits
 . gitweb: Add better error handling for gitweb caching
 . gitweb: Prepare for cached error pages & better error page handling
 . gitweb: When changing output (STDOUT) change STDERR as well
 . gitweb: Add show_warning() to display an immediate warning, with refresh
 . gitweb: add print_transient_header() function for central header printing
 . gitweb: Add commented url & url hash to page footer
 . gitweb: Change file handles (in caching) to lexical variables as opposed to globs
 . gitweb: add isDumbClient() check
 . gitweb: Adding isBinaryAction() and isFeedAction() to determine the action type
 . gitweb: Revert reset_output() back to original code
 . gitweb: Change is_cacheable() to return true always
 . gitweb: Revert back to $cache_enable vs. $caching_enabled
 . gitweb: Add more explicit means of disabling 'Generating...' page
 . gitweb: Regression fix concerning binary output of files
 . gitweb: Minimal testing of gitweb caching
 . gitweb: File based caching layer (from git.kernel.org)
 . gitweb: add output buffering and associated functions
 . gitweb: Prepare for splitting gitweb

It appears that John and Jakub are finally working together to help
producing something that we can ship in-tree, finally.  I am looking
forward to seeing the conclusion of the discussion.

* nd/setup (2010-11-26) 47 commits
 - git.txt: correct where --work-tree path is relative to
 - Revert "Documentation: always respect core.worktree if set"
 - t0001: test git init when run via an alias
 - Remove all logic from get_git_work_tree()
 - setup: rework setup_explicit_git_dir()
 - setup: clean up setup_discovered_git_dir()
 - t1020-subdirectory: test alias expansion in a subdirectory
 - setup: clean up setup_bare_git_dir()
 - setup: limit get_git_work_tree()'s to explicit setup case only
 - Use git_config_early() instead of git_config() during repo setup
 - Add git_config_early()
 - rev-parse: prints --git-dir relative to user's cwd
 - git-rev-parse.txt: clarify --git-dir
 - t1510: setup case #31
 - t1510: setup case #30
 - t1510: setup case #29
 - t1510: setup case #28
 - t1510: setup case #27
 - t1510: setup case #26
 - t1510: setup case #25
 - t1510: setup case #24
 - t1510: setup case #23
 - t1510: setup case #22
 - t1510: setup case #21
 - t1510: setup case #20
 - t1510: setup case #19
 - t1510: setup case #18
 - t1510: setup case #17
 - t1510: setup case #16
 - t1510: setup case #15
 - t1510: setup case #14
 - t1510: setup case #13
 - t1510: setup case #12
 - t1510: setup case #11
 - t1510: setup case #10
 - t1510: setup case #9
 - t1510: setup case #8
 - t1510: setup case #7
 - t1510: setup case #6
 - t1510: setup case #5
 - t1510: setup case #4
 - t1510: setup case #3
 - t1510: setup case #2
 - t1510: setup case #1
 - t1510: setup case #0
 - Add t1510 and basic rules that run repo setup
 - builtins: print setup info if repo is found

Need to re-read this series to move it forward.

* yd/dir-rename (2010-10-29) 5 commits
 - Allow hiding renames of individual files involved in a directory rename.
 - Unified diff output format for bulk moves.
 - Add testcases for the --detect-bulk-moves diffcore flag.
 - Raw diff output format for bulk moves.
 - Introduce bulk-move detection in diffcore.

Need to re-queue the reroll.

* nd/struct-pathspec (2010-12-15) 21 commits
 - t7810: overlapping pathspecs and depth limit
 - grep: drop pathspec_matches() in favor of tree_entry_interesting()
 - grep: use writable strbuf from caller for grep_tree()
 - grep: use match_pathspec_depth() for cache/worktree grepping
 - grep: convert to use struct pathspec
 - Convert ce_path_match() to use match_pathspec_depth()
 - Convert ce_path_match() to use struct pathspec
 - struct rev_info: convert prune_data to struct pathspec
 - pathspec: add match_pathspec_depth()
 - tree_entry_interesting(): optimize wildcard matching when base is matched
 - tree_entry_interesting(): support wildcard matching
 - tree_entry_interesting(): fix depth limit with overlapping pathspecs
 - tree_entry_interesting(): support depth limit
 - tree_entry_interesting(): refactor into separate smaller functions
 - diff-tree: convert base+baselen to writable strbuf
 - glossary: define pathspec
 - Move tree_entry_interesting() to tree-walk.c and export it
 - tree_entry_interesting(): remove dependency on struct diff_options
 - Convert struct diff_options to use struct pathspec
 - diff-no-index: use diff_tree_setup_paths()
 - Add struct pathspec
 (this branch is used by en/object-list-with-pathspec.)

Rerolled again.  Getting nicer by the round ;-)

* en/object-list-with-pathspec (2010-09-20) 2 commits
 - Add testcases showing how pathspecs are handled with rev-list --objects
 - Make rev-list --objects work together with pathspecs
 (this branch uses nd/struct-pathspec.)

* tr/merge-unborn-clobber (2010-08-22) 1 commit
 - Exhibit merge bug that clobbers index&WT

* ab/i18n (2010-10-07) 161 commits
 - po/de.po: complete German translation
 - po/sv.po: add Swedish translation
 - gettextize: git-bisect bisect_next_check "You need to" message
 - gettextize: git-bisect [Y/n] messages
 - gettextize: git-bisect bisect_replay + $1 messages
 - gettextize: git-bisect bisect_reset + $1 messages
 - gettextize: git-bisect bisect_run + $@ messages
 - gettextize: git-bisect die + eval_gettext messages
 - gettextize: git-bisect die + gettext messages
 - gettextize: git-bisect echo + eval_gettext message
 - gettextize: git-bisect echo + gettext messages
 - gettextize: git-bisect gettext + echo message
 - gettextize: git-bisect add git-sh-i18n
 - gettextize: git-stash drop_stash say/die messages
 - gettextize: git-stash "unknown option" message
 - gettextize: git-stash die + eval_gettext $1 messages
 - gettextize: git-stash die + eval_gettext $* messages
 - gettextize: git-stash die + eval_gettext messages
 - gettextize: git-stash die + gettext messages
 - gettextize: git-stash say + gettext messages
 - gettextize: git-stash echo + gettext message
 - gettextize: git-stash add git-sh-i18n
 - gettextize: git-submodule "blob" and "submodule" messages
 - gettextize: git-submodule "path not initialized" message
 - gettextize: git-submodule "[...] path is ignored" message
 - gettextize: git-submodule "Entering [...]" message
 - gettextize: git-submodule $errmsg messages
 - gettextize: git-submodule "Submodule change[...]" messages
 - gettextize: git-submodule "cached cannot be used" message
 - gettextize: git-submodule $update_module say + die messages
 - gettextize: git-submodule die + eval_gettext messages
 - gettextize: git-submodule say + eval_gettext messages
 - gettextize: git-submodule echo + eval_gettext messages
 - gettextize: git-submodule add git-sh-i18n
 - gettextize: git-pull "rebase against" / "merge with" messages
 - gettextize: git-pull "[...] not currently on a branch" message
 - gettextize: git-pull "You asked to pull" message
 - gettextize: git-pull split up "no candidate" message
 - gettextize: git-pull eval_gettext + warning message
 - gettextize: git-pull eval_gettext + die message
 - gettextize: git-pull die messages
 - gettextize: git-pull add git-sh-i18n
 - gettext docs: add "Testing marked strings" section to po/README
 - gettext docs: the Git::I18N Perl interface
 - gettext docs: the git-sh-i18n.sh Shell interface
 - gettext docs: the gettext.h C interface
 - gettext docs: add "Marking strings for translation" section in po/README
 - gettext docs: add a "Testing your changes" section to po/README
 - po/pl.po: add Polish translation
 - po/hi.po: add Hindi Translation
 - po/en_GB.po: add British English translation
 - po/de.po: add German translation
 - Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
 - gettext docs: add po/README file documenting Git's gettext
 - gettextize: git-am printf(1) message to eval_gettext
 - gettextize: git-am core say messages
 - gettextize: git-am "Apply?" message
 - gettextize: git-am clean_abort messages
 - gettextize: git-am cannot_fallback messages
 - gettextize: git-am die messages
 - gettextize: git-am eval_gettext messages
 - gettextize: git-am multi-line getttext $msg; echo
 - gettextize: git-am one-line gettext $msg; echo
 - gettextize: git-am add git-sh-i18n
 - gettext tests: add GETTEXT_POISON tests for shell scripts
 - gettext tests: add GETTEXT_POISON support for shell scripts
 - Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
 - Makefile: add GNU_GETTEXT, set when we expect GNU gettext
 - gettextize: git-shortlog basic messages
 - gettextize: git-revert split up "could not revert/apply" message
 - gettextize: git-revert literal "me" messages
 - gettextize: git-revert "Your local changes" message
 - gettextize: git-revert basic messages
 - gettextize: git-notes "Refusing to %s notes in %s" message
 - gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
 - gettextize: git-notes basic commands
 - gettextize: git-gc "Auto packing the repository" message
 - gettextize: git-gc basic messages
 - gettextize: git-describe basic messages
 - gettextize: git-clean clean.requireForce messages
 - gettextize: git-clean basic messages
 - gettextize: git-bundle basic messages
 - gettextize: git-archive basic messages
 - gettextize: git-status "renamed: " message
 - gettextize: git-status "Initial commit" message
 - gettextize: git-status "Changes to be committed" message
 - gettextize: git-status shortstatus messages
 - gettextize: git-status "nothing to commit" messages
 - gettextize: git-status basic messages
 - gettextize: git-push "prevent you from losing" message
 - gettextize: git-push basic messages
 - gettextize: git-tag tag_template message
 - gettextize: git-tag basic messages
 - gettextize: git-reset "Unstaged changes after reset" message
 - gettextize: git-reset reset_type_names messages
 - gettextize: git-reset basic messages
 - gettextize: git-rm basic messages
 - gettextize: git-mv "bad" messages
 - gettextize: git-mv basic messages
 - gettextize: git-merge "Wonderful" message
 - gettextize: git-merge "You have not concluded your merge" messages
 - gettextize: git-merge "Updating %s..%s" message
 - gettextize: git-merge basic messages
 - gettextize: git-log "--OPT does not make sense" messages
 - gettextize: git-log basic messages
 - gettextize: git-grep "--open-files-in-pager" message
 - gettextize: git-grep basic messages
 - gettextize: git-fetch split up "(non-fast-forward)" message
 - gettextize: git-fetch update_local_ref messages
 - gettextize: git-fetch formatting messages
 - gettextize: git-fetch basic messages
 - gettextize: git-diff basic messages
 - gettextize: git-commit advice messages
 - gettextize: git-commit "enter the commit message" message
 - gettextize: git-commit print_summary messages
 - gettextize: git-commit formatting messages
 - gettextize: git-commit "middle of a merge" message
 - gettextize: git-commit basic messages
 - gettextize: git-checkout "Switched to a .. branch" message
 - gettextize: git-checkout "HEAD is now at" message
 - gettextize: git-checkout describe_detached_head messages
 - gettextize: git-checkout: our/their version message
 - gettextize: git-checkout basic messages
 - gettextize: git-branch "(no branch)" message
 - gettextize: git-branch "git branch -v" messages
 - gettextize: git-branch "Deleted branch [...]" message
 - gettextize: git-branch "remote branch '%s' not found" message
 - gettextize: git-branch basic messages
 - gettextize: git-add refresh_index message
 - gettextize: git-add "remove '%s'" message
 - gettextize: git-add "pathspec [...] did not match" message
 - gettextize: git-add "Use -f if you really want" message
 - gettextize: git-add "no files added" message
 - gettextize: git-add basic messages
 - gettextize: git-clone "Cloning into" message
 - gettextize: git-clone basic messages
 - gettext tests: test message re-encoding under C
 - po/is.po: add Icelandic translation
 - gettext tests: mark a test message as not needing translation
 - gettext tests: test re-encoding with a UTF-8 msgid under Shell
 - gettext tests: test message re-encoding under Shell
 - gettext tests: add detection for is_IS.ISO-8859-1 locale
 - gettext tests: test if $VERSION exists before using it
 - gettextize: git-init "Initialized [...] repository" message
 - gettextize: git-init basic messages
 - gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
 - gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
 - gettext.c: use libcharset.h instead of langinfo.h when available
 - gettext.c: work around us not using setlocale(LC_CTYPE, "")
 - builtin.h: Include gettext.h
 - Makefile: use variables and shorter lines for xgettext
 - Makefile: tell xgettext(1) that our source is in UTF-8
 - Makefile: provide a --msgid-bugs-address to xgettext(1)
 - Makefile: A variable for options used by xgettext(1) calls
 - gettext tests: locate i18n lib&data correctly under --valgrind
 - gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
 - gettext tests: rename test to work around GNU gettext bug
 - gettext: add infrastructure for translating Git with gettext
 - builtin: use builtin.h for all builtin commands
 - tests: use test_cmp instead of piping to diff(1)
 - t7004-tag.sh: re-arrange git tag comment for clarity

It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.

Needs a bit more minor work to get the basic code structure right.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22  1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
@ 2010-12-22 11:05 ` Thiago Farina
  2010-12-22 11:39   ` Andreas Ericsson
  2010-12-22 20:48   ` Junio C Hamano
  2010-12-23 15:52 ` Heiko Voigt
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 17+ messages in thread
From: Thiago Farina @ 2010-12-22 11:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * tf/commit-list-prefix (2010-11-26) 1 commit
>  (merged to 'next' on 2010-12-21 at 16e1351)
>  + commit: Add commit_list prefix in two function names.
>
> This churn
Since you said that, can could you drop this patch? I don't mind if
you discard this patch since you consider it a CHURN[1].

> already introduced an unnecessary conflict.
Which conflict? If you say, I could try to fix it.

> It is not by itself a biggie, but these things tend to add up.

How *these things* add a conflict? This is a new thing to me really.

[1] Hope I will learn what this means and avoid it, something like,
unnecessary, stupid, really trivial, etc...

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22 11:05 ` Thiago Farina
@ 2010-12-22 11:39   ` Andreas Ericsson
  2010-12-22 20:48   ` Junio C Hamano
  1 sibling, 0 replies; 17+ messages in thread
From: Andreas Ericsson @ 2010-12-22 11:39 UTC (permalink / raw)
  To: Thiago Farina; +Cc: Junio C Hamano, git

On 12/22/2010 12:05 PM, Thiago Farina wrote:
> 
> [1] Hope I will learn what this means and avoid it, something like,
> unnecessary, stupid, really trivial, etc...

churn:
Work for little or no benefit.
A patch that adds little or no value to the codebase by itself.

A patch that fixes a problem that isn't there in the real world but
could be there if some system somewhere followed some obscure standard
to the very letter is a typical example of code-churn.

A patch that introduces an poorly thought-out feature that nobody uses
is another common example, as is modifying code to accommodate adding
undefined features later. If the code-modifying is promptly followed
by a patch to introduce a new feature that relies on the new behaviour,
it's not considered churn since the new feature is already defined.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22 11:05 ` Thiago Farina
  2010-12-22 11:39   ` Andreas Ericsson
@ 2010-12-22 20:48   ` Junio C Hamano
  2010-12-22 23:08     ` Thiago Farina
  1 sibling, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2010-12-22 20:48 UTC (permalink / raw)
  To: Thiago Farina; +Cc: git

Thiago Farina <tfransosi@gmail.com> writes:

> On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * tf/commit-list-prefix (2010-11-26) 1 commit
>>  (merged to 'next' on 2010-12-21 at 16e1351)
>>  + commit: Add commit_list prefix in two function names.
>>
>> This churn
> Since you said that, can could you drop this patch? I don't mind if
> you discard this patch since you consider it a CHURN[1].
>
>> already introduced an unnecessary conflict.
> Which conflict? If you say, I could try to fix it.
>
>> It is not by itself a biggie, but these things tend to add up.
>
> How *these things* add a conflict? This is a new thing to me really.

Look at output from "git show 16e1351 sha1_name.c".

The damage (i.e. my time wasted to deal with the conflict resulting from
the rename of the function) has already been done.  There is nothing to
fix.

One thing you _could_ fix is to keep an eye on what are cooking (e.g. the
diff between maint and pu), and refrain from throwing "trivial clean-up"
patches that may overlap with them at the list until the dust settles.
That would greatly reduce the annoyance factor.

The same comment applies to your patches to reduce use of alloc_nr().  If
absolutely nothing else is going on in the project, these are genuinely
good clean-up patches, but when other patches that give us real-life
benefit are in flight, just having to check if they overlap with whatever
is cooking now is already annoying.

Thanks.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22 20:48   ` Junio C Hamano
@ 2010-12-22 23:08     ` Thiago Farina
  0 siblings, 0 replies; 17+ messages in thread
From: Thiago Farina @ 2010-12-22 23:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Dec 22, 2010 at 6:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * tf/commit-list-prefix (2010-11-26) 1 commit
>>>  (merged to 'next' on 2010-12-21 at 16e1351)
>>>  + commit: Add commit_list prefix in two function names.
>>>
>>> This churn
>> Since you said that, can could you drop this patch? I don't mind if
>> you discard this patch since you consider it a CHURN[1].
>>
>>> already introduced an unnecessary conflict.
>> Which conflict? If you say, I could try to fix it.
>>
>>> It is not by itself a biggie, but these things tend to add up.
>>
>> How *these things* add a conflict? This is a new thing to me really.
>
> Look at output from "git show 16e1351 sha1_name.c".
>
> The damage (i.e. my time wasted to deal with the conflict resulting from
> the rename of the function) has already been done.  There is nothing to
> fix.
>
> One thing you _could_ fix is to keep an eye on what are cooking (e.g. the
> diff between maint and pu), and refrain from throwing "trivial clean-up"
That should be the pain of being the maintainer. You have to deal with
this, like I have to deal with all the critics too.

> patches that may overlap with them at the list until the dust settles.
The dust never settles in this mailing list.

> That would greatly reduce the annoyance factor.
>
> The same comment applies to your patches to reduce use of alloc_nr().  If
> absolutely nothing else is going on in the project,
Which is impossible, due to the high traffic that this project attracts.

> these are genuinely good clean-up patches, but when other patches that give us real-life benefit are in flight,
Well, I'd say to just ignore it as you have done many times before.

> just having to check if they overlap with whatever
> is cooking now is already annoying.
>
What I can do if you are the ONLY one that has commit access to this project.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22  1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
  2010-12-22 11:05 ` Thiago Farina
@ 2010-12-23 15:52 ` Heiko Voigt
  2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
  2010-12-26 10:46 ` Thomas Rast
  3 siblings, 0 replies; 17+ messages in thread
From: Heiko Voigt @ 2010-12-23 15:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi,

On Tue, Dec 21, 2010 at 05:59:54PM -0800, Junio C Hamano wrote:
> * hv/mingw-fs-funnies (2010-12-14) 5 commits
>  - mingw_rmdir: set errno=ENOTEMPTY when appropriate
>  - mingw: add fallback for rmdir in case directory is in use
>  - mingw: make failures to unlink or move raise a question
>  - mingw: work around irregular failures of unlink on windows
>  - mingw: move unlink wrapper to mingw.c
> 
> Can somebody remind me what the status of this series is?

Still dicussing and preparing a new series. I hope I will get to answer
and send the new series soon.

Cheers Heiko

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22  1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
  2010-12-22 11:05 ` Thiago Farina
  2010-12-23 15:52 ` Heiko Voigt
@ 2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
  2010-12-23 17:17   ` Junio C Hamano
  2010-12-26 10:46 ` Thomas Rast
  3 siblings, 1 reply; 17+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2010-12-23 16:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/struct-pathspec (2010-12-15) 21 commits
>  ...
>  (this branch is used by en/object-list-with-pathspec.)
>
> Rerolled again.  Getting nicer by the round ;-)

With jj/icase-directory merged to master, match_pathspec() and
match_pathspec_depth() now diverse again.

When I wrote match_pathspec_depth(), I assumed that match_pathspec()
would not change much and I would have more time for converting the
rest of git to use match_*_depth(). Looks like I need to add case
insensitive matching to struct pathspec and friends then remove
match_pathspec() in this series too. At least if somebody changes
match_pathspec() again, it would cause a conflict so I can catch it.
-- 
Duy

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
@ 2010-12-23 17:17   ` Junio C Hamano
  2010-12-23 23:35     ` Joshua Jensen
  2010-12-24  1:33     ` Nguyen Thai Ngoc Duy
  0 siblings, 2 replies; 17+ messages in thread
From: Junio C Hamano @ 2010-12-23 17:17 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: git

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/struct-pathspec (2010-12-15) 21 commits
>>  ...
>>  (this branch is used by en/object-list-with-pathspec.)
>>
>> Rerolled again.  Getting nicer by the round ;-)
>
> With jj/icase-directory merged to master, match_pathspec() and
> match_pathspec_depth() now diverse again.
>
> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
> would not change much and I would have more time for converting the
> rest of git to use match_*_depth(). Looks like I need to add case
> insensitive matching to struct pathspec and friends then remove
> match_pathspec() in this series too. At least if somebody changes
> match_pathspec() again, it would cause a conflict so I can catch it.

While this topic is something I have long wanted to see, I have started
feeling that this needs to cook a bit longer than be in the next release.
So perhaps the best course of action might be to rebase the series once
after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
part of the release after that.  I think at that point we may probably
want to have other changes that are not strictly backward compatible but
their incompatibilities do not matter in practice (e.g. cquoting pathspecs
in the attributes file comes to mind, but I am sure there will be other
changes that people wanted to have but we held them off due to worries on
compatibility).

What do you think?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-23 17:17   ` Junio C Hamano
@ 2010-12-23 23:35     ` Joshua Jensen
  2010-12-24  1:39       ` Nguyen Thai Ngoc Duy
  2010-12-24 19:23       ` Junio C Hamano
  2010-12-24  1:33     ` Nguyen Thai Ngoc Duy
  1 sibling, 2 replies; 17+ messages in thread
From: Joshua Jensen @ 2010-12-23 23:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git

----- Original Message -----
From: Junio C Hamano
Date: 12/23/2010 10:17 AM
> Nguyen Thai Ngoc Duy<pclouds@gmail.com>  writes:
>
>> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano<gitster@pobox.com>  wrote:
>> With jj/icase-directory merged to master, match_pathspec() and
>> match_pathspec_depth() now diverse again.
>>
>> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
>> would not change much and I would have more time for converting the
>> rest of git to use match_*_depth(). Looks like I need to add case
>> insensitive matching to struct pathspec and friends then remove
>> match_pathspec() in this series too. At least if somebody changes
>> match_pathspec() again, it would cause a conflict so I can catch it.
> While this topic is something I have long wanted to see, I have started
> feeling that this needs to cook a bit longer than be in the next release.
> So perhaps the best course of action might be to rebase the series once
> after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
> part of the release after that.  I think at that point we may probably
> want to have other changes that are not strictly backward compatible but
> their incompatibilities do not matter in practice (e.g. cquoting pathspecs
> in the attributes file comes to mind, but I am sure there will be other
> changes that people wanted to have but we held them off due to worries on
> compatibility).
>
> What do you think?
Certainly, you know what's best overall for Git.

Having said that, I have had 100 people using the jj/icase-directory 
series on Windows daily for 4 months now without issue.  Prior to that, 
a majority of the series had been used for a full year by a dozen 
people.  In any case, the improvement on non-case sensitive file systems 
is the difference between night and day, and the series has helped 
prevent a number of messes that occurred without it (git add readme.txt 
and git add Readme.txt, for example... ugh...).

More than Windows, this series also affects Mac OS X in a positive 
manner, though the case sensitivity problems can be considered worse.  
When you change directories at the command line, the command line 
retains the case you used to change directory, and then Git uses that 
case as the relative path into the repository.  Ugh... this is different 
than on Windows where the file system's directory case is retained at 
the Command Prompt as you change directories.  (Cygwin actually appears 
to have the problem, too, but MinGW, what msysGit is built upon, does not.)

The Mac OS X issue listed above is not a reason not to publish the 
series, though, as the fixes necessary to make that work are in 
completely different areas in Git than the current jj/icase-directory 
series.

Finally, I'm sitting on a bunch of other case sensitivity refinements, 
but I'd like to get one series published before evolving this more.  I'd 
like to get the other ones out there for discussion, but they build on 
the current series.

In reference to above, where is match_pathspec_depth()?  I can only find 
match_pathspec().

Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-23 17:17   ` Junio C Hamano
  2010-12-23 23:35     ` Joshua Jensen
@ 2010-12-24  1:33     ` Nguyen Thai Ngoc Duy
  1 sibling, 0 replies; 17+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2010-12-24  1:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Fri, Dec 24, 2010 at 12:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * nd/struct-pathspec (2010-12-15) 21 commits
>>>  ...
>>>  (this branch is used by en/object-list-with-pathspec.)
>>>
>>> Rerolled again.  Getting nicer by the round ;-)
>>
>> With jj/icase-directory merged to master, match_pathspec() and
>> match_pathspec_depth() now diverse again.
>>
>> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
>> would not change much and I would have more time for converting the
>> rest of git to use match_*_depth(). Looks like I need to add case
>> insensitive matching to struct pathspec and friends then remove
>> match_pathspec() in this series too. At least if somebody changes
>> match_pathspec() again, it would cause a conflict so I can catch it.
>
> While this topic is something I have long wanted to see, I have started
> feeling that this needs to cook a bit longer than be in the next release.
> So perhaps the best course of action might be to rebase the series once
> after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
> part of the release after that.  I think at that point we may probably
> want to have other changes that are not strictly backward compatible but
> their incompatibilities do not matter in practice (e.g. cquoting pathspecs
> in the attributes file comes to mind, but I am sure there will be other
> changes that people wanted to have but we held them off due to worries on
> compatibility).
>
> What do you think?
>

No problem.
-- 
Duy

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-23 23:35     ` Joshua Jensen
@ 2010-12-24  1:39       ` Nguyen Thai Ngoc Duy
  2010-12-24 16:53         ` Joshua Jensen
  2010-12-24 19:23       ` Junio C Hamano
  1 sibling, 1 reply; 17+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2010-12-24  1:39 UTC (permalink / raw)
  To: Joshua Jensen; +Cc: Junio C Hamano, git

On Fri, Dec 24, 2010 at 6:35 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> Having said that, I have had 100 people using the jj/icase-directory series
> on Windows daily for 4 months now without issue.  Prior to that, a majority
> of the series had been used for a full year by a dozen people.  In any case,
> the improvement on non-case sensitive file systems is the difference between
> night and day, and the series has helped prevent a number of messes that
> occurred without it (git add readme.txt and git add Readme.txt, for
> example... ugh...).
>
> More than Windows, this series also affects Mac OS X in a positive manner,
> though the case sensitivity problems can be considered worse.  When you
> change directories at the command line, the command line retains the case
> you used to change directory, and then Git uses that case as the relative
> path into the repository.  Ugh... this is different than on Windows where
> the file system's directory case is retained at the Command Prompt as you
> change directories.  (Cygwin actually appears to have the problem, too, but
> MinGW, what msysGit is built upon, does not.)
>
> The Mac OS X issue listed above is not a reason not to publish the series,
> though, as the fixes necessary to make that work are in completely different
> areas in Git than the current jj/icase-directory series.
>
> Finally, I'm sitting on a bunch of other case sensitivity refinements, but
> I'd like to get one series published before evolving this more.  I'd like to
> get the other ones out there for discussion, but they build on the current
> series.

If you have not known already, path in "git log ref -- path" must be
case sensitive. Solving that is not hard: ce_path_match() and
tree_entry_interesting() are the ones that do path matching. Those
functions are nearly replaced in this series. I'll add
case-insensitive support to them, so you can worry about other places.

> In reference to above, where is match_pathspec_depth()?  I can only find
> match_pathspec().

 Introduced in this series, nd/setup.
-- 
Duy

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-24  1:39       ` Nguyen Thai Ngoc Duy
@ 2010-12-24 16:53         ` Joshua Jensen
  2010-12-25  2:20           ` Nguyen Thai Ngoc Duy
  0 siblings, 1 reply; 17+ messages in thread
From: Joshua Jensen @ 2010-12-24 16:53 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git

----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 12/23/2010 6:39 PM
> If you have not known already, path in "git log ref -- path" must be
> case sensitive. Solving that is not hard: ce_path_match() and
> tree_entry_interesting() are the ones that do path matching. Those
> functions are nearly replaced in this series. I'll add
> case-insensitive support to them, so you can worry about other places.
As I recall (I'd have to examine other unsubmitted case insensitivity 
patches), merely adding case insensitivity support to ce_path_match() is 
not enough.  The cache is stored alphabetically in a case sensitive 
fashion.  That means filenames starting with 'A' are stored in a 
completely different place than filenames starting with 'a'.  Certain 
parts of the code call ce_path_match() and then walk the cache 
sequentially for possible matches.  It aborts long before hitting the 
'a' filename.

I have a patch that appears to resolve most of these issues.  For 
core.ignorecase=true, when the cache is read, it is re-sorted 
alphabetically in a case insensitive manner.  ce_path_match() still 
needs fixes, but the rest were covered by the case insensitive cache.  
'A' and 'a' are not interleaved, and the combination of sequential and 
binary(?) searches Git uses are successful.  Finally, when the cache is 
written, I re-sort the cache in a case insensitive fashion.

Hmmm... I think this was also needed for the *_name_compare() functions, 
too.

Anyway, just something to consider.

Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-23 23:35     ` Joshua Jensen
  2010-12-24  1:39       ` Nguyen Thai Ngoc Duy
@ 2010-12-24 19:23       ` Junio C Hamano
  2010-12-24 20:02         ` Joshua Jensen
  1 sibling, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2010-12-24 19:23 UTC (permalink / raw)
  To: Joshua Jensen; +Cc: Nguyen Thai Ngoc Duy, git

Joshua Jensen <jjensen@workspacewhiz.com> writes:

> From: Junio C Hamano
> Date: 12/23/2010 10:17 AM
>> Nguyen Thai Ngoc Duy<pclouds@gmail.com>  writes:
>>
>>> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano<gitster@pobox.com>  wrote:
>>> With jj/icase-directory merged to master, match_pathspec() and
>>> match_pathspec_depth() now diverse again.
>>>
>>> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
>>> would not change much and I would have more time for converting the
>>> rest of git to use match_*_depth(). Looks like I need to add case
>>> insensitive matching to struct pathspec and friends then remove
>>> match_pathspec() in this series too. At least if somebody changes
>>> match_pathspec() again, it would cause a conflict so I can catch it.
>> While this topic is something I have long wanted to see, I have started
>> feeling that this needs to cook a bit longer than be in the next release.
>> So perhaps the best course of action might be to rebase the series once
>> after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
>> part of the release after that.  I think at that point we may probably
>> want to have other changes that are not strictly backward compatible but
>> their incompatibilities do not matter in practice (e.g. cquoting pathspecs
>> in the attributes file comes to mind, but I am sure there will be other
>> changes that people wanted to have but we held them off due to worries on
>> compatibility).
>>
>> What do you think?
> ...
> Having said that, I have had 100 people using the jj/icase-directory
> series on Windows daily for 4 months now without issue.  Prior to
> that, a majority of the series had been used for a full year by a
> dozen people....

Just to make sure nobody misunderstood me, what I was proposing to put on
hold was not the "case insensitivity" work of yours, which is already
scheduled to be part of the coming release.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-24 19:23       ` Junio C Hamano
@ 2010-12-24 20:02         ` Joshua Jensen
  0 siblings, 0 replies; 17+ messages in thread
From: Joshua Jensen @ 2010-12-24 20:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git

----- Original Message -----
From: Junio C Hamano
Date: 12/24/2010 12:23 PM
> Joshua Jensen<jjensen@workspacewhiz.com>  writes:
>
>> Having said that, I have had 100 people using the jj/icase-directory
>> series on Windows daily for 4 months now without issue.  Prior to
>> that, a majority of the series had been used for a full year by a
>> dozen people....
> Just to make sure nobody misunderstood me, what I was proposing to put on
> hold was not the "case insensitivity" work of yours, which is already
> scheduled to be part of the coming release.
Ah.  I completely misinterpreted your statement.

Well, that's exciting.  After it goes live, I'll have some more case 
insensitivity patches forthcoming for discussion.

-Josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-24 16:53         ` Joshua Jensen
@ 2010-12-25  2:20           ` Nguyen Thai Ngoc Duy
  0 siblings, 0 replies; 17+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2010-12-25  2:20 UTC (permalink / raw)
  To: Joshua Jensen; +Cc: Junio C Hamano, git

On Fri, Dec 24, 2010 at 11:53 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> As I recall (I'd have to examine other unsubmitted case insensitivity
> patches), merely adding case insensitivity support to ce_path_match() is not
> enough.  The cache is stored alphabetically in a case sensitive fashion.
>  That means filenames starting with 'A' are stored in a completely different
> place than filenames starting with 'a'.  Certain parts of the code call
> ce_path_match() and then walk the cache sequentially for possible matches.
>  It aborts long before hitting the 'a' filename.

Hmm.. what you describe sounds like never_interesting optimization in
tree_entry_interesting(). By the way do you still remember the parts
that it walk sequentially after ce_path_match() is matched?

> I have a patch that appears to resolve most of these issues.  For
> core.ignorecase=true, when the cache is read, it is re-sorted alphabetically
> in a case insensitive manner.  ce_path_match() still needs fixes, but the
> rest were covered by the case insensitive cache.  'A' and 'a' are not
> interleaved, and the combination of sequential and binary(?) searches Git
> uses are successful.  Finally, when the cache is written, I re-sort the
> cache in a case insensitive fashion.

Resorting the cache is quite risky. Many parts of git depend on the
cache being sorted as it is now. Also if you go this way, then you
will also need to resort tree objects (git-log walks them directly).
-- 
Duy

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-22  1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
                   ` (2 preceding siblings ...)
  2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
@ 2010-12-26 10:46 ` Thomas Rast
  2010-12-26 19:28   ` Junio C Hamano
  3 siblings, 1 reply; 17+ messages in thread
From: Thomas Rast @ 2010-12-26 10:46 UTC (permalink / raw)
  To: Yann Dirson; +Cc: Junio C Hamano, git

Junio C Hamano wrote:
> * yd/dir-rename (2010-10-29) 5 commits
>  - Allow hiding renames of individual files involved in a directory rename.
>  - Unified diff output format for bulk moves.
>  - Add testcases for the --detect-bulk-moves diffcore flag.
>  - Raw diff output format for bulk moves.
>  - Introduce bulk-move detection in diffcore.
> 
> Need to re-queue the reroll.

This BTW does not even compile on OS X because of its use of memrchr.

(I recently set up a Darwin 10.5 smoke tester that reports to Ævar's
site.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
  2010-12-26 10:46 ` Thomas Rast
@ 2010-12-26 19:28   ` Junio C Hamano
  0 siblings, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2010-12-26 19:28 UTC (permalink / raw)
  To: Thomas Rast; +Cc: Yann Dirson, git

Thomas Rast <trast@student.ethz.ch> writes:

> Junio C Hamano wrote:
>> * yd/dir-rename (2010-10-29) 5 commits
>>  - Allow hiding renames of individual files involved in a directory rename.
>>  - Unified diff output format for bulk moves.
>>  - Add testcases for the --detect-bulk-moves diffcore flag.
>>  - Raw diff output format for bulk moves.
>>  - Introduce bulk-move detection in diffcore.
>> 
>> Need to re-queue the reroll.
>
> This BTW does not even compile on OS X because of its use of memrchr.

Thanks for an early warning.  I am planning to do an 1.7.4-rc0 soon
anyway, so in the meantime I'd drop this and wait for a resubmission for
the next round (I think I saw a larger re-roll that I didn't pick up).

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2010-12-26 19:28 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-22  1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
2010-12-22 11:05 ` Thiago Farina
2010-12-22 11:39   ` Andreas Ericsson
2010-12-22 20:48   ` Junio C Hamano
2010-12-22 23:08     ` Thiago Farina
2010-12-23 15:52 ` Heiko Voigt
2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
2010-12-23 17:17   ` Junio C Hamano
2010-12-23 23:35     ` Joshua Jensen
2010-12-24  1:39       ` Nguyen Thai Ngoc Duy
2010-12-24 16:53         ` Joshua Jensen
2010-12-25  2:20           ` Nguyen Thai Ngoc Duy
2010-12-24 19:23       ` Junio C Hamano
2010-12-24 20:02         ` Joshua Jensen
2010-12-24  1:33     ` Nguyen Thai Ngoc Duy
2010-12-26 10:46 ` Thomas Rast
2010-12-26 19:28   ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.