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

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

[Junio C Hamano]

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.

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

[Jakub Narebski]

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

> ----------------------------------------------------------------
> [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.

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

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).

>  - 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.

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.

> 
> * 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.

This is I think good UI improvement.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

en/fast-export, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)

[Johannes Schindelin]

Hi,

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

> * 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?

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

Ciao,
Dscho

db/transport-shim, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)

[Johannes Schindelin]

Hi,

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

> * 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.
> 
> [...]
>
> * 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.

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

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

[Michael Haggerty]

Junio C Hamano wrote:
> * 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

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:

> Thanks, both.  I generally am not very fond of adding tests without
> intention to look into fixes, but if they make outstanding bugs more
> visible, they may have the effect of shaming the original authors
> badly enough to step in in the effort of fixing them  ;-)

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

gp/maint-rebase-p-onto, was Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)

[Johannes Schindelin]

Hi,

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

> ----------------------------------------------------------------
> [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.

Maybe better include it into 1.6.4?

Ciao,
Dscho

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

[Johannes Schindelin]

Hi,

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

> * 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...

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

Ciao,
Dscho

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

[Alex Riesen]

On Sun, Jul 26, 2009 at 10:47, Junio C Hamano<gitster@pobox.com> wrote:
> * 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.

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.

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

[Paolo Bonzini]

> * 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.

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

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

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> Is your workflow to merge next to master after the release, or do you
> cherry-pick the merges?

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.

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

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.

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

[Paolo Bonzini]

On 07/28/2009 10:01 AM, Junio C Hamano wrote:
> 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.

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