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.
----------------------------------------------------------------
* ph/strbuf (Thu Sep 27 13:33:19 2007 +0200) 44 commits
+ Make read_patch_file work on a strbuf.
+ strbuf_read_file enhancement, and use it.
+ strbuf change: be sure ->buf is never ever NULL.
+ double free in builtin-update-index.c
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
...
Will be in 'master' soon. We've seen nice linecount reduction
and the end result is rather pleasant to read.
* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits
+ git-am: fix typo in the previous one.
+ git-am: make the output quieter.
Response against recent "rebase being too chatty" complaints.
This should be a 'master' material.
* ap/dateformat (Fri Sep 28 15:17:45 2007 +0100) 3 commits
+ Make for-each-ref's grab_date() support per-atom formatting
+ Make for-each-ref allow atom names like "<name>:<something>"
+ parse_date_format(): convert a format name to an enum date_mode
With some test suite additions, this could go to 'master' soon.
Yes, that's a HINT, people ;-).
* je/hooks (Wed Sep 26 15:31:01 2007 -0600) 1 commit
+ post-checkout hook, tests, and docs
Will be in 'master' soon.
* db/fetch-pack (Mon Oct 1 00:59:39 2007 +0100) 49 commits
+ fetch/push: readd rsync support
+ Introduce remove_dir_recursively()
+ bundle transport: fix an alloc_ref() call
+ Allow abbreviations in the first refspec to be merged
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
...
Has been cooking for quite long time.
There was a regression that made me quite unhappy about the
rewrite, but Daniel fixed it, so I should be happy. There is
another usability regression: http transport is now totally
silent. Even when you fetch daily, if the other end frequently
repacks everything into one big ball of wax like repo.or.cz
does, you will end up transferring quite a large pack every
time, and the total lack of progress report is unacceptably
unnerving. At least we should reinstate "Fetching blah from URL
using http", and preferrably "walk $object_name" lines. The
latter could be replaced with just series of CR + "walked N
commits..." if we do not like many output from the current "walk
$object_name" lines scrolling the other information away.
I am not sure the quality of "rsync" transport near the tip,
either, but at least the change should not affect other
transports. Nobody should using about rsync transport these
days anyway. Perhaps we should put a deprecation notice in the
release notes to 1.5.4, and remove it three months later.
* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
+ git-gc --auto: run "repack -A -d -l" as necessary.
+ git-gc --auto: restructure the way "repack" command line is built.
+ git-gc --auto: protect ourselves from accumulated cruft
+ git-gc --auto: add documentation.
+ git-gc --auto: move threshold check to need_to_gc() function.
+ repack -A -d: use --keep-unreachable when repacking
+ pack-objects --keep-unreachable
+ Export matches_pack_name() and fix its return value
+ Invoke "git gc --auto" from commit, merge, am and rebase.
+ Implement git gc --auto
I think this one is reasonably sane, but I was the one who wrote
it so people should take that with a grain of salt. What it is
and isn't:
- "gc --auto" is a way to prevent you from keeping your
repository _grossly_ inefficient. Ideally, if you ever
rapacked your repository once, and do the regular repository
maintenance ("'git gc' before you leave for lunch every other
day"), it should never trigger.
- "gc --auto" is not something you can background. We do not
want to lock the repository and worry about associated stale
lock, expiry etc. The complexity is not worth it, compared
to the stated purpose above (I suspect it might already be
safe to run multiple instances at the same time, but the
effort to analyze if it is is not even worth, compared to the
stated purpose above. Just let it run synchronously if it
triggers, but it should not trigger for you).
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commits
+ rebase -i: work on a detached HEAD
Will be in 'master', together with "gc --auto", soon.
* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
+ Don't use "<unknown>" for placeholders and suppress printing of
empty user formats.
Will be in 'master' soon.
* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
+ git-merge: add --ff and --no-ff options
+ git-merge: add support for --commit and --no-squash
+ git-merge: add support for branch.<name>.mergeoptions
+ git-merge: refactor option parsing
+ git-merge: fix faulty SQUASH_MSG
+ Add test-script for git-merge porcelain
Will be in 'master' soon.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
Instead of refusing to rebase, telling you that your work tree
is dirty, this stashes your local changes, runs rebase and then
unstashes automatically. That _sounds_ nicer and easier to use,
but I am not sure if it is a wise/sane thing to do. We may want
to revert the "autostash" from rebase. Opinions?
* kh/commit (Mon Sep 17 20:06:47 2007 -0400)
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
+ rerere: Fix use of an empty strbuf.buf
+ Small cache_tree_write refactor.
...
Stalled.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
Stalled. This is about my pet-peeve that log (diff-tree) family
has much limited pathspec semantics. It should learn to glob
like ls-files and grep do.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
