What's cooking in git.git (Jul 2009, #02; Sun, 26)

These topics in 'next' (ones prefixed with '+') and 'pu' (ones prefixed with '.') will not be in 1.6.4 final, and are subject to be rewound once 1.6.4 final happens.

We have quite a few solid topics in 'next', so hopefully the next cycle would be shorter than usual. I'd propose to call it 1.6.5, and then make the one after that 1.7.0, which means that during the 1.6.5 cycle, 'next' will have the two incompatible "push" (actually, receive-pack) changes hitherto kept on hold in 'pu'.

---------------------------------------------------------------- [New Topics]

* jk/show-tag (Sat Jul 18 06:14:37 2009 -0400) 2 commits
 + show: add space between multiple items
 + show: suppress extra newline when showing annotated tag

Didn't look bad at all, but is not pressing either.

* sb/parse-options (Tue Jul 7 22:15:41 2009 -0700) 4 commits
 + prune-packed: migrate to parse-options
 + verify-pack: migrate to parse-options
 + verify-tag: migrate to parse-options
 + write-tree: migrate to parse-options

* mk/grep-max-depth (Wed Jul 22 19:52:15 2009 +0200) 1 commit
 + grep: Add --max-depth option.

* jn/gitweb-blame (Sat Jul 25 00:44:10 2009 +0200) 10 commits
 - gitweb: Create links leading to 'blame_incremental' using
   JavaScript
 - gitweb: Incremental blame (proof of concept)
 - gitweb: Add optional "time to generate page" info in footer
 - gitweb: Add -partial_query option to href() subroutine
 - gitweb: Use light/dark for class names also in 'blame' view
 - gitweb: Add author initials in 'blame' view, a la "git gui blame"
 - gitweb: Mark commits with no "previous" in 'blame' view
 - gitweb: Use "previous" header of git-blame -p in 'blame' view
 - gitweb: Mark boundary commits in 'blame' view
 - gitweb: Make .error style generic

Still in flux/rfc.

* ns/init-mkdir (Sat Jul 25 06:59:28 2009 +0900) 1 commit
 + git init: optionally allow a directory argument

Didn't look bad, but is not pressing either.

* jc/apply-epoch-patch (Fri Jul 10 18:38:08 2009 -0700) 1 commit
 + apply: notice creation/removal patches produced by GNU diff

* sb/pull-rebase (Sun Jul 19 09:45:16 2009 +0200) 2 commits
 + pull: support rebased upstream + fetch + pull --rebase
 + t5520-pull: Test for rebased upstream + fetch + pull --rebase

* db/transport-shim (Sat Jul 25 13:51:40 2009 -0400) 3 commits
 - git-http-fetch: not a builtin
 - Use an external program to implement fetching with curl
 - Add support for external programs for handling native fetches

Interesting as a concept. I saw its ls-remote segfault on me, though. Hopefully will mature by 1.6.5 final.

* pb/tracking (Thu Jul 16 16:26:15 2009 -0500) 7 commits
 + branch.c: if remote is not config'd for branch, don't try delete
   push config
 + branch, checkout: introduce autosetuppush
 + move deletion of merge configuration to branch.c
 + remote: add per-remote autosetupmerge and autosetuprebase
   configuration
 + introduce a struct tracking_config
 + branch: install_branch_config and struct tracking refactoring
 + config: allow false and true values for branch.autosetuprebase

After some discussion, I suspect we may want to rewind this out of 'next' and start over with a fresh design.

* mk/init-db-parse-options (Sun Jul 12 12:24:32 2009 +0200) 1 commit
 + init-db: migrate to parse-options

* tr/reset-checkout-patch (Sat Jul 25 23:29:34 2009 +0200) 5 commits
 - Implement 'git stash save --patch'
 - Implement 'git checkout --patch'
 - Implement 'git reset --patch'
 - builtin-add: refactor the meat of interactive_add()
 - git-apply--interactive: Refactor patch mode code

Still in flux/rfc.

---------------------------------------------------------------- [Stalled and may need help and prodding to go forward]

* gp/maint-rebase-p-onto (Wed Jul 22 12:38:58 2009 -0400) 1 commit
 . Fix rebase -p --onto

I'd say we should take this even if it means Dscho needs his rebase -p rewrite. It is not very pressing, so perhaps do so immediately after 1.6.4 final.

* jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits
 - Teach "-m <msg>" and "-F <file>" to "git notes edit"
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

Dscho asked about the performance implications of this; I do not think I saw any progress on that yet...

Will drop after 1.6.4 unless any further progress is seen.

* ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits
 - Fix for a merge where a branch has an F->D transition
 - Add a reminder test case for a merge with F/D transition

Although the reported breakage is covered with the patch, Alex feels the solution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive may be long overdue but seems to be a hard problem.

* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
 - blame.c: start libifying the blame infrastructure

A few minor point remains in this initial one.

Will drop after 1.6.4 unless any further progress is seen.

* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
 - Allow --date=local --date=other-format to work as expected

The one I posted had a few corner-case bugs that was caught with the test suite; this one has them fixed. People did not like the UI so it is kept out of 'next'

Will drop after 1.6.4 unless any further progress is seen.

* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
 - git-merge-file: allow converting the results for the work tree

This is a feature waiting for a user.

We did not give scripted Porcelains a way to say "this temporary file I am using for merging is for this path, so use the core.autocrlf and attributes rules for that final path". Instead, merge-file simply wrote out the data in the canonical repository representation.

rerere has the same issue, but it is a lot worse. It reads the three files (preimage, postimage and thisimage) from the work tree in the work tree representation, merges them without converting them to the canonical representation first but inserts the conflict markers with the canonical representation and writes the resulting mess out. It needs to be fixed to read with convert_to_git(), merge them while they are still in the canonical representation and possibly add conflict markers, and then write the results out after convert_to_working_tree(). It also needs to write in binary mode as well.

Will drop after 1.6.4 unless any further progress is seen.

* db/foreign-scm (Tue Mar 24 23:04:12 2009 -0400) 3 commits
 - Add option for using a foreign VCS
 - Document details of transport function APIs
 - Allow late reporting of fetched hashes

I have a feeling that the recent transport-shim series from the same author could supersede this one.

* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits
 - t/t9600: remove exit after test_done
 - cvsimport: extend testcase about patchset order to contain
   branches
 - cvsimport: add test illustrating a bug in cvsps
 - Add a test of "git cvsimport"'s handling of tags and branches
 - Add some tests of git-cvsimport's handling of vendor branches
 - Test contents of entire cvsimported "master" tree contents
 - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
 - Start a library for cvsimport-related tests

---------------------------------------------------------------- [Not actively cooking]

* js/run-command-updates (Sat Jul 4 21:26:43 2009 +0200) 6 commits
 + receive-pack: remove unnecessary run_status report
 + run_command: report failure to execute the program, but optionally
   don't
 + run_command: encode deadly signal number in the return value
 + run_command: report system call errors instead of returning error
   codes
 + run_command: return exit code as positive value
 + MinGW: simplify waitpid() emulation macros

Will merge after 1.6.4

* cc/sequencer-rebase-i (Fri Jun 26 23:08:46 2009 +0200) 4 commits
 - rebase -i: use "git sequencer--helper --make-patch"
 - sequencer: free memory used in "make_patch" function
 - sequencer: add "make_patch" function to save a patch
 - sequencer: add "builtin-sequencer--helper.c"

* en/fast-export (Thu Jun 25 22:48:33 2009 -0600) 7 commits
 + fast-export: Document the fact that git-rev-list arguments are
   accepted
 + Add new fast-export testcases
 + fast-export: Add a --tag-of-filtered-object option for newly
   dangling tags
 + fast-export: Do parent rewriting to avoid dropping relevant
   commits
 + fast-export: Make sure we show actual ref names instead of
   "(null)"
 + fast-export: Omit tags that tag trees
 + fast-export: Set revs.topo_order before calling setup_revisions

Shawn?  Dscho?

* jc/diff-whitespace-only-status (Sat May 23 01:15:35 2009 -0700) 2 commits
 + diff: Rename QUIET internal option to QUICK
 + diff: change semantics of "ignore whitespace" options

Possibly merge during 1.6.5, or 1.7.0 since this is a semantics change.

* sb/read-tree (Thu Jun 25 22:14:10 2009 -0700) 2 commits
 + read-tree: migrate to parse-options
 + read-tree: convert unhelpful usage()'s to helpful die()'s

Will merge after 1.6.4

* ne/futz-upload-pack (Wed Jun 10 01:50:18 2009 +0200) 1 commit
 + Shift object enumeration out of upload-pack

Will merge after 1.6.4

* cc/replace (Wed May 27 07:14:09 2009 +0200) 14 commits
 + t6050: check pushing something based on a replaced commit
 + Documentation: add documentation for "git replace"
 + Add git-replace to .gitignore
 + builtin-replace: use "usage_msg_opt" to give better error messages
 + parse-options: add new function "usage_msg_opt"
 + builtin-replace: teach "git replace" to actually replace
 + Add new "git replace" command
 + environment: add global variable to disable replacement
 + mktag: call "check_sha1_signature" with the replacement sha1
 + replace_object: add a test case
 + object: call "check_sha1_signature" with the replacement sha1
 + sha1_file: add a "read_sha1_file_repl" function
 + replace_object: add mechanism to replace objects found in
   "refs/replace/"
 + refs: add a "for_each_replace_ref" function

* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
 - receive-pack: default receive.denyDeleteCurrent to refuse

* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
 - Refuse updating the current branch in a non-bare repository via
   push

These are for 1.7.0, but the messages when they trigger together may need to be rethought. Will be kept in 'next' during 1.6.5 cycle.

---------------------------------------------------------------- [Dropped]

* ae/maint-mailinfo-rm-only-one-patch-marker (Mon Jun 29 11:55:51 2009 +0200) 1 commit
 - mailinfo: Remove only one set of square brackets

* lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits
 . Add initial support for pathname conversion to UTF-8
 . read_directory(): infrastructure for pathname character set
   conversion
 . Add 'fill_directory()' helper function for directory traversal

It appears that we may want to settle with a MacOS X specific conversion, if somebody really cares enough.

Junio C Hamano <gitster@pobox.com> writes:

I like the output of "git show <tag>" much better than current one
(where I sometimes fall back on "git cat-file -p <tag>").
 

This part (above) is RFC, especially the 'incremental blame' patch, which is in flux.

Well, perhaps except 'time to generate page' (aka. 'timed' feature), but even this still have some things (like name of feature enabling this behavior: currently 'named', or unconditional requiring Time::HiRes if it exists even if it is not needed).

This part is, I think, good now (after fixing embarassing but harmless unquote_maybe() incident ;-)). Junio had some questions about style used, but it can be very easily fiddled with later, IMVHO.

This is I think good UI improvement.

Hi,

On Sun, 26 Jul 2009, Junio C Hamano wrote:

I think that those changes are good, even for 1.6.4.

Ciao, Dscho

Hi,

On Sun, 26 Jul 2009, Junio C Hamano wrote:

Oh, you mean that the foreign scm helpers would turn into shim helpers, which could then either call fast-import directly or use another helper?

Interesting, Dscho

Junio C Hamano wrote:

What needs to happen to get these changes moving again? The last relevant comment I can find from you about this subject is from 2009-02-22:

No knight in shining armor has shown up to fix these bugs, but there is still value to documenting them in the form of unit tests.

Michael

Hi,

On Sun, 26 Jul 2009, Junio C Hamano wrote:

Maybe better include it into 1.6.4?

Ciao, Dscho

Hi,

On Sun, 26 Jul 2009, Junio C Hamano wrote:

I didn't see any progress, either.  And I am very disappointed.

Ciao, Dscho

On Sun, Jul 26, 2009 at 10:47, Junio C Hamano<gitster@pobox.com> wrote:

Maybe promote the testcase patch to master and drop (or leave it in next) the other patch? So that the reminder reminds not only people running next but also anyone who happens to look at the output of their test suite run.

Is your workflow to merge next to master after the release, or do you cherry-pick the merges? If the latter, I propose that instead you graduate to master only the first five patches (e.g. as pb/per-remote-tracking).

I'd rather not see the series reverted until there is some code for the fresh design. While I like it overall, I tried implementing it and I could not really do it in a nice way (I could not even find a way to nicely separate changes).

Do you plan to merge at least the first two patches of "git push --current" (i.e. without the config option)? Do you want me to resend them separately?

I will also separate from the --push series in two parts the patch that reuse "git remote" code in "git clone", so that you can get the first one as a cleanup and I can resubmit the rest later if the fresh design does not work out. I'll submit it after 1.6.4.

Paolo

Paolo Bonzini <bonzini@gnu.org> writes:

Usually 'next' will never rewind, and topics graduate by merging into 'master', either as a whole or in steps.

But I've kept 'next' and 'pu' deliberately more inclusive during this -rc period, knowing that people by now would be very well aware that after the final release of 1.6.4, 'next' will be discarded and rebuilt with a few selected topics. That means what currently is in 'next' can be safely kicked back to 'pu' or discarded if it turns out to be necessary.

If you have doubts or regrets in the series currently in 'next', you can even send in replacements if you want to (which is not how 'next' works normally). I can revert the merge of the original series to 'next' and merge the replacements during -rc period. After 1.6.4, I can discard the original series and keep only the updated series.

On the other hand, if you want to keep going incremental, which is how 'next' is supposed to work, that is perfectly Ok, too. After 1.6.4, we can decide what to do.

I am not quite sure if that is a good approach. If the design is in flux, perhaps we should cook the code in 'pu' a bit longer until we know what end user interface want? The last thing I want to do is to give end users a set of new command line options in 'master' (or even 'next'), only to revoke them before the next release.

On 07/28/2009 10:01 AM, Junio C Hamano wrote:

Agreed. However, some people expressed appreciation for the new git-push command-line option independent of the push.tracking work, of which I'd guess they might not even be aware. If you agree, I would leave in pu the third patch ("add remote.*.pushHeadOnly") while merging the first two to next.

Paolo