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.
* jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
+ diffcore-rename: cache file deltas
Parked in 'next' for now but is 'master' material.
* 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.
Parked in 'next'; I was already burned by it not passing one of
the test cases, and I am not absolutely certain what else this
subtly breaks. Hopefully minor.
* jb/remote-rm (Sun Sep 23 22:29:12 2007 -0700) 3 commits
+ git-remote rm: add tests and minor fix-ups
+ remote: document the 'rm' subcommand
+ remote: add 'rm' subcommand
Should be Ok to push out to 'master'.
* ml/submodule (Sun Sep 23 22:19:42 2007 -0400) 1 commit
+ git-submodule - allow a relative path as the subproject url
Should be Ok to push out to 'master'.
* 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
Comments? I personally never felt need for --no-ff but the
series is reasonably clean so I do not see strong objection
against this series either.
* sv/svn (Fri Sep 21 15:27:01 2007 +1200) 3 commits
+ git-svn: handle changed svn command-line syntax
+ git-svn: fix test for trunk svn (transaction out of date)
+ git-svn: fix test for trunk svn (commit message not needed)
Will merge to 'master' this weekend.
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
+ rebase -i: work on a detached HEAD
Waiting for autogc change as this textually interacts with it,
and the additional convenience can wait.
* 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 the only remaining thing left with this thing is to
prevent more than one instances of it from running at the same
time. Any takers?
* ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
+ Small cache_tree_write refactor.
+ Make builtin-rerere use of strbuf nicer and more efficient.
+ Add strbuf_cmp.
+ strbuf_setlen(): do not barf on setting length of an empty buffer
to 0
+ sq_quote_argv and add_to_string rework with strbuf's.
+ Full rework of quote_c_style and write_name_quoted.
+ ...
I had to make a small fix-up to strbuf_setlen() last night to
this series; this should be ready for 'master'.
And it is better to push this out early, as the series touches
everywhere and conflicts with peoples' patches.
* db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
+ Cleanup style nit of 'x == NULL' in remote.c
+ Fix memory leaks when disconnecting transport instances
+ Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
+ ...
Two issues known to me are:
- "rsync" transport is not supported yet;
- regresses "git pull <name>" using .git/remotes/<name>; does
not merge the first refspec when branch.<name>.merge is not
set.
There may be others but some people apparently use this in
production (including me) and I do not expect major breakages in
the really essential part.
* ss/svnimport (Mon Sep 24 12:57:40 2007 +0200) 1 commit
+ Fix pool handling in git-svnimport to avoid memory leaks.
This is meant to eventually go to 'maint' as well but with
diminishing user base of svnimport it is getting harder to get
good "tested successfully, seen improvements" reports.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
I think "stash create" is going in a good direction, but I do
not think rebase should unstash unconditionally on the resulting
work tree. A good compromise might be not to unstash if the
user asked to switch branches first and to unstash if he didn't.
* kh/commit (Mon Sep 17 20:06:48 2007 -0400) 7 commits
- Implement git commit as a builtin command.
- Export rerere() and launch_editor().
- Add strbuf_read_file().
- Clean up stripspace a bit, use strbuf even more.
- Introduce entry point for launching add--interactive.
- Enable wt-status to run against non-standard index file.
- Enable wt-status output to a given FILE pointer.
There were a few updates/replacements to the list I missed;
* gr/smtp (Tue Sep 25 17:27:54 2007 -0700) 2 commits
- [TO BE SQUASHED] Fix-up after review
- Add ability to specify SMTP server port when using git-send-email.
Will be in 'next'.
Hi,
On Wed, 26 Sep 2007, Junio C Hamano wrote:
* 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.
Parked in 'next'; I was already burned by it not passing one of the test
cases, and I am not absolutely certain what else this subtly breaks.
Hopefully minor.
I guess a few scripts could maybe rely on this behaviour. We should
advertise it as such.
* 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
Comments? I personally never felt need for --no-ff but the series is
reasonably clean so I do not see strong objection against this series
either.
Together with a resubmitted git-merge-rebase.sh (hint, hint), the
mergeOptions would be quite useful for a workflow where you want to rebase
on top of an upstream quite often.
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
+ rebase -i: work on a detached HEAD
Waiting for autogc change as this textually interacts with it, and the
additional convenience can wait.
Sure. I never used it anyway, but you specifically requested it ;-) BTW
thanks for merging the rest; especially the progress meter was a sore
point for me since long.
* 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 the only remaining thing left with this thing is to prevent more
than one instances of it from running at the same time. Any takers?
You mean, just creating a throw-away lock file?
* ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
+ Small cache_tree_write refactor.
+ Make builtin-rerere use of strbuf nicer and more efficient.
+ Add strbuf_cmp.
+ strbuf_setlen(): do not barf on setting length of an empty buffer
to 0
+ sq_quote_argv and add_to_string rework with strbuf's.
+ Full rework of quote_c_style and write_name_quoted.
+ ...
I had to make a small fix-up to strbuf_setlen() last night to this
series; this should be ready for 'master'.
And it is better to push this out early, as the series touches
everywhere and conflicts with peoples' patches.
Hehe. Indeed, I had to fix the notes series after rebasing it...
* db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
+ Cleanup style nit of 'x == NULL' in remote.c
+ Fix memory leaks when disconnecting transport instances
+ Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
+ ...
Two issues known to me are:
- "rsync" transport is not supported yet;
I promised to do this, and so I will today.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
I think "stash create" is going in a good direction, but I do not think
rebase should unstash unconditionally on the resulting work tree. A
good compromise might be not to unstash if the user asked to switch
branches first and to unstash if he didn't.
Sounds like a sensible change to me; maybe a little warning after the
rebase?
I have no idea if I come around to do the same for rebase--interactive any
time soon, though.
Ciao,
Dscho
On 9/26/07, Johannes Schindelin [off-list ref] wrote:
Together with a resubmitted git-merge-rebase.sh (hint, hint), the
mergeOptions would be quite useful for a workflow where you want to rebase
on top of an upstream quite often.
I'll resubmit merge rebase tomorrow :-)
-Tom
On Wed, Sep 26, 2007 at 01:05:59PM -0700, Junio C Hamano wrote:
* jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
+ diffcore-rename: cache file deltas
Parked in 'next' for now but is 'master' material.
My tests after this patch show that spanhash_find is responsible for
a large portion of the processing time in large renames, so I am going
to look into speeding that up.
* 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
Comments? I personally never felt need for --no-ff but the
series is reasonably clean so I do not see strong objection
against this series either.
I like it. I know that --no-ff is frowned upon, but I think previous
discussions have mentioned workflows where it might be used
intelligently. Since the patch is unlikely to break anything for
traditional workflows, I think it is a nice way to let people experiment
with alternative workflows that use --no-ff. Maybe something interesting
will come of it.
-Peff
On Wed, 26 Sep 2007, Junio C Hamano wrote:
* db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
+ Cleanup style nit of 'x == NULL' in remote.c
+ Fix memory leaks when disconnecting transport instances
+ Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
+ ...
Two issues known to me are:
- "rsync" transport is not supported yet;
- regresses "git pull <name>" using .git/remotes/<name>; does
not merge the first refspec when branch.<name>.merge is not
set.
Actually, I think it's only that it doesn't merge anything if the first
refspec doesn't match the first fetched ref from the server. I'm running
tests on a patch that should fix it, but I'm not sure how to write a test
for this particular case; I think the fetch tests try to test this, but
pass by chance.
-Daniel
*This .sig left intentionally blank*
On Wed, Sep 26, 2007 at 10:36:33PM -0400, Jeff King wrote:
quoted
* jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
+ diffcore-rename: cache file deltas
Parked in 'next' for now but is 'master' material.
My tests after this patch show that spanhash_find is responsible for
a large portion of the processing time in large renames, so I am going
to look into speeding that up.
Just to update, I tried using a non-colliding hash for this (at the
expense of much memory), and I wasn't able to get things much faster
(and certainly not worth the explosion in memory), short of reducing the
size of the hash (which is going to reduce the quality of the output).
So I am giving up for the time being, but if others are interested in
trying to speed things up, I would be happy to discuss ideas.
-Peff