What's cooking in git.git (Mar 2011, #06; Thu, 31)

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

It's been two months since v1.7.4 and -rc0 was way overdue. I'll do a -rc1 sometime next week, hoping that we can finish this cycle by mid April.

Which means that from now on, we wouldn't be interested in topics that are mostly internal clean-ups, new features that is not already in 'master', nor fixes for nontrivial bugs that are not regressions. A bug that existed since v1.7.0 is something we have lived with long enough that it is not worth the risk of introducing other new bugs by trying to fix it before 1.7.5 final).

What we would want to see are regression fixes. There are quite a few new topics that have already graduated in 'master', or have been cooking and should be in 'master' shortly. If they introduce new bugs that didn't exist in v1.7.4, they need to be squashed before anything else.

The criteria is a bit looser for documentation updates. Simple grammar and spelling fixes are usually safe; changes in the structure and markups are riskier.

In any case, please use your best judgement and help polishing v1.7.5 release.

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

* jh/notes-add-ui (2011-03-30) 1 commit
 - Make "git notes add" more user-friendly when there are existing notes

* jk/maint-remote-mirror-safer (2011-03-30) 3 commits
 - remote: deprecate --mirror
 - remote: separate the concept of push and fetch mirrors
 - remote: disallow some nonsensical option combinations

* jk/notes-ui-updates (2011-03-30) 7 commits
 - log/pretty-options: Document --[no-]notes and deprecate old notes options
 - revision.c: make --no-notes reset --notes list
 - revision.c: support --notes command-line option
 - notes: refactor display notes default handling
 - notes: refactor display notes extra refs field
 - revision.c: refactor notes ref expansion
 - notes: make expand_notes_ref globally accessible

* jr/grep-en-config (2011-03-30) 1 commit
  (merged to 'next' on 2011-03-31 at 2a73028)
 + grep: allow -E and -n to be turned on by default via configuration

This is low impact, isolated, and has no risk of breaking the system as a whole. May merge by rc1.

* nd/maint-setup (2011-03-26) 2 commits
  (merged to 'next' on 2011-03-31 at 2c36f6a)
 + Kill off get_relative_cwd()
 + setup: return correct prefix if worktree is '/'

This benefits only the minority who use /.git at the root level of the filesystem, but the changed code is used from many codepaths; will not merge before 1.7.5.

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

* jc/diff-irreversible-delete (2011-02-28) 1 commit
 - git diff -D: omit the preimage of deletes

"diff -B -D" should omit the deleting half of a broken pair from the output. This is low impact, isolated, and has no risk of breaking the system as a whole, but the topic needs documentation and tests.

* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit
 - Look for password in both CVS and CVSNT password files.

It seems that we need separate parsers for these two formats in order not to regress the users of the original cvs.

* jc/index-pack (2011-02-25) 5 commits
 - index-pack --verify: read anomalous offsets from v2 idx file
 - write_idx_file: need_large_offset() helper function
 - index-pack: --verify
 - write_idx_file: introduce a struct to hold idx customization options
 - index-pack: group the delta-base array entries also by type

Still a WIP, and will not be ready for 1.7.5. Need to put histogram output into index-pack --verify to really kill verify-pack.

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

* jk/edit-notes-in-commit-log (2011-03-07) 2 commits
 - [wip] commit: allow editing notes in commit message editor
 - notes: make expand_notes_ref globally accessible

* mg/grep-full-tree (2011-03-01) 2 commits
 - grep: make --full-tree work with pathspecs
 - grep: --full-tree

Do not merge; it would be preferable to use ":/" or whatever magic pathspec that is relative to the root of the working tree.

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

* mz/rebase (2011-02-28) 34 commits
  (merged to 'next' on 2011-03-31 at 3b1343c)
 + rebase: define options in OPTIONS_SPEC
  (merged to 'next' on 2011-02-25 at 52caa7a)
 + Makefile: do not install sourced rebase scripts
  (merged to 'next' on 2011-02-22 at 3219155)
 + rebase: use @{upstream} if no upstream specified
 + rebase -i: remove unnecessary state rebase-root
 + rebase -i: don't read unused variable preserve_merges
 + git-rebase--am: remove unnecessary --3way option
 + rebase -m: don't print exit code 2 when merge fails
 + rebase -m: remember allow_rerere_autoupdate option
 + rebase: remember strategy and strategy options
 + rebase: remember verbose option
 + rebase: extract code for writing basic state
 + rebase: factor out sub command handling
 + rebase: make -v a tiny bit more verbose
 + rebase -i: align variable names
 + rebase: show consistent conflict resolution hint
 + rebase: extract am code to new source file
 + rebase: extract merge code to new source file
 + rebase: remove $branch as synonym for $orig_head
 + rebase -i: support --stat
 + rebase: factor out call to pre-rebase hook
 + rebase: factor out clean work tree check
 + rebase: factor out reference parsing
 + rebase: reorder validation steps
 + rebase -i: remove now unnecessary directory checks
 + rebase: factor out command line option processing
 + rebase: align variable content
 + rebase: align variable names
 + rebase: stricter check of standalone sub command
 + rebase: act on command line outside parsing loop
 + rebase: improve detection of rebase in progress
 + rebase: remove unused rebase state 'prev_head'
 + rebase: read state outside loop
 + rebase: refactor reading of state
 + rebase: clearer names for directory variables

I wanted to wait for an independent Ack or two for the tip one, which was a response to regression concerns raised by J6t, but ended up merging it after giving another look. Will not merge before 1.7.5, as there is no user visible improvements up to this point.

* jc/merge-sans-branch (2011-03-23) 2 commits
  (merged to 'next' on 2011-03-31 at 754a6af)
 + merge: merge with the default upstream branch without argument
 + merge: match the help text with the documentation

Allow running "git merge" without telling it what to merge. It will merge with the "upstream" of the current branch if configured. This is low impact, isolated, and has no risk of major regression. May merge before rc1, but it is Ok to wait.

* jh/gitweb-localtime (2011-03-23) 1 commit
 - gitweb: javascript ability to adjust time based on timezone

* jk/maint-merge-rename-create (2011-03-25) 3 commits
  (merged to 'next' on 2011-03-31 at b9bc9f1)
 + merge: turn on rewrite detection
 + merge: handle renames with replacement content
 + t3030: fix accidental success in symlink rename

May merge before rc1, but it is Ok to wait.

* jk/pull-into-empty (2011-03-25) 2 commits
  (merged to 'next' on 2011-03-31 at d4dd598)
 + pull: do not clobber untracked files on initial pull
 + merge: merge unborn index before setting ref

This is low impact, isolated, and has no risk of major regression. Will merge before rc1.

* mz/maint-rename-unmerged (2011-03-23) 1 commit
  (merged to 'next' on 2011-03-31 at c7b3d9a)
 + diffcore-rename: don't consider unmerged path as source

Will cook until 1.7.5 final.

* nd/struct-pathspec (2011-03-25) 4 commits
  (merged to 'next' on 2011-03-31 at 66cbb7d)
 + Improve tree_entry_interesting() handling code
 + Convert read_tree{,_recursive} to support struct pathspec
 + Reimplement read_tree_recursive() using tree_entry_interesting()
 + Merge branch 'en/object-list-with-pathspec' into 'nd/struct-pathspec'

Will cook until 1.7.5 final.

* jc/add-u-migration (2011-03-22) 3 commits
 - add: make "add -u/-A" update full tree without pathspec (step 3)
 - add: make "add -u/-A" update full tree without pathspec (step 2)
  (merged to 'next' on 2011-03-31 at 962e058)
 + add: make "add -u/-A" update full tree without pathspec

The bottom one is a necessary first step toward the UI clean-up planned for 1.8.0 which we discussed in length in the earlier part of the cycle; the change is low impact, isolated, and has no risk of breaking the system as a whole, but I would wait until the ":/" magic pathspec materializes, as the advice message would have to become different, and the way to get more stable semantics will become more direct.

* jk/progress-with-pager (2011-03-24) 4 commits
 - diff: turn on rename detection progress reporting
 - show: turn on rename detection progress reporting
 - progress: use pager's original_stderr if available
 - pager: save the original stderr when redirecting to pager

Will cook until 1.7.5 final.

* sb/sparse-more (2011-03-21) 1 commit
  (merged to 'next' on 2011-03-23 at 4bec1d1)
 + Makefile: Cover more files with make check

Will merge.

* jc/rename-degrade-cc-to-c (2011-01-06) 4 commits
  (merged to 'next' on 2011-03-31 at 8d685d7)
 + diffcore-rename: fall back to -C when -C -C busts the rename limit
 + diffcore-rename: record filepair for rename src
 + diffcore-rename: refactor "too many candidates" logic
 + builtin/diff.c: remove duplicated call to diff_result_code()

Will hold.

* cn/system-path-tweak (2011-03-17) 1 commit
 - system_path: use a static buffer

* en/merge-recursive (2011-03-17) 4 commits
  (merged to 'next' on 2011-03-18 at a32016b)
 + merge-recursive: tweak magic band-aid
  (merged to 'next' on 2011-03-09 at 3762932)
 + merge-recursive: When we detect we can skip an update, actually skip it
 + t6022: New test checking for unnecessary updates of files in D/F conflicts
 + t6022: New test checking for unnecessary updates of renamed+modified files

I am not happy with these magic band aids.  Will hold.

* nd/init-gitdir (2011-03-19) 2 commits
  (merged to 'next' on 2011-03-31 at 3b8fb40)
 + init, clone: support --separate-git-dir for .git file
 + git-init.txt: move description section up

Will merge.

* jl/submodule-fetch-on-demand (2011-03-06) 7 commits
  (merged to 'next' on 2011-03-20 at a5e452d)
 + fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
 + submodule update: Don't fetch when the submodule commit is already present
 + fetch/pull: Don't recurse into a submodule when commits are already present
 + Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
 + config: teach the fetch.recurseSubmodules option the 'on-demand' value
 + fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
 + fetch/pull: recurse into submodules when necessary

Will merge.

* ab/i18n-st (2011-02-22) 69 commits
  (merged to 'next' on 2011-03-23 at e2732e2)
 + i18n: git-shortlog basic messages
 + i18n: git-revert split up "could not revert/apply" message
 + i18n: git-revert literal "me" messages
 + i18n: git-revert "Your local changes" message
 + i18n: git-revert basic messages
 + i18n: git-notes GIT_NOTES_REWRITE_MODE error message
 + i18n: git-notes basic commands
 + i18n: git-gc "Auto packing the repository" message
 + i18n: git-gc basic messages
 + i18n: git-describe basic messages
 + i18n: git-clean clean.requireForce messages
 + i18n: git-clean basic messages
 + i18n: git-bundle basic messages
 + i18n: git-archive basic messages
 + i18n: git-status "renamed: " message
 + i18n: git-status "Initial commit" message
 + i18n: git-status "Changes to be committed" message
 + i18n: git-status shortstatus messages
 + i18n: git-status "nothing to commit" messages
 + i18n: git-status basic messages
 + i18n: git-push "prevent you from losing" message
 + i18n: git-push basic messages
 + i18n: git-tag tag_template message
 + i18n: git-tag basic messages
 + i18n: git-reset "Unstaged changes after reset" message
 + i18n: git-reset reset_type_names messages
 + i18n: git-reset basic messages
 + i18n: git-rm basic messages
 + i18n: git-mv "bad" messages
 + i18n: git-mv basic messages
 + i18n: git-merge "Wonderful" message
 + i18n: git-merge "You have not concluded your merge" messages
 + i18n: git-merge "Updating %s..%s" message
 + i18n: git-merge basic messages
 + i18n: git-log "--OPT does not make sense" messages
 + i18n: git-log basic messages
 + i18n: git-grep "--open-files-in-pager" message
 + i18n: git-grep basic messages
 + i18n: git-fetch split up "(non-fast-forward)" message
 + i18n: git-fetch update_local_ref messages
 + i18n: git-fetch formatting messages
 + i18n: git-fetch basic messages
 + i18n: git-diff basic messages
 + i18n: git-commit advice messages
 + i18n: git-commit "enter the commit message" message
 + i18n: git-commit print_summary messages
 + i18n: git-commit formatting messages
 + i18n: git-commit "middle of a merge" message
 + i18n: git-commit basic messages
 + i18n: git-checkout "Switched to a .. branch" message
 + i18n: git-checkout "HEAD is now at" message
 + i18n: git-checkout describe_detached_head messages
 + i18n: git-checkout: our/their version message
 + i18n: git-checkout basic messages
 + i18n: git-branch "(no branch)" message
 + i18n: git-branch "git branch -v" messages
 + i18n: git-branch "Deleted branch [...]" message
 + i18n: git-branch "remote branch '%s' not found" message
 + i18n: git-branch basic messages
 + i18n: git-add "Unstaged changes" message
 + i18n: git-add "remove '%s'" message
 + i18n: git-add "did not match any files" message
 + i18n: git-add "The following paths are ignored" message
 + i18n: git-add basic messages
 + i18n: git-clone "Cloning into" message
 + i18n: git-clone "Cloning into" message
 + i18n: git-clone basic messages
 + i18n: git-init "Initialized [...] repository" message
 + i18n: git-init basic messages

Will merge.

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

* jc/diff-dotdot (2011-03-23) 2 commits
 . warn use of "git diff A..B"
 . diff: remove dead code that flips arguments order

This was 1/4 tongue-in-cheek. Now we seem to have a handful of volunteer cluebat bearers, and I wouldn't have to worry about this topic very much.

* jh/merge-sans-branch (2011-02-10) 4 commits
 . merge: add support for merging from upstream by default
 . merge: introduce per-branch-configuration helper function
 . merge: introduce setup_merge_commit helper function
 . merge: update the usage information to be more modern

I've been wanting to move this forward for quite some time but ended up redoing it myself (see jc/merge-sans-branch)

I've been aiming for 6-8 week cycles but the 1.7.5 cycle ended up being way longer than that. I just tagged a -rc0 and it will be mirroring out, and today's "What's cooking" has annotations on topics in flight that I expect to be in the -rc1.

This message is primarily meant to be a reminder to myself and also to clarify my intentions. I'd like one cycle of ours to look roughly like this:

 - 1.7.5 is released.

 - Week 1: post release clean-up.  People are strongly encouraged to give
   the highest priority to the regression fixes for the most recent
   release.

 - Week 2: new features, restructuring, non-regression bugfixes start to
   flow in and graduate in preparation for 1.7.6.  Some may graduate from
   'next' before 1.7.5 to master, some may be newly queued through 'pu' to
   'next'.

 - Week N: 1.7.6-rc0 is tagged.  Examine topics in 'next' that are still
   not in 'master' and decide which way they should go, either included in
   1.7.6-rc1 or wait until the next cycle.

 - Week N+1: 1.7.6-rc1 is tagged with (a subset of) candidate topics we
   decided previous week.

   At this point, people are again strongly encouraged to give the highest
   priority to the regression fixes for the upcoming release.

 - Week N+2: 1.7.6-rc2 is tagged.

 - Week X: 1.7.6 is released.

Historically we have done at least two rc releases, and often three, so I would expect X is at least N+3 but possibly N+4. Since I want to have at most an 8-week cycle, it would mean N=4 or 5, so we have three to four weeks to concentrate the real development for the next release.

We are at "Week N" for this cycle as of today.

This of course does not mean that people are forbidden from working on or discussing anything but regression fixes during the rc and post-release period. It may take longer than a month to stabilize for a large-ish topic to be properly reviewed, discussed and guinea-pigged in 'next'.

So during Weeks N thru X, there may appear new topics in flight and I may end up queueing them in 'pu' or even move some of them to 'next', with an understanding that they will not be part of the current cycle, but are queued merely to make it easier for people interested in the new topic to try out and discuss ideas for the next cycle. Also handling these new topics during the rc period will receive much lower priority and time from me.

I hope all the above sound sensible.  Thanks.

On Fri, Apr 1, 2011 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:

Hi Junio, I was surprised to not read response, it's having sensitive impact on the project. Junio, it's effective now?

Sebastien Douche <sdouche@gmail.com> writes:

Hmm, what sensitive impact on which project do you have in mind?

The structure of clean-up, development, freeze and then release has always been in effect in this project, but historically the duration of the development stretch varied a lot from cycle to cycle.

I just spelled the structure out for the next cycle, and tried to give some predictable bounds to that elastic development stretch, in order to force myself to stick to a schedule in which we can make measurable progress in reasonable amount of time.

It does not mean that we won't be tackling issues that will take more than N weeks to perfect. Either a topic gets polished enough in a single cycle to graduate to 'master' before -rc0, or it keeps cooking in 'next' during the feature freeze, and will attempt to be in the release after that.

I've tentatively set the following dates on my calendar, based on 9-week cycle:

 - Today is the beginning of week #1 for this cycle.

 - The entire month of May 2011 will be the development stretch (lasting
   up to Week #5 that ends May 29th).

 - Aim to tag 1.7.6-rc0 on June 1st, 2011, -rc1 on 8th, -rc2 on 15th.

 - Either tag 1.7.6 final on 19th or have -rc3 on 22nd and final on 26th
   of June.

If you happen to use Google Calendar, you can paste:

    jfgbl2mrlipp4pb6ieih0qr3so@group.calendar.google.com

in the "Other calendars" box (where a gray "Add a friend's calendar" appears), but you won't be missing much even if you don't (I only have week numbers and the target tagging dates, nothing more interesting than that).

On Mon, Apr 25, 2011 at 19:03, Junio C Hamano <gitster@pobox.com> wrote:

Short cycle means less time to write code for the next release, the "frame" to add feature is reduced. I'm surely wrong, Git is a stable project and well managed (with 4 branches: unstable, integration, next stable & stable).

Cool :).

Introduce the -D/--irreversible-delete option which omits the diff for total deletes. It is similar to -M,-C in its output but irreversible in the sense that the resulting patch can not be reversed (-R).

When used in connection with -B, omit the diff of the deletion part of a complete rewrite.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/diff-options.txt |   10 +++++++++
 diff.c                         |   14 +++++++++---
 diff.h                         |    1 +
 t/t4022-diff-rewrite.sh        |   43 +++++++++++++++++++++++++++++++++++++++-
 4 files changed, 63 insertions(+), 5 deletions(-)

Michael J Gruber <git@drmicha.warpmail.net> writes:

Thanks, but this hunk looks fishy.

What happens to a path that was tentatively broken for the purpose of rename detection with -B -M (break to match with another file) but then found to be with no counterpart after all after running diffcore_rename(), which now needs to get merged back? Such a path is shown as a normal patch when the dissimlarity between the preimage and postimage is not large enough and merge-broken is the step that combines such a broken but unmatched pair back.

I would have expected that the patch relative to jc/diff-irreversible-delete topic would consist only of changes to diff.c:emit_rewrite_diff(), docs and tests.

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

Here is an "in other words" follow-up. Your tests looked reasonable (and pass with this patch on top of what has been queued in 'pu').

 diff.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

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

And this is the documentation part, based on your version but somewhat rewritten. Your version said "cannot be applied with -R", but at the mechanical application level, the format is deliberately designed to make `patch` and `git apply` to fail, and I think that should be mentioned together with the reason why such an option exists (i.e. for human eyeball consumption).

I'll squash these two to what is queued in 'pu'. We may want to polish it again after 1.7.5 but I think it is in much better shape now.

Thanks.

 Documentation/diff-options.txt |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

Junio C Hamano venit, vidit, dixit 01.04.2011 21:26:

I think I misunderstood what you intended "-B -D" to do (and I even didn't know about -B until -D came up; my understanding of "-B" is still fishy). I just didn't want to let this die before 1.7.5. Thanks for taking this up and clarifying it.

Michael

On Thu, Mar 31, 2011 at 03:26:31PM -0700, Junio C Hamano wrote:

Both probably post-1.7.5 material. I am of course tempted to get new options in place ASAP (since the sooner they are in, the sooner script writers can say "they are in long enough" and start using them). But I don't think either is critical.

You may want to drop this for now. The bottom one is in jk/notes-ui-updates, which hopefully will go to master soon after 1.7.5, and the top one is going to be rewritten.

I would hold off on this. I _think_ it's fine, but I would really prefer for it to get more exposure in 'next' to shake out any bugs.

Agreed.

I have been meaning to look closer at this. Were you wanting to get the first stage of the transition into 1.7.5?

I'm not sure if this whole thing should be scrapped. There are potential problems with starting a pager that wants to grab the whole screen (i.e., not less). Maybe it would be enough to have a pager.noprogress option for people who use such a pager.

-Peff

Jeff King <peff@peff.net> writes:

I was tempted to but I think it would be far more pleasant if the first step were to add the warning against "add -u" without pathspec that is ran from a subdirectory to advise "if you meant 'from here', say '.', if you meant 'everywhere', say ':/'---for now we pretend you said '.' to match the traditional behaviour."

It is adding even more confusion to add the "in this repository, 'add -u' is tree-wide" configuration variable without giving people who need to override that in unfamiliar repositories (read: scripts).

Right now, we don't have a good advice to force the tree-wide behaviour other than "cd $(git rev-parse --show-cdup)/. && git add -u", which is quite a mouthful.

We know how the magic "this pathspec is from the root" should work, and I think we even saw "should look like this" patches, but haven't applied to any branch so far yet.

Perhaps. With "Will cook until" I only meant "will not graduate until"; I was not even making any prediction after 1.7.5 in the message.

Thanks.

On Fri, Apr 01, 2011 at 10:01:42AM -0700, Junio C Hamano wrote:

Yes, I think that is definitely the right first step.

That reasoning makes sense. Let's let the :/ patches develop and cook for post-1.7.5, then, and worry about it in the next cycle when we can build on top of them.

-Peff