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

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

[Junio C Hamano]

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

Issues that need to be resolved before 1.7.0-rc1

[Junio C Hamano]

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.

Re: Issues that need to be resolved before 1.7.0-rc1

[Johannes Sixt]

On Montag, 25. Januar 2010, Junio C Hamano wrote:
> 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...

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

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

[Jakub Narebski]

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


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

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Petr Baudis]

On Mon, Jan 25, 2010 at 02:43:01PM -0800, Jakub Narebski wrote:
> 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.

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 "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

Sounds reasonable.

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

[Jakub Narebski]

On Tue, Jan 26, 2010 at 00:12 +0100, Petr Baudis wrote:
> On Mon, Jan 25, 2010 at 02:43:01PM -0800, Jakub Narebski wrote:

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

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.

> 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?

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...
-- 
Jakub Narebski
Poland

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

[J.H.]

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

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.

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

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

[Jakub Narebski]

On Mon, 25 Jan 2010 at 16:21:51 -0800 (PST), J.H. wrote:
> >
> > 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.
> 
> 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.

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

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

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.

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

-- 
Jakub Narebski
Poland