Re: What's cooking in git.git (topics)
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Sep 26, 2007, 21:44 UTC
- Message-ID
- <Pine.LNX.4.64.0709262159430.28395@racer.site>
- In-Reply-To
- <7vfy11yyxk.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 26 Sep 2007, Junio C Hamano wrote:
Show 7 quoted lines
> * 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.
Show 11 quoted lines
> * 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.
Show 5 quoted lines
> * 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.
Show 14 quoted lines
> * 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?
Show 15 quoted lines
> * 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...
Show 11 quoted lines
> * 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.
Show 8 quoted lines
> * 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