threads / discuss / 17843

What's cooking in git.git (Feb 2009, #05; Mon, 16)

Subject: What's cooking in git.git (Feb 2009, #05; Mon, 16)

## tl;dr

10 messages between Feb 17, 2009 and Feb 18, 2009.

replies: 9people: 6as markdown or json

Junio C Hamano· Feb 17, 2009, 07:57 UTC · lore

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the branches, but I am still holding onto them.

The topics list the commits in reverse chronological order. The topics meant to be merged to the maintenance series have "maint-" in their names.

The master branch is slightly past 1.6.2-rc1.

As an experiment, 'next' and 'pu' stay open during this release freeze; new topics are accepted as time permits, but people are much more strongly encouraged to find issues on what is already on 'master', and patches to fix them always takes precedence over what is still on 'next' and will never graduate until 1.6.2 final.

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

* gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
 - gitweb: fix wrong base URL when non-root DirectoryIndex
Should this go in 1.6.2-rc2?
* tr/gcov (Sun Feb 15 23:25:45 2009 +0100) 8 commits
 - Test git-patch-id
 - Test rev-list --parents/--children
 - Test log --decorate
 - Test fsck a bit harder
 - Test log --graph
 - Test diff --dirstat functionality
 - Test that diff can read from stdin
 - Support coverage testing with GCC/gcov
* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
 - git-add -i/-p: learn to unwrap C-quoted paths

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

* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
 - stash: --keep option just saves
Do we want to keep this one?
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
 - archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
* 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 gives Porcelains (like gitweb) the information on the commit _before_ the one that the final blame is laid on, which should save them one rev-parse to dig further. The line number in the "previous" information may need refining, and sanity checking code for reference counting may need to be resurrected before this can move forward.

I thought recent tig discussion may blow new life into it, but is this unneeded? If so I'd rather revert it (or discard after 1.6.2).

* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
 - Support fetching from foreign VCSes
 - Add specification of git-vcs helpers
 - Add "vcs" config option in remotes

The "spec" did not seem quite well cooked yet, but in the longer term I think something like this to allow interoperating with other SCMs as if the other end is a native git repository is a very worthy goal.

* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
 - 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

I think the code is much cleaner than the first round, but I am not convinced it is doing the right thing in the connectivity traverser. Independent review sorely needed.

* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
 - gitweb: Optional grouping of projects by category
 - gitweb: Split git_project_list_body in two functions
 - gitweb: Modularized git_get_project_description to be more generic

Design discussion between Jakub and Sebastien seems to have stalled, but Jakub seems to be taking this over.

* jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
 - fsck: three levels of validation
 - verify-pack: add --quick
 - verify_pack(): allow a quicker verification for a pack with
   version 2 idx
 - pack-check.c: minor formatting fix to match coding style

J6t has a good point that if this had any value then medium level should replace the default. I am tempted to actually dropping this as a failed experiment.

---------------------------------------------------------------- [Reverted]

* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
 ? Revert previous two commits
 ? move the color variables to color.c
 ? handle color.ui at a central place
This broke git-format-patch badly.
* js/rebase-error-a-bit-more-verbose (Sun Feb 8 21:22:18 2009 -0800) 2 commits
 ? Revert "rebase: explain why when the HEAD could not be detached"
 ? rebase: explain why when the HEAD could not be detached
This turned out to be unnecessary.
* rs/maint-1.6.0-windows-ceiling (Sat Feb 7 12:40:40 2009 -0800) 2 commits
 ? Revert "fix t1504 on Windows"
 ? fix t1504 on Windows
I'm giving a fresh start to J6t's series which contains this.
* lh/reverted-submodule-tree-traversal (Sun Jan 25 18:39:55 2009 -0800) 4 commits
 ? Revert round #1 of the series
 ? builtin-ls-tree: enable traversal of submodules
 ? archive.c: enable traversal of submodules
 ? tree.c: add support for traversal of submodules
I'm giving a fresh start to Lars's second iteration.

---------------------------------------------------------------- [Will merge to 'next' soon]

* js/send-email (Sat Feb 14 23:32:15 2009 -0500) 3 commits
 - send-email: --suppress-cc improvements
 - send-email: handle multiple Cc addresses when reading mbox message
 - send-email: allow send-email to run outside a repo
* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
 - rerere: remove duplicated functions

---------------------------------------------------------------- [Ready for 'master' after 1.6.2]

* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
 + imap.preformattedHTML to tell Thunderbird to send non-flowed text

The patch text should be identical to Jeremy's "Virtual Patch", except that the configuration variable was renamed per list discussion.

* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
 + Enable setting attach as the default in .gitconfig for git-format-
   patch.
* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
 + Teach rebase to rebase even if upstream is up to date
* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
 + Support "\" in non-wildcard exclusion entries
* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
 + add -i: revisit hunk on editor failure
* tp/completion (Wed Feb 11 13:03:26 2009 -0500) 4 commits
 + completion: More fixes to prevent unbound variable errors
 + completion: Better __git_ps1 support when not in working directory
 + completion: Use consistent if [...] convention, not "test"
 + completion: For consistency, change "git rev-parse" to __gitdir
   calls
* js/branch-symref (Fri Feb 13 04:40:18 2009 -0500) 1 commit
 + builtin-branch: improve output when displaying remote branches
* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
 + builtin-branch.c: Rename branch category color names
 + Clean up use of ANSI color sequences
* kb/checkout-optim (Mon Feb 9 21:54:53 2009 +0100) 9 commits
 + lstat_cache(): print a warning if doing ping-pong between cache
   types
 + show_patch_diff(): remove a call to fstat()
 + write_entry(): use fstat() instead of lstat() when file is open
 + write_entry(): cleanup of some duplicated code
 + create_directories(): remove some memcpy() and strchr() calls
 + unlink_entry(): introduce schedule_dir_for_removal()
 + lstat_cache(): swap func(length, string) into func(string, length)
 + lstat_cache(): generalise longest_match_lstat_cache()
 + lstat_cache(): small cleanup and optimisation
* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
 + valgrind: do not require valgrind 3.4.0 or newer
 + test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
 + Tests: let --valgrind imply --verbose and --tee
 + Add a script to coalesce the valgrind outputs
 + t/Makefile: provide a 'valgrind' target
 + test-lib.sh: optionally output to test-results/$TEST.out, too
 + Valgrind support: check for more than just programming errors
 + valgrind: ignore ldso and more libz errors
 + Add valgrind support in test scripts

---------------------------------------------------------------- [Actively cooking]

* js/notes (Sat Feb 14 21:23:25 2009 +0100) 13 commits
 - notes: refuse to edit notes outside refs/notes/
 - t3301: use test_must_fail instead of !
 - t3301: fix confusing quoting in test for valid notes ref
 - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
 - notes: only clean up message file when editing
 - handle empty notes gracefully
 + git notes show: test empty notes
 + git-notes: fix printing of multi-line notes
 + notes: fix core.notesRef documentation
 + Add an expensive test for git-notes
 + Speed up git notes lookup
 + Add a script to edit/inspect notes
 + Introduce commit notes

Earlier part was merged to master and then reverted there. I probably should rebase this after 1.6.2 to keep my sanity.

* fc/config-editor (Tue Feb 17 02:54:54 2009 +0200) 9 commits
 . config: Cleanup editor action.
 . config: Codestyle cleanups.
 . config: Don't allow extra arguments for -e or -l.
 . config: Disallow multiple config file locations.
 . config: Disallow multiple variable types.
 . config: Use parseopt.
 . config: Reorganize get_color*.
 . config: Trivial rename in preparation for parseopt.
 - config: Add new option to open an editor.

The follow-up series does not pass the test suite, and evicted from 'pu'; the first one might be 'next' worthy, though.

* js/remote-set-head (Sat Feb 14 05:30:30 2009 -0500) 5 commits
 - builtin-remote: better handling of multiple remote HEADs
 - builtin-remote: add set-head subcommand
 - builtin-remote: teach show to display remote HEAD
 - builtin-remote: move duplicated cleanup code its own function
 - builtin-clone: move locate_head() to remote.c so it can be re-used
* jk/head-lookup (Sun Feb 15 01:18:18 2009 -0500) 5 commits
 - remote: use exact HEAD lookup if it is available
 - remote: refactor guess_remote_head
 - refactor find_refs_by_name to accept const list
 - add basic http clone/fetch tests
 - test scripts: refactor start_httpd helper

Builds on top of Jay Soffian's js/remote-set-head topic. How well do these two work in practice in the real world? Success stories?

---------------------------------------------------------------- [On Hold]

* 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
This is for 1.7.0.
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
 - git commit: pathspec without -i/-o implies -i semantics during a
   merge
 - builtin-commit: shorten eye-sore overlong lines
 - Add "partial commit" tests during a conflicted merge
This was only meant as a weatherballoon to help facilitate discussion.
* 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.  I do not need it in 1.6.2

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.

[Perhaps will discard]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 . diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 . git-am --forge: add Signed-off-by: line for the author
 . git-am: clean-up Signed-off-by: lines
 . stripspace: add --log-clean option to clean up signed-off-by:
   lines
 . stripspace: use parse_options()
 . Add "git am -s" test
 . git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
 . revision --simplify-merges: incremental simplification
 . revision --simplify-merges: prepare for incremental simplification
Jakub Narebski· Feb 17, 2009, 10:17 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> ----------------------------------------------------------------
> [New Topics]
> 
> * gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
>  - gitweb: fix wrong base URL when non-root DirectoryIndex
> 
> Should this go in 1.6.2-rc2?
Isn't it in master already?
Show 10 quoted lines
> 
> * tr/gcov (Sun Feb 15 23:25:45 2009 +0100) 8 commits
>  - Test git-patch-id
>  - Test rev-list --parents/--children
>  - Test log --decorate
>  - Test fsck a bit harder
>  - Test log --graph
>  - Test diff --dirstat functionality
>  - Test that diff can read from stdin
>  - Support coverage testing with GCC/gcov
Hmmmm... wouldn't it be nice to have more tests?
> 
> * jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
>  - git-add -i/-p: learn to unwrap C-quoted paths

It might be considered bugfix, but IIRC it is still cooking, so perhaps it wouldn't be absolutely ready for 1.6.2

Show 17 quoted lines
> 
> ----------------------------------------------------------------
> [Stalled and may need help and prodding to go forward]
> 
> * 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 gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

It would be nice to have for gitweb... especially if it is a merge commit that gets the blame (which I guess should happen only for 'evil merge' case).

Show 9 quoted lines
> 
> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
>  - Support fetching from foreign VCSes
>  - Add specification of git-vcs helpers
>  - Add "vcs" config option in remotes
> 
> The "spec" did not seem quite well cooked yet, but in the longer term I
> think something like this to allow interoperating with other SCMs as if
> the other end is a native git repository is a very worthy goal.

I wonder what are the limitations: I guess that importer has to be incremental (and probably store additional info, or at least cache it). IIRC the example was for Perforce; much more interesting would be to have example for Subversion, I guess.

Show 18 quoted lines
> 
> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
>  - 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
> 
> I think the code is much cleaner than the first round, but I am not
> convinced it is doing the right thing in the connectivity traverser.  
> Independent review sorely needed.
This is certainly something that it would be nice to have.
Show 8 quoted lines
> 
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>  - gitweb: Optional grouping of projects by category
>  - gitweb: Split git_project_list_body in two functions
>  - gitweb: Modularized git_get_project_description to be more generic
> 
> Design discussion between Jakub and Sebastien seems to have stalled, but
> Jakub seems to be taking this over.

The fact that discussion stalled is largely my fault as reviewer wanting for this series to do too much 'by the way' changes, and preparation for further changes.

I don't know when I would have time to actively work on this, but I have it in my repository, so it wouldn't vanish

  git://repo.or.cz/git/jnareb-git.git gitweb/category
  http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=refs/heads/gitweb/category
Show 11 quoted lines
> 
> * jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
>  - fsck: three levels of validation
>  - verify-pack: add --quick
>  - verify_pack(): allow a quicker verification for a pack with
>    version 2 idx
>  - pack-check.c: minor formatting fix to match coding style
> 
> J6t has a good point that if this had any value then medium level should
> replace the default.  I am tempted to actually dropping this as a failed
> experiment.
I recall that medium level wasn't that much faster, isn't it?
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Thomas Rast· Feb 17, 2009, 11:04 UTC · re: Jakub Narebski · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Jakub Narebski wrote:
Show 11 quoted lines
> > * tr/gcov (Sun Feb 15 23:25:45 2009 +0100) 8 commits
> >  - Test git-patch-id
> >  - Test rev-list --parents/--children
> >  - Test log --decorate
> >  - Test fsck a bit harder
> >  - Test log --graph
> >  - Test diff --dirstat functionality
> >  - Test that diff can read from stdin
> >  - Support coverage testing with GCC/gcov
> 
> Hmmmm... wouldn't it be nice to have more tests?

I was hoping the coverage patch would give people an incentive to write some ;-)

Seriously, the list is huge. Running the tests in my private next-and-then-some branch[*], summarizing by function counts and filtering for >2 untested functions shows:

      4 builtin-apply.c
      4 builtin-blame.c
      6 builtin-fetch-pack.c
      3 builtin-fsck.c
      6 builtin-log.c
      4 builtin-pack-objects.c
      4 builtin-rev-parse.c
      6 builtin-show-branch.c
      3 builtin-update-index.c
      4 builtin-upload-archive.c
      3 config.c
      7 connect.c
      8 date.c
      4 diffcore-order.c
      3 fsck.c
      8 help.c
      5 index-pack.c
      6 merge-file.c
      4 mktree.c
      4 object.c
      4 pager.c
      3 refs.c
      3 shell.c

plus some matches in HTTP, IMAP etc. code that I'll just ignore for now.

Some of it is fairly easy stuff; for example, rev-parse --{all,branches,tags,remotes} is completely untested according to the coverage report. I might add more tests as my time allows, but it is also limited.

[*] git://repo.or.cz/git/trast.git next
-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Johannes Schindelin· Feb 17, 2009, 14:12 UTC · re: Thomas Rast · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Hi,
On Tue, 17 Feb 2009, Thomas Rast wrote:
Show 17 quoted lines
> Jakub Narebski wrote:
> > > * tr/gcov (Sun Feb 15 23:25:45 2009 +0100) 8 commits
> > >  - Test git-patch-id
> > >  - Test rev-list --parents/--children
> > >  - Test log --decorate
> > >  - Test fsck a bit harder
> > >  - Test log --graph
> > >  - Test diff --dirstat functionality
> > >  - Test that diff can read from stdin
> > >  - Support coverage testing with GCC/gcov
> > 
> > Hmmmm... wouldn't it be nice to have more tests?
> 
> I was hoping the coverage patch would give people an incentive to
> write some ;-)
> 
> Seriously, the list is huge.

Well, judging from your patch-id example, I am somewhat doubtful: the meat of patch-id is exercized in the --cherry-pick patches.

IMHO the biggest shortcoming of gcov is that it cannot distinguish between functions that need thorough testing and functions which don't.

Don't get me wrong, I do not want to downplay the importance of tr/gcov, I'd like to have it in git.git, but just making tests for all the uncovered functions would just make a full test run longer, for dubitable value.

Ciao, Dscho

Junio C Hamano· Feb 17, 2009, 18:39 UTC · re: Jakub Narebski · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Jakub Narebski <jnareb@gmail.com> writes:
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> ----------------------------------------------------------------
>> [New Topics]
>> 
>> * gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
>>  - gitweb: fix wrong base URL when non-root DirectoryIndex
>> 
>> Should this go in 1.6.2-rc2?
>
> Isn't it in master already?
Yeah, I merged it, didn't I.  Sorry for the noise.
Show 5 quoted lines
>> * jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
>>  - git-add -i/-p: learn to unwrap C-quoted paths
>
> It might be considered bugfix, but IIRC it is still cooking,
> so perhaps it wouldn't be absolutely ready for 1.6.2

The informal policy I have during release freeze period is to fix only regressions. "We've lived with this bug for a long time, we can live one cycle longer and it is safer to do so than pushing out a fix that risks to break things unexpectedly".

Show 10 quoted lines
>> [Stalled and may need help and prodding to go forward]
>> 
>> * 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
>>
> It would be nice to have for gitweb... especially if it is a merge
> commit that gets the blame (which I guess should happen only for 'evil
> merge' case).

Will then move to "perhaps 'master' after 1.6.2" list, but the line number logic needs to be revisited, especially taking into account what was said in a recent discussion thread.

Show 13 quoted lines
>> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
>>  - Support fetching from foreign VCSes
>>  - Add specification of git-vcs helpers
>>  - Add "vcs" config option in remotes
>> 
>> The "spec" did not seem quite well cooked yet, but in the longer term I
>> think something like this to allow interoperating with other SCMs as if
>> the other end is a native git repository is a very worthy goal.
>
> I wonder what are the limitations: I guess that importer has to be
> incremental (and probably store additional info, or at least cache
> it).  IIRC the example was for Perforce; much more interesting would
> be to have example for Subversion, I guess.

We have a working git-svn. As a demonstration, a one that works with git would be more interesting.

Show 19 quoted lines
>> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
>>  - 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
>> 
>> I think the code is much cleaner than the first round, but I am not
>> convinced it is doing the right thing in the connectivity traverser.  
>> Independent review sorely needed.
>
> This is certainly something that it would be nice to have.

"Nice to have" we probably all know (otherwise it would not have been queued). Independent review is sorely needed.

Show 17 quoted lines
>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>>  - gitweb: Optional grouping of projects by category
>>  - gitweb: Split git_project_list_body in two functions
>>  - gitweb: Modularized git_get_project_description to be more generic
>> 
>> Design discussion between Jakub and Sebastien seems to have stalled, but
>> Jakub seems to be taking this over.
>
> The fact that discussion stalled is largely my fault as reviewer
> wanting for this series to do too much 'by the way' changes, and
> preparation for further changes.
>
> I don't know when I would have time to actively work on this, but I
> have it in my repository, so it wouldn't vanish
>
>   git://repo.or.cz/git/jnareb-git.git gitweb/category
>   http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=refs/heads/gitweb/category
Thanks.
Show 12 quoted lines
>> * jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
>>  - fsck: three levels of validation
>>  - verify-pack: add --quick
>>  - verify_pack(): allow a quicker verification for a pack with
>>    version 2 idx
>>  - pack-check.c: minor formatting fix to match coding style
>> 
>> J6t has a good point that if this had any value then medium level should
>> replace the default.  I am tempted to actually dropping this as a failed
>> experiment.
>
> I recall that medium level wasn't that much faster, isn't it?
Yes, that is why I am inclined to drop it.
Jakub Narebski· Feb 17, 2009, 23:29 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes: 
>> Junio C Hamano <gitster@pobox.com> writes:
Show 14 quoted lines
>>> [Stalled and may need help and prodding to go forward]
>>> 
>>> * 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
>>>
>> It would be nice to have for gitweb... especially if it is a merge
>> commit that gets the blame (which I guess should happen only for 'evil
>> merge' case).
> 
> Will then move to "perhaps 'master' after 1.6.2" list, but the line number
> logic needs to be revisited, especially taking into account what was said
> in a recent discussion thread.
Well, even without 'line number logic', i.e. having line number for
version of given line _before_ current version (which might be not
solvable anyway, only approximated), having parents from git-blame,
without need to run at least 'git cat-file --batch', would be nice
enhancement.  If merge is blamed, then we can offer user more than
one parent to choose from to go to...
 
Show 16 quoted lines
>>> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
>>>  - Support fetching from foreign VCSes
>>>  - Add specification of git-vcs helpers
>>>  - Add "vcs" config option in remotes
>>> 
>>> The "spec" did not seem quite well cooked yet, but in the longer term I
>>> think something like this to allow interoperating with other SCMs as if
>>> the other end is a native git repository is a very worthy goal.
>>
>> I wonder what are the limitations: I guess that importer has to be
>> incremental (and probably store additional info, or at least cache
>> it).  IIRC the example was for Perforce; much more interesting would
>> be to have example for Subversion, I guess.
> 
> We have a working git-svn.  As a demonstration, a one that works with git
> would be more interesting.
Hmmm... I wonder then how hard would be to reuse git-svn (which is not
fast-import importer) for foreign-scm feature...
 
Show 22 quoted lines
>>> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
>>>  - 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
>>> 
>>> I think the code is much cleaner than the first round, but I am not
>>> convinced it is doing the right thing in the connectivity traverser.  
>>> Independent review sorely needed.
>>
>> This is certainly something that it would be nice to have.
> 
> "Nice to have" we probably all know (otherwise it would not have been
> queued).  Independent review is sorely needed.

Perhaps I would take a look, then... Not that I know anything about this area of code ;-)

-- 
Jakub Narebski
Poland
Jeff King· Feb 17, 2009, 19:21 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

On Mon, Feb 16, 2009 at 11:57:36PM -0800, Junio C Hamano wrote:
Show 13 quoted lines
> * 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 gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

I never got a chance to look closely at this patch series; Jonas ended up implementing something in tig which does a diff-tree to guess where we want the view to go:

  http://repo.or.cz/w/tig.git?a=commitdiff;h=b6d0d41e01e4e435385db260cf34fd5d9069d782

It has been working pretty well for me in practice. I'm sure that blame could do it faster internally, but it really isn't performance critical, as it is triggered by user input.

So a blame implementation might help other callers, but I don't think there is much motivation from tig's point of view.

-Peff
Jeff King· Feb 17, 2009, 19:30 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

[oops, resend as I screwed up Jonas' address in the last one]
On Mon, Feb 16, 2009 at 11:57:36PM -0800, Junio C Hamano wrote:
Show 13 quoted lines
> * 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 gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

I never got a chance to look closely at this patch series; Jonas ended up implementing something in tig which does a diff-tree to guess where we want the view to go:

  http://repo.or.cz/w/tig.git?a=commitdiff;h=b6d0d41e01e4e435385db260cf34fd5d9069d782

It has been working pretty well for me in practice. I'm sure that blame could do it faster internally, but it really isn't performance critical, as it is triggered by user input.

So a blame implementation might help other callers, but I don't think there is much motivation from tig's point of view.

-Peff
Jonas Fonseca· Feb 17, 2009, 22:28 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Jeff King <peff@peff.net> wrote Tue, Feb 17, 2009:
Show 16 quoted lines
> On Mon, Feb 16, 2009 at 11:57:36PM -0800, Junio C Hamano wrote:
> > * 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 gives Porcelains (like gitweb) the information on the commit _before_
> > the one that the final blame is laid on, which should save them one
> > rev-parse to dig further.  The line number in the "previous" information
> > may need refining, and sanity checking code for reference counting may
> > need to be resurrected before this can move forward.
> > 
> > I thought recent tig discussion may blow new life into it, but is this
> > unneeded?  If so I'd rather revert it (or discard after 1.6.2).
> 
> I never got a chance to look closely at this patch series;

Sorry, me neither. Generally, I am all for pushing as much as possible into git, and was also happy to see a recent patch making it possible to launch an editor. Especially, since tig would then benefit if a better heuristic comes along. Unfortunately, I won't be able to offer to do what I think is a request for someone to polish it off.

> So a blame implementation might help other callers, but I don't think
> there is much motivation from tig's point of view.
Yeah, tig will be stuck with (falling back to) diff-tree anyway.
-- 
Jonas Fonseca
Johannes Schindelin· Feb 18, 2009, 12:05 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

Hi,
On Mon, 16 Feb 2009, Junio C Hamano wrote:
Show 17 quoted lines
> * js/notes (Sat Feb 14 21:23:25 2009 +0100) 13 commits
>  - notes: refuse to edit notes outside refs/notes/
>  - t3301: use test_must_fail instead of !
>  - t3301: fix confusing quoting in test for valid notes ref
>  - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
>  - notes: only clean up message file when editing
>  - handle empty notes gracefully
>  + git notes show: test empty notes
>  + git-notes: fix printing of multi-line notes
>  + notes: fix core.notesRef documentation
>  + Add an expensive test for git-notes
>  + Speed up git notes lookup
>  + Add a script to edit/inspect notes
>  + Introduce commit notes
> 
> Earlier part was merged to master and then reverted there.  I probably
> should rebase this after 1.6.2 to keep my sanity.
Yes, please.

Ciao, Dscho

← back to recent threads