What's cooking in git.git (Jan 2010, #08; Sun, 24)

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.

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

* jc/fix-tree-walk (2009-09-14) 7 commits
  (merged to 'next' on 2010-01-13 at 1c01b87)
 + read-tree --debug-unpack
 + unpack-trees.c: look ahead in the index
 + unpack-trees.c: prepare for looking ahead in the index
 + Aggressive three-way merge: fix D/F case
 + traverse_trees(): handle D/F conflict case sanely
 + more D/F conflict tests
 + tests: move convenience regexp to match object names to test-lib.sh

This is fix for a tricky codepath; I've been using this personally during the whole cycle up to point, so hopefully it finally have nailed all the corner cases? Knock wood...

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

* cc/reset-keep (2010-01-19) 5 commits
 - reset: disallow using --keep when there are unmerged entries
 - reset: disallow "reset --keep" outside a work tree
 - Documentation: reset: describe new "--keep" option
 - reset: add test cases for "--keep" option
 - reset: add option "--keep" to "git reset"

I do not think I'd ever use this, and I am not convinced I can sell this to users as a great new feature without confusing them unnecessarily, but perhaps queuing it to pu to give it wider visibility may help somebody coming up with a better way to defend the feature and introduce it to users without confusing them than Christan nor I managed to.

* jc/ce-uptodate (2010-01-24) 1 commit
 - Make ce_uptodate() trustworthy again

I think this and Jens Lehmann's follow-up patch to avoid calling is_submodule_modified() are needed before 1.7.0

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

* jh/notes (2010-01-17) 20 commits
 - builtin-gc: Teach the new --notes option to garbage-collect notes
 - Notes API: gc_notes(): Prune notes that belong to non-existing objects
 - t3305: Verify that removing notes triggers automatic fanout consolidation
 - builtin-notes: Teach -d option for deleting existing notes
 - Teach builtin-notes to remove empty notes
 - Teach notes code to properly preserve non-notes in the notes tree
 - t3305: Verify that adding many notes with git-notes triggers increased fanout
 - t3301: Verify successful annotation of non-commits
 - Builtin-ify git-notes
 - Refactor notes concatenation into a flexible interface for combining notes
 - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
 - Notes API: write_notes_tree(): Store the notes tree in the database
 - Notes API: for_each_note(): Traverse the entire notes tree with a callback
 - Notes API: get_note(): Return the note annotating the given object
 - Notes API: remove_note(): Remove note objects from the notes tree structure
 - Notes API: add_note(): Add note objects to the internal notes tree structure
 - Notes API: init_notes(): Initialize the notes tree from the given notes ref
 - Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
 - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
 - Minor non-functional fixes to notes.c

The changes to test vector this series makes to t3301 breaks tests that are in 'master', so 'pu' doesn't pass it.

* jh/gitweb-cached (2010-01-13) 9 commits
 - gitweb: File based caching layer (from git.kernel.org)
 - gitweb: Convert output to using indirect file handle
 - gitweb: cleanup error message produced by undefined $site_header
 - gitweb: add a get function to compliment print_sort_th
 - gitweb: add a get function to compliment print_local_time
 - gitweb: Makefile improvements
 - gitweb: Add option to force version match
 - gitweb: change die_error to take "extra" argument for extended die information
 - gitweb: Load checking

I know there is a series to split the later ones into smaller chunks that are being discussed on the list, but they don't appear here. I'd prefer to pick the series up after all the dust from the discussion settles.

* jc/grep-author-all-match-implicit (2010-01-17) 1 commit
 - "log --author=me --grep=it" should find intersection, not union

Right now 'next' is empty and there are a handful topics in 'pu':

 - Jens Lehmann's updates to omit expensive is_submodule_modified() call
   when running "diff --ignore-submodules" and to make "diff --submodule"
   to show the "dirty worktree" status.  I think they should be in 1.7.0
   as part of the series to show work tree/index dirtiness in "git diff"
   output from the superproject.

 - Christian Couder's "reset --keep".  I am inclined to exclude it from
   1.7.0 as I cannot make a convincing argument to sell this to users
   without confusing them (even I am not convinced even though I do fairly
   straight line development at day-job), but hopefully we can keep
   cooking it in 'pu/next'.

 - Johan Herland's notes updates.  Won't be ready for 1.7.0 but hopefully
   we can keep cooking in 'pu/next'.

 - John Hawley's gitweb caching layer.  Jakub is splitting them into
   smaller pieces and they are still generating discussions.

 - My "how about this" patch to make 'grep --author=foo --grep=bar' to
   implicitly run --all-match; this is not yet readyand needs reworking.

There also is a discussion on //server/share path on msysgit, that was started since 288123f (ignore duplicated slashes in make_relative_path(), 2010-01-21). If that commit _breaks_ use case on msysgit that used to work, I think the sanest course of action is to revert it and ship 1.7.0 with the same breakage we've had forever when the user gives extra slashes in the paths to --git-dir or --work-tree options. We could instead apply Thomas's patch

Message-ID: <379d55c6a4110736aadb8ace3b050de879a9deab.1264118830.git.trast@student.ethz.ch>

that changed behaviour in much narrower case, which should be safer. In any case, a more intrusive change for UNC is outside the scope of 1.7.0 (discussion and preparation can continue on 'pu/next').

I saw a few patches and discussion to git-p4 in contrib from Pal-Kristian Engstad and I understand that we are waiting for revised version before I should take any action on them.

The above are the current set of unresolved topics and their status but I am sure I've missed some others. Please remind me and the list if there are other important ones that need to be discussed.

On Montag, 25. Januar 2010, Junio C Hamano wrote:

IFAICS, this patch is not a regression w.r.t. //server/share paths.

The discussion is about that support of //server/share paths in msysgit is poor in general. For example, it is not possible to

  git clone //server/share/repo.git

with different failure modes depending on whether forward slashes or backslashes are used.

-- Hannes

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

Well, this series actually consist of two parts: miscellaneous gitweb
improvements and actual gitweb output caching.  The first part is more
or less ready; in particular the following patches are I think ready
for inclusion:
 - gitweb: Makefile improvements
 - gitweb: change die_error to take "extra" argument for extended die information
 - gitweb: Load checking
(Although die_error improvements is used by 'force version match',
which is not ready yet).

The following patches needs minimal fixups or extensions.  In
 - gitweb: add a get function to compliment print_sort_th
 - gitweb: add a get function to compliment print_local_time
IMVHO the new (unused) get_* functions should really be named format_*
to follow gitweb convention for naming subroutines.  And of course
that would probably require accompanying change to the commit message.

The patch
 - gitweb: cleanup error message produced by undefined $site_header
solves its problem... but not fully.  There are other variables
holding file names that could, in theory, be undefined.  Also the
commit message should perhaps mention that is defensive coding against
errors in gitweb config file, as in normal situation those variables
would be set to empty string, but not undefined.

I am not sure about the
 - gitweb: Add option to force version match
patch.  It is not that useful if the feature is turned off by default;
on the other hand if the feature is turned on by default the error
message needs to be changed... and be a bit more complicated in the
case when there are no config files (see my reply in thread).

You are right that actual caching support is in flux. The discussion continues: it is very good that we have the voice from Pasky, too.

On Mon, Jan 25, 2010 at 02:43:01PM -0800, Jakub Narebski wrote:

Unfortunately, I can't give much time to it, or actual contributions. I think it would be great to apply at least the miscellanous-changes part to (i) move this further (ii) give jh some positive feedback. :) There are ugly minor things, but they can be patched up later. I think it's healthier for new gitweb stuff to develop more in-tree, even if that means few angry users annoyed about less-than-perfect UI stuff, rather than polish the diamond in infinite discussions; worse is better! The only thing we should be worried about is avoiding introducing new bad URL interfaces since we should keep backwards compatibility there.

But Jakub's opinion is definitely much more important, he gives gitweb much more time than me.

For the main caching patch, it seems like good idea to take Jakub's split-up series instead, let's see what is J.H.'s opinion on the series?

Petr Baudis <pasky@suse.cz> writes:

Sounds reasonable.

On Tue, Jan 26, 2010 at 00:12 +0100, Petr Baudis wrote:

I think that while some patches from the miscellaneous-changes part are good now (and very nice to have, especially load checking and gitweb/Makefile), there needs to be one last, final reroll of those patches.

I am waiting for response from (I guess busy) J.H.; I can do the re-roll if he is too busy to work on it.

Let me at least make them into proper patches, with commit messages and configureability at least of the original caching patch by J.H.

Also the question whether to create 'print -> print $out' patch, or to manipulate *STDOUT instead must be solved, I think, before applying those patches... well, at least beyond 'pu'.

I am waiting for promised J.H. comments, when he will have time for it...

I'm juggling about 4 things in the air right now, with gitweb being one of them, and two of them involving external entities to kernel.org. It's good news all told, just requires a fair amount of my time (currently) and babysitting. I've been digging through the patches you've got right now. I should really just pull them in from your git tree again.

After reading through some of the discussions today I've had some more ideas on the caching stuff, they are written up on my whiteboard and I might be able to get to shortly, but I've got a rather large wall looming ahead of me that's going to chew up a *LOT* (read at least a month, if not two) of my time, so I'm a bit under the gun to try and get this as far as I can before I hit that wall or this is going to fall by the wayside again till I've got time again.

On Mon, 25 Jan 2010 at 16:21:51 -0800 (PST), J.H. wrote:

Note however that my series (gitweb/cache-kernel branch) is based on gitweb-ml-v2, not on newer gitweb-ml-v5.

I think the best way of utilizing your time would be for you to take active part in discussion, especially in what git.kernel.org needs and why.

I can clean up the miscellaneous improvements parts myself, and re-roll caching patches.