eyecatchu/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2026-01-21 22:37:17 +09:00
Code Issues Packages Projects Releases Wiki Activity

What's cooking (2008/07 #10)

Browse Source
This commit is contained in:
Junio C Hamano 2008-08-05 21:44:16 -07:00
parent 4db27779c2
commit a347bca37f
1 changed files with 56 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

198
whats-cooking.txt
View File

@ -1,7 +1,7 @@
Subject: What's cooking in git.git (Jul 2008, issue #09; Sun, 20)
Subject: What's cooking in git.git (Jul 2008, #11; Thu, 31)
What's cooking in git.git (Jul 2008, issue #09; Sun, 20)
--------------------------------------------------------
What's cooking in git.git (Jul 2008, #11; Thu, 31)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
@ -19,160 +19,75 @@ to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc0 (Jul 20)
- 1.6.0-rc1 (Jul 23)
- 1.6.0-rc2 (Jul 30)
- 1.6.0-rc3 (Aug 6)
- 1.6.0 (Aug 10)
- 1.6.0-rc2 (Aug 3)
- 1.6.0-rc3 (Aug 10)
----------------------------------------------------------------
[New Topics]
* pb/sane-mv (Mon Jul 21 02:25:56 2008 +0200) 2 commits
- git-mv: Keep moved index entries inact
- git-mv: Remove dead code branch
* rs/archive-parse-options (Fri Jul 25 12:41:26 2008 +0200) 1 commit
+ archive: allow --exec and --remote without equal sign
Running "git mv A B" when you have local changes to A automatically staged
it while moving it to B, which was a longstanding nonsense. This attempts
to fix it. Pasky has other plans to build on a more solidified foundation
to enhance the command to work with submodules better on top of this.
None of the following is for 1.6.0.
* mv/merge-custom (Thu Jul 31 00:38:07 2008 +0200) 5 commits
+ 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
builtins
* 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
stepwise merge
+ merge-base-many: add trivial tests based on the documentation
+ documentation: merge-base: explain "git merge-base" with more than
2 args
+ merge-base: teach "git merge-base" to drive underlying
merge_bases_many()
* jc/simplify-merges (Thu Jul 31 01:17:41 2008 -0700) 1 commit
. revision traversal: show full history with merge simplification
"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.
----------------------------------------------------------------
[Graduated to "master"]
[On Hold and/or Cooking]
* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
+ git am --abort
This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.
* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
+ rerere.autoupdate: change the message when autoupdate is in effect
This one is for Ingo.
This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.
It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future. When that happens, these messages will make the distinction
clearer.
* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
+ Reword "your branch has diverged..." lines to reduce line length
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
- Document that merge strategies can now take their own options
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.
Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.
----------------------------------------------------------------
[Stalled/Needs more work]
None of the following is for 1.6.0.
* 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
+ 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
I said: "Some people seem to prefer having this feature available also
with gnutls. If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'. Such an enhancement can be
done in-tree on top of this series." Anybody?
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
so inclined.
* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
. cherry: cache patch-ids to avoid repeating work
* 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 discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.
* 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
* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
. gitweb: use new Git::Repo API, and add optional caching
. Add new Git::Repo API
. gitweb: add test suite with Test::WWW::Mechanize::CGI
* jk/pager-swap (Tue Jul 22 03:14:12 2008 -0400) 2 commits
+ spawn pager via run_command interface
+ run-command: add pre-exec callback
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
This changes the parent-child relationship between the pager and the git
process. We used to make pager the parent which meant that the exit
status from git is lost from the caller.
I haven't looked at the updated series yet. I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable. Summer is slower ;-)
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
This is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.
----------------------------------------------------------------
[Dropped]
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
- Document that merge strategies can now take their own options
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.
Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.
----------------------------------------------------------------
[On Hold]
* ph/enable-threaded (Mon Jul 21 11:23:43 2008 +0200) 1 commit
+ Enable threaded delta search on *BSD and Linux.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
@ -192,9 +107,8 @@ This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
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.