What's cooking in git.git (topics)

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

* np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits
 + pack-objects: better check_object() performances
 + add get_size_from_delta()
 + pack-objects: make in_pack_header_size a variable of its own
 + pack-objects: get rid of create_final_object_list()
 + pack-objects: get rid of reuse_cached_pack
 + pack-objects: clean up list sorting
 + pack-objects: rework check_delta_limit usage
 + pack-objects: equal objects in size should delta against newer
   objects
 + pack-objects: optimize preferred base handling a bit
 + clean up add_object_entry()
 + tests for various pack index features
 + use test-genrandom in tests instead of /dev/urandom
 + simple random data generator for tests
 + validate reused pack data with CRC when possible
 + allow forcing index v2 and 64-bit offset treshold
 + pack-redundant.c: learn about index v2
 + show-index.c: learn about index v2
 + sha1_file.c: learn about index version 2
 + index-pack: learn about pack index version 2
 + pack-objects: learn about pack index version 2
 + compute object CRC32 with index-pack
 + compute a CRC32 for each object as stored in a pack
 + add overflow tests on pack offset variables
 + make overflow test on delta base offset work regardless of
   variable size
 + get rid of num_packed_objects()

Nico's "optionally 64-bit pack idx" aka idx format version 2.
I've taken another pass at them and am planning to push them out
on 'master' hopefully this weekend, but a documentation update
that mention the new --index-version option to git-pack-objects
would be nice to have before that happens.

* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 3 commits
 - Make the object lookup hash use a "object index" instead of a
   pointer
 + Clean up object creation to use more common code
 + Use proper object allocators for unknown object nodes too

The bottom 2 are genuine clean-ups, and I'd like to push them
out to 'master' this weekend after giving them one last look.

* jc/attr (Wed Apr 18 16:16:37 2007 -0700) 19 commits
 + Fix funny types used in attribute value representation
 + Allow low-level driver to specify different behaviour during
   internal merge.
 + Custom low-level merge driver: change the configuration scheme.
 + Allow the default low-level merge driver to be configured.
 + Custom low-level merge driver support.
 + Add a demonstration/test of customized merge.
 + Allow specifying specialized merge-backend per path.
 + merge-recursive: separate out xdl_merge() interface.
 + Allow more than true/false to attributes.
 + Document git-check-attr
 + Change attribute negation marker from '!' to '-'.
 + Define a built-in attribute macro "binary".
 + attribute macro support
 + Makefile: add patch-ids.h back in.
 + Fix 'diff' attribute semantics.
 + Fix 'crlf' attribute semantics.
 + Teach 'diff' about 'diff' attribute.
 + Define 'crlf' attribute.
 + Add basic infrastructure to assign attributes to paths

You've heard a lot of noises between me and Linus on this one
for the past few days.  Remaining tasks before it can graduate
to 'master' are:

 (1) I haven't decided how to allow the merge driver override
     the decision to punt on symlinks and some other minor
     policy decision merge-recursive hardcodes yet;

 (2) Not enough test coverage;

 (3) No documentation other than my e-mail messages to the list
     and commit log messages as to how you use this stuff;

 (4) Example "low level merge driver" scripts; covering the same
     set of tools git-mergetool knows about would be good.

Help from the list, probably starting from (3) and (4), would
help polish the series and squash any remaining bugs.

We could do $blobid$ only keywords by hooking into this, but
that would involve philosophical discussion and I'd rather
postpone that and have the infrastructure in 'master' first.

* jp/refs (Tue Apr 17 02:42:50 2007 +0100) 1 commit
 + refs.c: add a function to sort a ref list, rather then sorting on
   add
* jc/quickfetch (Mon Apr 16 00:42:29 2007 -0700) 3 commits
 + Make sure quickfetch is not fooled with a previous, incomplete
   fetch.
 + git-fetch: use fetch--tool pick-rref to avoid local fetch from
   alternate
 + git-fetch--tool pick-rref

I think these two topics should graduate to 'master' this
weekend, as I haven't heard any breakage from anybody, and they
do seem to help.

* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits
 + Expose subprojects as special files to "git diff" machinery
 + Fix some "git ls-files -o" fallout from gitlinks
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic to not follow gitlinks
 + Fix gitlink index entry filesystem matching
 + Teach "git-read-tree -u" to check out submodules as a directory
 + Teach git list-objects logic not to follow gitlinks
 + Don't show gitlink directories when we want "other" files
 + Teach git-update-index about gitlinks
 + Teach directory traversal about subprojects
 + Fix thinko in subproject entry sorting
 + Teach core object handling functions about gitlinks
 + Teach "fsck" not to follow subproject links
 + Add "S_IFDIRLNK" file mode infrastructure for git links
 + Add 'resolve_gitlink_ref()' helper function
 + Avoid overflowing name buffer in deep directory structures
 + diff-lib: use ce_mode_from_stat() rather than messing with modes
   manually

Stalled; Alex has a set of tests that should go on top of this
series but I haven't taken a look at it yet.  I think we should
have enough for interested people to start futzing with, and I
am wondering why nobody has sent a note saying "Hey, I did this
using tree objects with commits in it, it works nicely for these
operations but these things are still cumbersome to do and I
need to polish it more".

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

A small part of libification; nobody seems to want it.

* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up
 - blame -s: suppress author name and time.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Stalled.

Junio C Hamano, Thu, Apr 19, 2007 02:04:13 +0200:

Stalled; Alex has a set of tests that should go on top of this
series but I haven't taken a look at it yet.  I think we should
have enough for interested people to start futzing with, and I
am wondering why nobody has sent a note saying "Hey, I did this
using tree objects with commits in it, it works nicely for these
operations but these things are still cumbersome to do and I
need to polish it more".

I am setting up a super-repo for my own very private use (small home
server setup). Still working on what _recursive_ tools do I really
need (and fsck is not the most interesting one: git-diff-files is. Am
afraid of releasing a system I wont ever be able to get to the source
of).

It is, as predicted, becoming mostly work on build infrastructure and
integrity checks in the super-project. Being the sole user of this
project I'll definitely miss all the issues of really big modularized
projects, though.

* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits
 - Make read-cache.c "the_index" free.
 - Move index-related variables into a structure.

A small part of libification; nobody seems to want it.

No user _can_ want it. We need to make the future less a nightmare (it
may not even become one).

On Wed, 18 Apr 2007, Junio C Hamano wrote:

* np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits

Nico's "optionally 64-bit pack idx" aka idx format version 2.
I've taken another pass at them and am planning to push them out
on 'master' hopefully this weekend, but a documentation update
that mention the new --index-version option to git-pack-objects
would be nice to have before that happens.

Well... In fact I didn't intend for that option to ever be used by 
anything but test scripts in order to trigger some code paths without 
generating jumbo packs (don't know what people would think of me if I 
created a 8GB pack in my test ;-)).  Therefore I didn't think that 
option was worth documenting.

But if you insist I'll send you a patch.


Nicolas

hoi :)

On Wed, Apr 18, 2007 at 05:04:13PM -0700, Junio C Hamano wrote:

* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits

Stalled; Alex has a set of tests that should go on top of this
series but I haven't taken a look at it yet.  I think we should
have enough for interested people to start futzing with, and I
am wondering why nobody has sent a note saying "Hey, I did this
using tree objects with commits in it, it works nicely for these
operations but these things are still cumbersome to do and I
need to polish it more".

You know that I am interested, but sadly I don't have as much time to
really have a look / work on it as I'd liked.  But Linus' series
looks very good from what I've seen now.
Conceptually Linus approach is very much identical my prototyping work
and I am convinced that it is the right way to go.  Only his code is
much better (hey, it's Linus after all ;-) and about our branch-vs-HEAD
discussion, well we'll see how it works out.

Now, how to go on?
The next thing we need is a real checkout & merge support -- but that
is not that hard.
Then we need to think about how to handle the submodule object database,
e.g. when fetching.

I'd also like to be able to support bare supermodule repositories which
include all neccessary submodule objects.  But I guess we need some
more experience with submodules before we can solve that in a scalable
way.

-- 
Martin Waitz