What's in "What's cooking"

What's in "What's cooking"

[Junio C Hamano]

Here is a note to explain various sections and what the readers on
this list are expected to read from them in the periodic "What's
cooking" summary.  This probably should be integrated in the
periodic "A note from the maintainer" posting eventually.

The first part is mostly a boilerplate message, but the second
paragraph of it often explains where in the development cycle we
are.  The last one (issue #4 of this month) said:

   Trivially correct fixes to old bugs may still graduate to 'master',
   but otherwise we are mostly in "regression fixes only" mode until
   1.7.10 final (see http://tinyurl.com/gitCal for schedule).

The preamble is followed by various sections, each listing topics in
different "doneness".

Each topic looks like this:

  * cn/pull-rebase-message (2012-03-04) 1 commit
    (merged to 'next' on 2012-03-04 at 5a6cd58)
   + Make git-{pull,rebase} message without tracking information friendlier

  The advise message given when the user didn't give enough clue on what
  to merge was overly long.
  Will merge to 'master'.

A line that begins with a '*' has the name of a topic, the date of
the last activity on the topic and the number of changes in the
topic.  Then each commit on the topic is listed with prefix ("+",
"-" or ".").  The ones with "+" are already on 'next', and the dates
when they were merged to 'next' also appear on this list. This will
give readers the rough idea of how long the topic has been cooking
in 'next' (the branch active bug hunters and early adopters are
expected to be running) to measure the "doneness".

The list of commits on the topic is often followed by a few lines of
free-form text to summarize what the topic aims to achieve. This
often goes literally to the draft release notes when the topic
graduates to 'master'.  Also I annotate my short-term plan for the
topic ("Will merge to 'master' in the above example); it is very
much appreciated if readers raise timely objections to this plan
(e.g. "Don't merge it yet, it is broken --- see that discussion
thread").

The [New topics] section lists topics that were not in my tree when
the previous issue of "What's cooking" was sent.

The [Graduated to "master"] section lists topics that have been
merged to 'master' since the previous issue. Even if you are not an
active bug hunter, please exercise the features/fixes these topics
brings to the system, as breakages or regressions caused by these
will appear in the next release if they are not noticed and fixed.

The [Stalled] section lists topics whose discussion has stalled, or
re-rolled patches have not been seen for a while after the topic
received review comments. This section is listed here so that people
interested in the topics in it can help the owners of them to move
things forward.

The [Cooking] section lists the remainder of the topics. They are
making normal progress and are no cause for worries in general.
Those whose commits are all in "next" are often just simmering to
give time to active bug hunters find unexpected problem in them.
those whose commits are not in "next" yet are still going through
review/revise cycle until they become ready.

What's cooking in git.git (Aug 2013, #01; Thu, 1)

[Junio C Hamano]

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

The first release candidate v1.8.4-rc1 has been tagged; only
regression fixes and l10n updates from now on.

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"]

* jc/rm-submodule-error-message (2013-07-25) 1 commit
 + builtin/rm.c: consolidate error reporting for removing submodules


* jx/clean-interactive (2013-07-24) 2 commits
  (merged to 'next' on 2013-07-30 at b7fd474)
 + git-clean: implement partial matching for selection
  (merged to 'next' on 2013-07-24 at 1e63bb9)
 + Documentation/git-clean: fix description for range


* lf/echo-n-is-not-portable (2013-07-29) 1 commit
  (merged to 'next' on 2013-07-30 at e223ceb)
 + Avoid using `echo -n` anywhere


* ma/hg-to-git (2013-07-23) 1 commit
  (merged to 'next' on 2013-07-30 at 1dddc06)
 + hg-to-git: --allow-empty-message in git commit


* ms/subtree-install-fix (2013-07-30) 1 commit
 + contrib/subtree: Fix make install target


* ob/typofixes (2013-07-29) 1 commit
  (merged to 'next' on 2013-07-30 at ec2c897)
 + many small typofixes

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

* mb/docs-favor-en-us (2013-08-01) 1 commit
 - Provide some linguistic guidance for the documentation.

 Will merge to and cook in 'next'.


* jc/parseopt-command-modes (2013-07-30) 2 commits
 - tag: use OPT_CMDMODE
 - parse-options: add OPT_CMDMODE()

 Many commands use --dashed-option as a operation mode selector
 (e.g. "git tag --delete") that the user can use at most one
 (e.g. "git tag --delete --verify" is a nonsense) and you cannot
 negate (e.g. "git tag --no-delete" is a nonsense).  Make it easier
 for users of parse_options() to enforce these restrictions.

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

* tf/gitweb-ss-tweak (2013-07-15) 4 commits
 - gitweb: make search help link less ugly
 - gitweb: omit the repository owner when it is unset
 - gitweb: vertically centre contents of page footer
 - gitweb: ensure OPML text fits inside its box

 Comments?


* rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits
 - ### DONTMERGE: needs better explanation on what config they need
 - pack-refs.c: Add missing call to git_config()
 - show-ref.c: Add missing call to git_config()

 The changes themselves are probably good, but it is unclear what
 basic setting needs to be read for which exact operation.

 Waiting for clarification.
 $gmane/228294


* 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.
 $gmane/225137


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

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

 Seems to break some tests in a trivial and obvious way.


* 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; kicked back to 'pu'.


* 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


* jc/show-branch (2013-06-07) 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

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

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

* tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
 - log: use true parents for diff even when rewriting

 Output from "git log --full-diff -- <pathspec>" looked strange,
 because comparison was done with the previous ancestor that touched
 the specified <pathspec>, causing the patches for paths outside the
 pathspec to show more than the single commit has changed.

 I am not sure if that is necessarily a problem, though.  Output
 from "git log --full-diff -2 -- <pathspec>" without this change
 will be applicable to some codebase, but after this change that
 will no longer be true (you will get only tiny parts of the change
 that were made by the two commits in question, while missing all
 the other changes).


* bc/unuse-packfile (2013-08-01) 2 commits
 - Don't close pack fd when free'ing pack windows
 - sha1_file: introduce close_one_pack() to close packs on fd pressure

 Will merge to and cook in 'next'.


* da/darwin (2013-07-30) 1 commit
  (merged to 'next' on 2013-08-01 at d151a94)
 + imap-send: use Apple's Security framework for base64 encoding

 Will cook in 'next'.


* nd/sq-quote-buf (2013-07-30) 3 commits
  (merged to 'next' on 2013-08-01 at dc7934a)
 + quote: remove sq_quote_print()
 + tar-tree: remove dependency on sq_quote_print()
 + for-each-ref, quote: convert *_quote_print -> *_quote_buf

 Code simplification as a preparatory step to something larger.

 Will cook in 'next'.


* jc/url-match (2013-07-31) 6 commits
 - config: "git config --get-urlmatch" parses section.<url>.key
 - builtin/config: refactor collect_config()
 - config: parse http.<url>.<variable> using urlmatch
 - config: add generic callback wrapper to parse section.<url>.key
 - config: add helper to normalize and match URLs
 - http.c: fix parsing of http.sslCertPasswordProtected variable

 Reroll of km/http-curl-config-per-url topic.  Peff raises many good
 points about the tests for http.* variables.

 Waiting for the discussion to conclude, hopefully with a replacement test.


* jl/submodule-mv (2013-07-30) 5 commits
 - rm: delete .gitmodules entry of submodules removed from the work tree
 - mv: update the path entry in .gitmodules for moved submodules
 - submodule.c: add .gitmodules staging helper functions
 - mv: move submodules using a gitfile
 - mv: move submodules together with their work trees
 (this branch uses nd/magic-pathspec.)

 "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.


* nd/clone-connectivity-shortcut (2013-07-23) 1 commit
  (merged to 'next' on 2013-07-30 at 8d16721)
 + smart http: use the same connectivity check on cloning

 Will cook in 'next'.


* db/http-savecookies (2013-07-30) 1 commit
  (merged to 'next' on 2013-07-30 at d2ad6e5)
 + http: add http.savecookies option to write out HTTP cookies

 Will cook in 'next'.


* sb/fsck-opt-bool (2013-07-29) 1 commit
  (merged to 'next' on 2013-07-30 at 8a9964c)
 + fsck: Replace deprecated OPT_BOOLEAN by OPT_BOOL

 Will cook in 'next'.


* rr/feed-real-path-to-editor (2013-07-29) 1 commit
  (merged to 'next' on 2013-07-30 at 72c9bcb)
 + editor: use canonicalized absolute path

 Will cook in 'next'.


* rj/doc-rev-parse (2013-07-22) 2 commits
  (merged to 'next' on 2013-07-22 at 8188667)
 + rev-parse(1): logically group options
 + rev-parse: remove restrictions on some options

 Will cook in 'next'.


* jk/fast-import-empty-ls (2013-06-23) 4 commits
  (merged to 'next' on 2013-07-22 at d26dab6)
 + fast-import: allow moving the root tree
 + fast-import: allow ls or filecopy of the root tree
 + fast-import: set valid mode on root tree in "ls"
 + t9300: document fast-import empty path issues

 Will cook in 'next'.


* jc/diff-filter-negation (2013-07-19) 6 commits
  (merged to 'next' on 2013-07-22 at 80d167d)
 + diff: deprecate -q option to diff-files
 + diff: allow lowercase letter to specify what change class to exclude
 + diff: reject unknown change class given to --diff-filter
 + diff: preparse --diff-filter string argument
 + diff: factor out match_filter()
 + diff: pass the whole diff_options to diffcore_apply_filter()
 (this branch is used by jc/hold-diff-remove-q-synonym-for-no-deletion.)

 Teach "git diff --diff-filter" to express "I do not want to see
 these classes of changes" more directly by listing only the
 unwanted ones in lowercase (e.g. "--diff-filter=d" will show
 everything but deletion) and deprecate "diff-files -q" which did
 the same thing as "--diff-filter=d".

 Will cook in 'next'.


* nd/magic-pathspec (2013-07-23) 48 commits
  (merged to 'next' on 2013-07-23 at 784c3a1)
 + rm: do not set a variable twice without intermediate reading.
  (merged to 'next' on 2013-07-22 at 39f7194)
 + t6131 - skip tests if on case-insensitive file system
 + parse_pathspec: accept :(icase)path syntax
 + pathspec: support :(glob) syntax
 + pathspec: make --literal-pathspecs disable pathspec magic
 + pathspec: support :(literal) syntax for noglob pathspec
 + kill limit_pathspec_to_literal() as it's only used by parse_pathspec()
 + parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN
 + parse_pathspec: make sure the prefix part is wildcard-free
 + rename field "raw" to "_raw" in struct pathspec
 + tree-diff: remove the use of pathspec's raw[] in follow-rename codepath
 + remove match_pathspec() in favor of match_pathspec_depth()
 + remove init_pathspec() in favor of parse_pathspec()
 + remove diff_tree_{setup,release}_paths
 + convert common_prefix() to use struct pathspec
 + convert add_files_to_cache to take struct pathspec
 + convert {read,fill}_directory to take struct pathspec
 + convert refresh_index to take struct pathspec
 + convert report_path_error to take struct pathspec
 + checkout: convert read_tree_some to take struct pathspec
 + convert unmerge_cache to take struct pathspec
 + convert run_add_interactive to use struct pathspec
 + convert read_cache_preload() to take struct pathspec
 + line-log: convert to use parse_pathspec
 + reset: convert to use parse_pathspec
 + add: convert to use parse_pathspec
 + check-ignore: convert to use parse_pathspec
 + archive: convert to use parse_pathspec
 + ls-files: convert to use parse_pathspec
 + rm: convert to use parse_pathspec
 + checkout: convert to use parse_pathspec
 + rerere: convert to use parse_pathspec
 + status: convert to use parse_pathspec
 + commit: convert to use parse_pathspec
 + clean: convert to use parse_pathspec
 + guard against new pathspec magic in pathspec matching code
 + parse_pathspec: support prefixing original patterns
 + parse_pathspec: support stripping/checking submodule paths
 + parse_pathspec: support stripping submodule trailing slashes
 + parse_pathspec: add special flag for max_depth feature
 + convert some get_pathspec() calls to parse_pathspec()
 + parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL} flags
 + parse_pathspec: save original pathspec for reporting
 + add parse_pathspec() that converts cmdline args to struct pathspec
 + pathspec: add copy_pathspec
 + pathspec: i18n-ize error strings in pathspec parsing code
 + move struct pathspec and related functions to pathspec.[ch]
 + clean: remove unused variable "seen"
 (this branch is used by jl/submodule-mv.)

 Use "struct pathspec" interface in more places, instead of array of
 characters, the latter of which cannot express magic pathspecs
 (e.g. ":(icase)makefile" that matches both Makefile and makefile).

 Will cook in 'next'.


* jc/check-x-z (2013-07-11) 4 commits
  (merged to 'next' on 2013-07-15 at 62751bc)
 + check-attr -z: a single -z should apply to both input and output
 + check-ignore -z: a single -z should apply to both input and output
 + check-attr: the name of the character is NUL, not NULL
 + check-ignore: the name of the character is NUL, not NULL

 "git check-ignore -z" applied the NUL termination to both its input
 (with --stdin) and its output, but "git check-attr -z" ignored the
 option on the output side.

 This is potentially a backward incompatible fix.  I am tempted to
 merge this to and keep it in 'next' for a while to see if anybody
 screams before deciding if we want to do anything to help existing
 users (there may be none).

 Will cook in 'next'.


* ms/fetch-prune-configuration (2013-07-18) 1 commit
  (merged to 'next' on 2013-07-21 at 7ffb690)
 + fetch: make --prune configurable

 Allow fetch.prune and remote.*.prune configuration variables to be set,
 and "git fetch" to behave as if "--prune" is given.

 "git fetch" that honors remote.*.prune is fine, but I wonder if we
 should somehow make "git push" aware of it as well.  Perhaps
 remote.*.prune should not be just a boolean, but a 4-way "none",
 "push", "fetch", "both"?

 Will cook in 'next'.


* km/svn-1.8-serf-only (2013-07-18) 3 commits
  (merged to 'next' on 2013-07-19 at ab8d034)
 + Git.pm: revert _temp_cache use of temp_is_locked
  (merged to 'next' on 2013-07-12 at 70e0b95)
 + git-svn: allow git-svn fetching to work using serf
 + Git.pm: add new temp_is_locked function

 Subversion 1.8.0 that was recently released breaks older subversion
 clients coming over http/https in various ways.

 Will cook in 'next'.


* tr/merge-recursive-index-only (2013-07-07) 3 commits
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: untangle double meaning of o->call_depth
 - merge-recursive: remove dead conditional in update_stages()

 Will hold, until we get any user.


* jc/push-cas (2013-08-01) 7 commits
  (merged to 'next' on 2013-08-01 at a7604ee)
 + t5540/5541: smart-http does not support "--force-with-lease"
  (merged to 'next' on 2013-07-23 at 72371b0)
 + t5533: test "push --force-with-lease"
 + push --force-with-lease: tie it all together
 + push --force-with-lease: implement logic to populate old_sha1_expect[]
 + remote.c: add command line option parser for "--force-with-lease"
 + builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN
 + cache.h: move remote/connect API out of it

 Allow a safer "rewind of the remote tip" push than blind "--force",
 by requiring that the overwritten remote ref to be unchanged since
 the new history to replace it was prepared.

 The machinery is more or less ready.  The "--force" option is again
 the big red button to override any safety, thanks to J6t's sanity
 (the original round allowed --lockref to defeat --force).

 The logic to choose the default implemented here is fragile
 (e.g. "git fetch" after seeing a failure will update the
 remote-tracking branch and will make the next "push" pass,
 defeating the safety pretty easily).  It is suitable only for the
 simplest workflows, and it may hurt users more than it helps them.

 Also, smart-http needs to be taught about this before we can move
 it forward.

 Will cook in 'next'.


* jc/pull-training-wheel (2013-07-19) 1 commit
  (merged to 'next' on 2013-07-22 at 748180e)
 + pull: require choice between rebase/merge on non-fast-forward pull

 Make "git pull" (without arguments that say what branch to
 integrate from where) refuse with "it does not fast forward; choose
 between 'pull --merge' and 'pull --rebase'".

 See

 http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326
 http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229221

 for full discussion.

 Will cook in 'next'.


* rj/cygwin-clarify-use-of-cheating-lstat (2013-07-18) 1 commit
  (merged to 'next' on 2013-08-01 at 3ebfe7c)
 + cygwin: Remove the Win32 l/stat() implementation

 Cygwin port added a "not quite correct but a lot faster and good
 enough for many lstat() calls that are only used to see if the
 working tree entity matches the index entry" lstat() emulation some
 time ago, and it started biting us in places.  This removes it and
 uses the standard lstat() that comes with Cygwin.

 Recent topic that uses lstat on packed-refs file is broken when
 this cheating lstat is used, and this is a simplest fix that is
 also the cleanest direction to go in the long run.

 Will merge to 'master'.


* jc/reflog-doc (2013-06-19) 1 commit
 - setup_reflog_action: document the rules for using GIT_REFLOG_ACTION

 Document rules to use GIT_REFLOG_ACTION variable in the scripted
 Porcelain.  git-rebase--interactive locally violates this, but it
 is a leaf user that does not call out to or dot-sources other
 scripts, so fixing it is not all that urgent.


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

 Will cook in 'next' until Git 2.0.


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

 Will cook in 'next' until Git 2.0.


* jc/push-2.0-default-to-simple (2013-06-18) 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.


* jc/hold-diff-remove-q-synonym-for-no-deletion (2013-07-19) 1 commit
 - diff: remove "diff-files -q" in a version of Git in a distant future
 (this branch uses jc/diff-filter-negation.)

 Will cook in 'next' until a distant future.

--------------------------------------------------
[Discarded]

* jh/remote-hg-fetch-fix (2013-07-25) 2 commits
  (merged to 'next' on 2013-07-25 at 33161ad)
 + Revert "remotes-hg: bugfix for fetching non local remotes"
  (merged to 'next' on 2013-07-24 at 9c96641)
 + remotes-hg: bugfix for fetching non local remotes

 Reverted.

 Waiting for the final patch to replace, after discussion settles.


* km/http-curl-config-per-url (2013-07-31) 7 commits
  (merged to 'next' on 2013-07-31 at e88aad5)
 + Revert km/http-curl-config-per-url in its entirety
  (merged to 'next' on 2013-07-25 at 531e8cb)
 + docs: update http.<url>.* options documentation
  (merged to 'next' on 2013-07-23 at f84689b)
 + config: allow http.<url>.* any user matching
 + tests: add new test for the url_normalize function
 + config: improve support for http.<url>.* settings
 + config: add support for http.<url>.* settings
 + http.c: fix parsing of http.sslCertPasswordProtected variable

 Reverted to be replaced with a reroll (jc/url-match topic).

What's in "What's cooking"

[Junio C Hamano]

Here is a note to explain various sections and what the readers on
this list are expected to read from them in the periodic "What's
cooking" summary.  This probably should be integrated in the periodic
"A note from the maintainer" posting eventually.

The first part is mostly a boilerplate message, but the second
paragraph of it often explains where in the development cycle we are.
The latest one (issue #1 of this month) said:

    The first release candidate v1.8.4-rc1 has been tagged; only
    regression fixes and l10n updates from now on.

The preamble is followed by various sections, each listing topics in
different "doneness".

Each topic looks like this:

  * nd/sq-quote-buf (2013-07-30) 3 commits
    (merged to 'next' on 2013-08-01 at dc7934a)
   + quote: remove sq_quote_print()
   + tar-tree: remove dependency on sq_quote_print()
   + for-each-ref, quote: convert *_quote_print -> *_quote_buf

   Code simplification as a preparatory step to something larger.

   Will cook in 'next'.

A line that begins with a '*' has the name of a topic, the date of the
last activity on the topic and the number of changes in the topic.
Then each commit on the topic is listed with prefix ("+", "-" or ".").
The ones with "+" are already on 'next', and the dates when they were
merged to 'next' also appear on this list. This will give readers the
rough idea of how long the topic has been cooking in 'next' (the
branch active bug hunters and early adopters are expected to be
running) to measure the "doneness".

The list of commits on the topic is often followed by a few lines of
free-form text to summarize what the topic aims to achieve. This often
goes literally to the draft release notes when the topic graduates to
'master'.  Also I annotate my short-term plan for the topic ("Will
cook in 'next' in the above example); it is very much appreciated if
readers raise timely objections to this plan (e.g. "Don't merge it
yet, it is broken --- see that discussion thread").

The [New topics] section lists topics that were not in my tree when
the previous issue of "What's cooking" was sent.

The [Graduated to "master"] section lists topics that have been
merged to 'master' since the previous issue. Even if you are not an
active bug hunter, please exercise the features/fixes these topics
brings to the system, as breakages or regressions caused by these
will appear in the next release if they are not noticed and fixed.

The [Stalled] section lists topics whose discussion has stalled, or
re-rolled patches have not been seen for a while after the topic
received review comments. This section is listed here so that people
interested in the topics in it can help the owners of them to move
things forward.

The [Cooking] section lists the remainder of the topics. They are
making normal progress and are no cause for worries in general.
Those whose commits are all in "next" are often just simmering to
give time to active bug hunters find unexpected problem in them.
those whose commits are not in "next" yet are still going through
review/revise cycle until they become ready.

Re: What's cooking in git.git (Aug 2013, #01; Thu, 1)

[Thomas Rast]

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

> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>  - log: use true parents for diff even when rewriting
>
>  Output from "git log --full-diff -- <pathspec>" looked strange,
>  because comparison was done with the previous ancestor that touched
>  the specified <pathspec>, causing the patches for paths outside the
>  pathspec to show more than the single commit has changed.
>
>  I am not sure if that is necessarily a problem, though.  Output
>  from "git log --full-diff -2 -- <pathspec>" without this change
>  will be applicable to some codebase, but after this change that
>  will no longer be true (you will get only tiny parts of the change
>  that were made by the two commits in question, while missing all
>  the other changes).

Hmm.  Uwe's original complaint was that --stat -- as in "what other
things are touched when we modify foo" -- is nonsensical.

In addition, applying what you describe above would be a very strange
form of rebase: one that squashes everything into the commits that
affect the given files.  When would it ever make sense to do such
squashing?  After all, you'd lose all the commit splits&messages in
between.

If you care about it, I can introduce a new flag that lets the user
pick; it's pretty trivial.  But it seems very strange to me.

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

Re: What's cooking in git.git (Aug 2013, #01; Thu, 1)

[Junio C Hamano]

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>>  - log: use true parents for diff even when rewriting
>>
>>  Output from "git log --full-diff -- <pathspec>" looked strange,
>>  because comparison was done with the previous ancestor that touched
>>  the specified <pathspec>, causing the patches for paths outside the
>>  pathspec to show more than the single commit has changed.
>>
>>  I am not sure if that is necessarily a problem, though.  Output
>>  from "git log --full-diff -2 -- <pathspec>" without this change
>>  will be applicable to some codebase, but after this change that
>>  will no longer be true (you will get only tiny parts of the change
>>  that were made by the two commits in question, while missing all
>>  the other changes).
>
> Hmm.  Uwe's original complaint was that --stat -- as in "what other
> things are touched when we modify foo" -- is nonsensical.
>
> In addition, applying what you describe above would be a very strange
> form of rebase: one that squashes everything into the commits that
> affect the given files.  When would it ever make sense to do such
> squashing?  After all, you'd lose all the commit splits&messages in
> between.

I am not so worried about actually applying that kind of patch, but
more about reviewing what happened in each of the single logical
step shown.  If you made two changes in two far-apart commits to
files you are interested in and want to look at the changes made to
other files to make each of them a complete solution, depending on
how the change was split across files, you would get useful to
useless result with your patch.  In one extreme, if your commits are
too fine-grained and you committed one path at a time, then
"full-diff" will not show anything useful, as the commits that hit
the pathspec do not have changes to any other paths.  In another
extreme, you may have preparatory changes to other paths in commits
that immediately precede the commit that hits the pathspec and then
finally conclude the topic by introducing a caller of the prepared
codepath in other files to the file you are interested in, and your
patch will show only the endgame change without showing the
preparatory steps, which may or may not be useful, depending on what
you are looking for.

So while I do understand why sometimes you wish to see full diff 
"git log --full-diff -- <pathspec>" to match output from "git show"
without pathspec, I am not sure doing it unconditionally and by
default like your patch does is the best way to go.

In the meantime:

    git rev-list --header --parents HEAD -- <pathspec> |
    git -p diff-tree -p --stdin

would be one way to do so.

Re: What's cooking in git.git (Aug 2013, #01; Thu, 1)

[Thomas Rast]

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

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>>>  - log: use true parents for diff even when rewriting
>>>
>>>  Output from "git log --full-diff -- <pathspec>" looked strange,
>>>  because comparison was done with the previous ancestor that touched
>>>  the specified <pathspec>, causing the patches for paths outside the
>>>  pathspec to show more than the single commit has changed.
>>>
>>>  I am not sure if that is necessarily a problem, though.  Output
>>>  from "git log --full-diff -2 -- <pathspec>" without this change
>>>  will be applicable to some codebase, but after this change that
>>>  will no longer be true (you will get only tiny parts of the change
>>>  that were made by the two commits in question, while missing all
>>>  the other changes).
>>
>> Hmm.  Uwe's original complaint was that --stat -- as in "what other
>> things are touched when we modify foo" -- is nonsensical.
[...]
> I am not so worried about actually applying that kind of patch, but
> more about reviewing what happened in each of the single logical
> step shown.  If you made two changes in two far-apart commits to
> files you are interested in and want to look at the changes made to
> other files to make each of them a complete solution, depending on
> how the change was split across files, you would get useful to
> useless result with your patch.  In one extreme, if your commits are
> too fine-grained and you committed one path at a time, then
> "full-diff" will not show anything useful, as the commits that hit
> the pathspec do not have changes to any other paths.  In another
> extreme, you may have preparatory changes to other paths in commits
> that immediately precede the commit that hits the pathspec and then
> finally conclude the topic by introducing a caller of the prepared
> codepath in other files to the file you are interested in, and your
> patch will show only the endgame change without showing the
> preparatory steps, which may or may not be useful, depending on what
> you are looking for.
>
> So while I do understand why sometimes you wish to see full diff 
> "git log --full-diff -- <pathspec>" to match output from "git show"
> without pathspec, I am not sure doing it unconditionally and by
> default like your patch does is the best way to go.

I'm utterly unconvinced.

First, note that the behavior only shows when you use an option that
enables parent rewriting, such as --graph or --parents.

So if we went with a default-off option, there would be something like
--diff-original-parents.  The user would have to discover this option,
and use it whenever he wants to use --full-diff in combination with
--graph.  To obtain the same diffs as without --graph.

How do you explain that to a user?  "git-log has about 150 options.
Some of them interact badly, but don't worry, there are options in there
somewhere that make the weirdness go away."

  [No, I didn't actually count, but it seems a good estimate from
  looking at

    git grep -c -E '^-.*::' Documentation/rev-list-options.txt Documentation/diff-options.txt

  ]


Second, gitk's option "Limit diffs to listed paths", corresponding to
the inverse of --full-diff, shows the commits as with git-show.  (Not
internally, but still, the format is very similar.)  In particular it
only shows the changes from the commit itself.


Third, the only actual user data point I have is Uwe, who clearly
expected his diffs to remain the same across --graph.  There's a lot of
selection bias in this, because a happy user would not have complained,
but we can look at his example again (I added a right-hand side to the
range to make it reproducible).

With the patched version:

  $ git log --parents --stat v3.8..v3.9 --full-diff -- drivers/net/ethernet/freescale/fec.c
  commit 8d7ed0f051caf192994c02fbefb859eac03d1646 14109a59caf93e6eae726a34bf2f0897508ec8c1
  [...]
      net: fec: fix regression in link change accounting
  [...]
   drivers/net/ethernet/freescale/fec.c | 1 +
   1 file changed, 1 insertion(+)

With current master:

  commit 8d7ed0f051caf192994c02fbefb859eac03d1646 14109a59caf93e6eae726a34bf2f0897508ec8c1
  [...]
      net: fec: fix regression in link change accounting
  [...]
   Documentation/sound/alsa/ALSA-Configuration.txt    |    5 +-
   MAINTAINERS                                        |   22 +-
   Makefile                                           |    2 +-
   arch/alpha/Makefile                                |    2 +-
  [...]
   509 files changed, 9507 insertions(+), 7014 deletions(-)

509 files.  I don't know about you, but I think that's completely
useless for reviewing anything.


The only compromise I can see flying is using something like
--diff-parents=original and --diff-parents=rewritten, defaulting to
'original'.  Behind the scenes they would toggle the appropriate
machinery: 'rewritten' would enable parent simplification even when it
is not otherwise enabled, and 'original' would enable saving parents
whenever simplification is enabled.  Naturally all of this only applies
with --full-diff.


> In the meantime:
>
>     git rev-list --header --parents HEAD -- <pathspec> |
>     git -p diff-tree -p --stdin
>
> would be one way to do so.

Well, as a data point on how realistic this is, consider two things:

* I've hacked around on git for about five years now, and do not
  remember ever noticing or using --header.  Nor, for that matter, ever
  using rev-list|diff-tree for actual work.

* It doesn't work at my end: it doesn't show any diffs.  Removing
  --header helps, but then you lose the log messages.  --pretty again
  breaks the diffs.

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

Re: What's cooking in git.git (Aug 2013, #01; Thu, 1)

[Junio C Hamano]

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

>> So while I do understand why sometimes you wish to see full diff 
>> "git log --full-diff -- <pathspec>" to match output from "git show"
>> without pathspec, I am not sure doing it unconditionally and by
>> default like your patch does is the best way to go.
>
> I'm utterly unconvinced.

I was waiting you to say "I'm positively convinced that showing
local diff with the true parent is right!"; the reason why I planted
that seed in "What's cooking" to discuss this was because I needed
to play devil's advocate to make sure that all of us know that this
change is a good one, and that we know we agree that this change is
a good one, as the change is large insemantics, and the bookkeeping
burden is not negligible.  I suspect that we may want to restrict
the copying of the true parents only to limited cases (e.g. when
"--full-diff" is given), but I think that can be done on top, as it
is only the performance thing, not correctness.