What's cooking in git.git (Aug 2008, #01; Tue, 05)
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
* jc/post-simplify (Sun Aug 3 17:47:16 2008 -0700) 3 commits
+ Topo-sort before --simplify-merges
+ revision traversal: show full history with merge simplification
+ revision.c: whitespace fix
"log --full-history" is with too much clutter, "log" itself is too cleverer
than some people, and here is the middle level of merge simplification.
* sp/smart-http (Sun Aug 3 00:25:17 2008 -0700) 2 commits
- [do not merge -- original version] Add Git-aware CGI for Git-aware
smart HTTP transport
- Add backdoor options to receive-pack for use in Git-aware CGI
The "magic" detection protocol was revised to use POST to info/refs; the
top one queued is from before that discussion.
* jc/add-stop-at-symlink (Mon Aug 4 00:52:37 2008 -0700) 2 commits
- add: refuse to add working tree items beyond symlinks
- update-index: refuse to add working tree items beyond symlinks
The performance impact of this needs to be discussed in a separate
* dp/hash-literally (Sun Aug 3 18:36:22 2008 +0400) 6 commits
+ add --no-filters option to git hash-object
+ add --path option to git hash-object
+ use parse_options() in git hash-object
+ correct usage help string for git-hash-object
+ correct argument checking test for git hash-object
+ teach index_fd to work with pipes
Gives a bit more flexibility to hash-objects by allowing us to lie about
the path the contents comes from.
* jn/svn-log (Sun Aug 3 14:07:21 2008 +0200) 1 commit
- git-svn: --clean-changelog=<style> to sanitize messages
Eric firmly rejected this one so I won't be merging this to 'next' but
this was an interesting firestarter for discussion nevertheless.
[On Hold and/or Cooking]
* rs/archive-parse-options (Fri Jul 25 12:41:26 2008 +0200) 1 commit
+ archive: allow --exec and --remote without equal sign
None of the following is for 1.6.0.
* mv/merge-custom (Sat Aug 2 10:08:38 2008 +0200) 6 commits
+ Builtin git-help.
+ builtin-help: always load_command_list() in cmd_help()
+ Add a second testcase for handling invalid strategies in git-merge
+ Add a new test for using a custom merge strategy
+ builtin-merge: allow using a custom strategy
+ builtin-help: make some internal functions available to other
* cc/merge-base-many (Sun Jul 27 13:47:22 2008 -0700) 4 commits
- git-merge-octopus: use (merge-base A (merge B C D E...)) for
+ merge-base-many: add trivial tests based on the documentation
+ documentation: merge-base: explain "git merge-base" with more than
+ merge-base: teach "git merge-base" to drive underlying
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
+ Documentation: Improve documentation for git-imap-send(1)
+ imap-send.c: more style fixes
+ imap-send.c: style fixes
+ git-imap-send: Support SSL
+ git-imap-send: Allow the program to be run from subdirectories of
a git tree
Some people seem to prefer having this feature available also with gnutls.
Such an enhancement can be done in-tree on top of this series if they are
* cc/bisect (Fri Jul 25 05:36:37 2008 +0200) 2 commits
- bisect: only check merge bases when needed
- bisect: test merge base if good rev is not an ancestor of bad rev
The first one alone does not pass its self-test but combined together they
seem to. It does not build confidence as the latter one is supposed to be
an optimization only.
* jc/add-addremove (Tue Jul 22 22:30:40 2008 -0700) 2 commits
+ builtin-add.c: optimize -A option and "git add ."
+ builtin-add.c: restructure the code for maintainability
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2008, #01; Tue, 05)
Junio C Hamano <[hidden email]> wrote:
> [New Topics]
> * sp/smart-http (Sun Aug 3 00:25:17 2008 -0700) 2 commits
> - [do not merge -- original version] Add Git-aware CGI for Git-aware
> smart HTTP transport
> - Add backdoor options to receive-pack for use in Git-aware CGI
> The "magic" detection protocol was revised to use POST to info/refs; the
> top one queued is from before that discussion.
I'm surprised you queued these. They really are not ready for
application to a tree. For example the CGI is really messed up for
trying to do Transfer-Encoding: chunked on its own, JH was right and
Apache does it for us. That removed a good chunk of code from it.
Writing the client for this is slightly non-trivial. I more-or-less
want to shove it into send-pack, not http-push, as the bulk of the
protocol we need to speak is there in send-pack.
Anyway, I'm going to try to get back to this topic more later
this week. I have been focusing on JGit this week (or at least
trying to) as I really need to get some stuff done there for EGit.