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.

Topics not in 'next' will have to wait until post 1.7.1 cycle.  I expect
that the changes already under discussion will be ready by the time the post
1.7.1 cycle begins, and we will hopefully have a cycle for 1.7.2 that is
shorter than usual to include them.

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

* sb/notes-parse-opt (2010-02-27) 1 commit
  (merged to 'next' on 2010-03-24 at 82eebc1)
 + notes: rework subcommands and parse options

* cc/cherry-pick-ff (2010-03-20) 7 commits
  (merged to 'next' on 2010-03-20 at a1ae16b)
 + revert: fix tiny memory leak in cherry-pick --ff
 + rebase -i: use new --ff cherry-pick option
  (merged to 'next' on 2010-03-07 at 5589b26)
 + Documentation: describe new cherry-pick --ff option
 + cherry-pick: add tests for new --ff option
 + revert: add --ff option to allow fast forward when cherry-picking
 + builtin/merge: make checkout_fast_forward() non static
 + parse-options: add parse_options_concat() to concat options

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

* cw/ws-indent-with-tab (2010-04-01) 2 commits
 - whitespace: we cannot "catch all errors known to git" anymore
 - Add tab-in-indent whitespace error class

Not quite ready until "apply --whitespace=fix" gets a matching change.

* ic/bash-completion-rpm (2010-03-26) 1 commit
 - RPM spec: include bash completion support

This is needed in 'master' by -rc1 at the latest.  Soon in 'next'.

* js/grep-open (2010-03-26) 2 commits
 - grep -O: allow optional argument specifying the pager (or editor)
 - grep: Add the option '--open-files-in-pager'

Probably needs to support --no-index mode as well.

* mg/notes-reflog (2010-03-29) 2 commits
 - refs.c: Write reflogs for notes just like ...
[ message continues ]

I haven't forgotten the "git init" with alias bug Jonathan found. Just
a little busy with other stuff.
-- 
Duy
--

[ message continues ]

You already fixed it, I think. ;-)

Unfortunately, I have also run into a double-initialization bug with
clone.  I haven’t figured out how to reproduce it yet; once I do, I’ll
send a patch.

Overall, I think this series does a good thing, so I am anxious to find
all the bugs I can so the wrinkles get ironed out.

Here’s another tiny issue.

-- %< --
Subject: Revert "help: use RUN_SETUP_GENTLY"

Commit 717b8850580ecb9009505f71ea43ecda51ac1f0e taught ‘git help’
to unconditionally looks for a git directory, with the justification:

    So the sooner we set up gitdir, the less trouble we may have to
    deal with.

In the case of ‘git help -a’, that is not quite true.  In automount
setups like that which prompted v1.6.0-rc0~121^2~1 (Add support for
GIT_CEILING_DIRECTORIES, 2008-05-19), if GIT_CEILING_DIRECTORIES is
unset, then probing for the Git directory can take a long time.  Thus
unnecessarily searching for a git directory can slow down ‘git help -a’
(and thus bash completion).

‘git help’ does not use RUN_SETUP or USE_PAGER, and neither option
parsing nor producing output for plain ‘git help’ or ‘git help -a’
requires access to the git configuration.  Therefore it is safe to not
search for the git directory early in this case.

Also add some comments to document the requirements this places on
list_commands() and list_common_cmds_help().

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 builtin/help.c |    7 +++++++
 git.c          |    2 +-
 help.c         |    4 ++++
 3 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/builtin/help.c b/builtin/help.c
index 4988629..68b72df 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -271,6 +271,11 @@ static int git_help_config(const char *var, const char *value, void *cb)
 
 static struct cmdnames main_cmds, other_cmds;
 
+/*
+ * Used for plain ‘git’ and ‘git help’.
+ * Therefore this should not use git_config(), nor any other function
+ * that requires searching for a repository.
+ */
 ...
[ message continues ]

Didn't notice it. Looks good. I will replace the "help: use
RUN_SETUP_GENTLY" commit with this patch next time, if you don't mind.
-- 
Duy
--

[ message continues ]

Junio,

I wanted to update nd/setup topic, but found nd/root-git was merged in
between its two parts, which resulted in non-trivial conflicts in the
end. Changes are minor, mainly to clean up the topic. So it's up to
you to either leave the topic as is (plus Jonathan's "help revert"
patch on top) or replace with some patches I attach, because if I send
the whole topic again, you would need to resolve conflicts manually.
I'll make proper patch messages next time once I figure out how to
send conflict resolutions through mail.

- 717b885 help: use RUN_SETUP_GENTLY
  replaced by 0001 (needs to resolve conflict in the next patch in
topic, but it's quite simple)
- 450476a worktree setup: restore original state when things go wrong
  replaced by 0002
- bc7cd1c Guard unallowed access to repository when it's not set up
  replaced by 0003 and 0004
- a55fdda builtins: reset startup_info->have_run_setup_gitdir when
unsetting up repository
  dropped (splitted as part of 0002-0004)
--
Duy
[ message continues ]

I am not quite sure what you want me to do.  Replacing these named commits
in place (meaning, the merge with nd/root-git to adjust the later parts
that depend on that fix is reproduced while rebuilding the topic) has some
silly conflicts, and rebuilding the whole series without the merge but
with the named commits replaced has different conflicts.

As the fix of nd/root-git is already in 'master', it might make more sense
to apply the whole series rebased to the newer codebase instead of keeping
the same fork point as the older series.  That also removes the worries
for you about having to send conflict resolutions, no?

--

[ message continues ]

Heya,


Agreed, if 1.7.2 will be a short cycle I don't mind waiting a few more weeks :).

-- 
Cheers,

Sverre Rabbelier
--

[ message continues ]

Indeed.


Nicolas
--

[ message continues ]