Re: What's cooking in git.git (Mar 2014, #02; Tue, 11)

2014-03-12 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes:

 On Wed, Mar 12, 2014 at 5:12 AM, Junio C Hamano gits...@pobox.com wrote:
 * nd/log-show-linear-break (2014-02-10) 1 commit
  - log: add --show-linear-break to help see non-linear history

  Attempts to show where a single-strand-of-pearls break in git log
  output.

  Will merge to 'next'.

 Hold this one. I haven't found time to check again if any rev-list
 combincation may break it. The option name is coule use some
 improvement too.

OK.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Mar 2014, #02; Tue, 11)

2014-03-12 Thread Jeff King
On Tue, Mar 11, 2014 at 03:12:11PM -0700, Junio C Hamano wrote:

 * jk/warn-on-object-refname-ambiguity (2014-01-09) 6 commits
  - get_sha1: drop object/refname ambiguity flag
  - get_sha1: speed up ambiguous 40-hex test
  - FIXUP: teach DO_FOR_EACH_NO_RECURSE to prime_ref_dir()
  - refs: teach for_each_ref a flag to avoid recursion
  - cat-file: fix a minor memory leak in batch_objects
  - cat-file: refactor error handling of batch_objects
 
  Expecting a reroll.

I finally got a chance to return to this one. Michael had some good
comments on the refactoring that was going on in the middle patches. He
ended with:

  Yes.  Still, the code is really piling up for this one warning for the
  contrived eventuality that somebody wants to pass SHA-1s and branch
  names together in a single cat-file invocation *and* wants to pass
  lots of inputs at once and so is worried about performance *and* has
  reference names that look like SHA-1s.  Otherwise we could just leave
  the warning disabled in this case, as now.  Or we could add a new
  --hashes-only option that tells cat-file to treat all of its
  arguments/inputs as SHA-1s; such an option would permit an even faster
  code path for bulk callers.

Having looked at it again, I really think it is not worth pursuing. The
end goal is not that interesting, there is a lot of code introduced, and
a reasonable chance of accidentally introducing regressions and/or
making the code less maintainable.  Keeping the existing code (which
just disables the check for cat-file) is probably the sanest course of
action. We can do a similar thing for rev-list --stdin if we want, or
we can wait until somebody complains.

The bottom two patches are reasonable cleanups we should keep, though
(and the rest can just be discarded).

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What's cooking in git.git (Mar 2014, #02; Tue, 11)

2014-03-12 Thread Junio C Hamano
Jeff King p...@peff.net writes:

 On Tue, Mar 11, 2014 at 03:12:11PM -0700, Junio C Hamano wrote:

 * jk/warn-on-object-refname-ambiguity (2014-01-09) 6 commits
  - get_sha1: drop object/refname ambiguity flag
  - get_sha1: speed up ambiguous 40-hex test
  - FIXUP: teach DO_FOR_EACH_NO_RECURSE to prime_ref_dir()
  - refs: teach for_each_ref a flag to avoid recursion
  - cat-file: fix a minor memory leak in batch_objects
  - cat-file: refactor error handling of batch_objects
 
  Expecting a reroll.

 I finally got a chance to return to this one. Michael had some good
 comments on the refactoring that was going on in the middle patches. He
 ended with:

   Yes.  Still, the code is really piling up for this one warning for the
   contrived eventuality that somebody wants to pass SHA-1s and branch
   names together in a single cat-file invocation *and* wants to pass
   lots of inputs at once and so is worried about performance *and* has
   reference names that look like SHA-1s.  Otherwise we could just leave
   the warning disabled in this case, as now.  Or we could add a new
   --hashes-only option that tells cat-file to treat all of its
   arguments/inputs as SHA-1s; such an option would permit an even faster
   code path for bulk callers.

 Having looked at it again, I really think it is not worth pursuing. The
 end goal is not that interesting, there is a lot of code introduced, and
 a reasonable chance of accidentally introducing regressions and/or
 making the code less maintainable.  Keeping the existing code (which
 just disables the check for cat-file) is probably the sanest course of
 action. We can do a similar thing for rev-list --stdin if we want, or
 we can wait until somebody complains.

 The bottom two patches are reasonable cleanups we should keep, though
 (and the rest can just be discarded).

Fine, let's do that.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


What's cooking in git.git (Mar 2014, #02; Tue, 11)

2014-03-11 Thread Junio C Hamano
Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

Topics that have been cooking in 'next' for 2.0 have been merged to
'master', which means we are committed to make the next one a big
release.  Kind of scary, isn't it?

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to master]

* cc/starts-n-ends-with-endgame (2013-12-05) 1 commit
  (merged to 'next' on 2014-02-25 at 473e143)
 + strbuf: remove prefixcmp() and suffixcmp()

 Originally merged to 'next' on 2014-01-07

 Endgame for the cc/starts-n-ends-with topic; this needs to be
 evil-merged with other topics that introduce new uses of
 prefix/suffix-cmp functions.


* gj/push-more-verbose-advice (2013-11-13) 1 commit
  (merged to 'next' on 2014-02-25 at 1cd10b0)
 + push: switch default from matching to simple

 Originally merged to 'next' on 2013-11-21

 Explain 'simple' and 'matching' in git push advice message; the
 topmost patch is a rebase of jc/push-2.0-default-to-simple on top
 of it.


* jc/add-2.0-ignore-removal (2013-04-22) 1 commit
  (merged to 'next' on 2014-02-25 at a0d018a)
 + git add pathspec... defaults to -A

 Originally merged to 'next' on 2013-12-06

 Updated endgame for git add pathspec that defaults to --all
 aka --no-ignore-removal.


* jc/core-checkstat-2.0 (2013-05-06) 1 commit
  (merged to 'next' on 2014-02-25 at 62f6aeb)
 + core.statinfo: remove as promised in Git 2.0

 Originally merged to 'next' on 2013-12-06


* jc/hold-diff-remove-q-synonym-for-no-deletion (2013-07-19) 1 commit
  (merged to 'next' on 2014-02-25 at ccfff88)
 + diff: remove diff-files -q in a version of Git in a distant future

 Originally merged to 'next' on 2013-12-06

 Remove deprecated -q option git diff-files.


* jc/push-2.0-default-to-simple (2013-06-18) 1 commit
  (merged to 'next' on 2014-02-25 at 1f0e178)
 + push: switch default from matching to simple

 Originally merged to 'next' on 2013-12-06


* jk/run-network-tests-by-default (2014-02-14) 1 commit
  (merged to 'next' on 2014-02-25 at 62a8ad0)
 + tests: turn on network daemon tests by default

 Originally merged to 'next' on 2014-02-20

 Teach make test to run networking tests when possible by default.


* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit
  (merged to 'next' on 2014-02-25 at 9e5c0d2)
 + git add: -u/-A now affects the entire working tree

 Originally merged to 'next' on 2013-12-06


* ks/combine-diff (2014-02-24) 6 commits
  (merged to 'next' on 2014-02-25 at 69e5a87)
 + tests: add checking that combine-diff emits only correct paths
 + combine-diff: simplify intersect_paths() further
 + combine-diff: combine_diff_path.len is not needed anymore
 + combine-diff: optimize combine_diff_path sets intersection
 + diff test: add tests for combine-diff with orderfile
 + diffcore-order: export generic ordering interface
 (this branch is used by ks/tree-diff-nway.)

 Originally merged to 'next' on 2014-02-20

 Teach combine-diff to honour the path-output-order imposed by
 diffcore-order, and optimize how matching paths are found in
 the N-way diffs made with parents.


* nd/daemonize-gc (2014-02-10) 2 commits
  (merged to 'next' on 2014-02-25 at f592335)
 + gc: config option for running --auto in background
 + daemon: move daemonize() to libgit.a

 Originally merged to 'next' on 2014-02-20

 Allow running gc --auto in the background.

--
[New Topics]

* jk/detect-push-typo-early (2014-03-05) 3 commits
 - push: detect local refspec errors early
 - match_explicit_lhs: allow a verify only mode
 - match_explicit: hoist refspec lhs checks into their own function

 Catch git push $there no-such-branch early.

 Will merge to 'next'.


* jk/diff-funcname-cpp-regex (2014-03-05) 1 commit
 - diff: simplify cpp funcname regex

 Has the discussion settled on this?


* jk/doc-deprecate-grafts (2014-03-05) 1 commit
 - docs: mark info/grafts as outdated

 Will merge to 'next'.


* rm/strchrnul-not-strlen (2014-03-10) 1 commit
 - use strchrnul() in place of strchr() and strlen()

 Will merge to 'next'.


* sh/use-hashcpy (2014-03-06) 1 commit
 - Use hashcpy() when copying object names

 Will merge to 'next'.


* jc/no-need-for-env-in-sh-scripts (2014-03-06) 1 commit
 - *.sh: drop useless use of env

 Will merge to 'next'.


* jc/tag-contains-with (2014-03-07) 1 commit
 - tag: grok --with as synonym to --contains

 Will merge to 'next'.


* bp/commit-p-editor (2014-03-11) 8 commits
 - run-command: mark run_hook_with_custom_index as deprecated
 - merge hook tests: fix and update tests
 - merge: fix GIT_EDITOR override for commit hook
 - commit: fix patch hunk editing with commit -p -m
 - SQUASH???
 - test patch hunk editing with commit -p -m
 - merge hook tests: use 'test_must_fail' 

Re: What's cooking in git.git (Mar 2014, #02; Tue, 11)

2014-03-11 Thread Duy Nguyen
On Wed, Mar 12, 2014 at 5:12 AM, Junio C Hamano gits...@pobox.com wrote:
 * nd/log-show-linear-break (2014-02-10) 1 commit
  - log: add --show-linear-break to help see non-linear history

  Attempts to show where a single-strand-of-pearls break in git log
  output.

  Will merge to 'next'.

Hold this one. I haven't found time to check again if any rev-list
combincation may break it. The option name is coule use some
improvement too.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html