Re: What's cooking in git.git (Dec 2013, #05; Thu, 26)

2014-01-02 Thread Junio C Hamano
Eric Sunshine sunsh...@sunshineco.com writes:

 On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:

 On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
 [New Topics]

 Would $gmane/239575 [1] be of interest for New Topics?

 [1]: http://article.gmane.org/gmane.comp.version-control.git/239575/

 Actually I was planning to scoop it up directly to master but forgot
 to do so.

 Make sense.

 Running git diff maint pu -- name-hash.c shows that we have added
 a comment that mentions index_name_exists---that needs to be
 adjusted, too, by the way.

 Oops, yes, I had noticed that too when testing atop 'pu' but then
 forgot about it when preparing the patch for submission on 'master'.

 I'm not sure how to move forward with this now that kb/fast-hashmap,
 with which it has a textual conflict, has graduated to 'next'. Should
 this become a two-patch series with one for scooping directly to
 'master' and one for 'next' to sit atop kb/fast-hashmap? (But how will
 the textual conflict be handled?)

I have a feeling that a small unused helper function is not a huge
breakage that needs to be immediately fixed, so a single patch as a
clean-up on top of whatever is cooking on 'next' should be the best
approach, I would think.
--
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 (Dec 2013, #05; Thu, 26)

2014-01-02 Thread Eric Sunshine
On Thu, Jan 2, 2014 at 4:11 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:

 On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:

 On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
 [New Topics]

 Would $gmane/239575 [1] be of interest for New Topics?

 [1]: http://article.gmane.org/gmane.comp.version-control.git/239575/

 Actually I was planning to scoop it up directly to master but forgot
 to do so.

 Make sense.

 Running git diff maint pu -- name-hash.c shows that we have added
 a comment that mentions index_name_exists---that needs to be
 adjusted, too, by the way.

 Oops, yes, I had noticed that too when testing atop 'pu' but then
 forgot about it when preparing the patch for submission on 'master'.

 I'm not sure how to move forward with this now that kb/fast-hashmap,
 with which it has a textual conflict, has graduated to 'next'. Should
 this become a two-patch series with one for scooping directly to
 'master' and one for 'next' to sit atop kb/fast-hashmap? (But how will
 the textual conflict be handled?)

 I have a feeling that a small unused helper function is not a huge
 breakage that needs to be immediately fixed, so a single patch as a
 clean-up on top of whatever is cooking on 'next' should be the best
 approach, I would think.

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


Re: What's cooking in git.git (Dec 2013, #05; Thu, 26)

2013-12-27 Thread Eric Sunshine
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
 Here are the topics that have been cooking.  Commits prefixed with
 '-' are only in 'pu' (proposed updates) while commits prefixed with
 '+' are in 'next'.

 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

 --
 [New Topics]

Would $gmane/239575 [1] be of interest for New Topics?

[1]: http://article.gmane.org/gmane.comp.version-control.git/239575/
--
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 (Dec 2013, #05; Thu, 26)

2013-12-27 Thread Junio C Hamano
Eric Sunshine sunsh...@sunshineco.com writes:

 On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
 Here are the topics that have been cooking.  Commits prefixed with
 '-' are only in 'pu' (proposed updates) while commits prefixed with
 '+' are in 'next'.

 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

 --
 [New Topics]

 Would $gmane/239575 [1] be of interest for New Topics?

 [1]: http://article.gmane.org/gmane.comp.version-control.git/239575/

Actually I was planning to scoop it up directly to master but forgot
to do so.

Running git diff maint pu -- name-hash.c shows that we have added
a comment that mentions index_name_exists---that needs to be
adjusted, too, by the way.

--
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 (Dec 2013, #05; Thu, 26)

2013-12-26 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'.

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

--
[New Topics]

* bc/log-decoration (2013-12-20) 1 commit
 - log: properly handle decorations with chained tags

 git log --decorate did not handle a tag pointed by another tag
 nicely.

 Will merge to 'next'.


* jh/rlimit-nofile-fallback (2013-12-18) 1 commit
 - get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure

 When we figure out how many file descriptors to allocate for
 keeping packfiles open, a system with non-working getrlimit() could
 cause us to die(), but because we make this call only to get a
 rough estimate of how many is available and we do not even attempt
 to use up all file descriptors available ourselves, it is nicer to
 fall back to a reasonable low value rather than dying.

 Will merge to 'next'.


* rt/bfg-ad-in-filter-branch-doc (2013-12-18) 1 commit
 - docs: add filter-branch notes on The BFG

 Will merge to 'next'.


* sb/diff-orderfile-config (2013-12-18) 3 commits
 - diff: add diff.orderfile configuration variable
 - diff: let git diff -O read orderfile from any file and fail properly
 - t4056: add new tests for git diff -O

 Allow git diff -Ofile to be configured with a new configuration
 variable.

 Will merge to 'next'.


* jc/graph-post-root-gap (2013-12-20) 1 commit
 - graph: give an extra gap after showing root commit

 This was primarily a RFH ($gmane/239580).


* nd/daemon-informative-errors-typofix (2013-12-20) 1 commit
 - daemon: be strict at parsing parameters --[no-]informative-errors

 Will merge to 'next'.


* tm/fetch-prune (2013-12-20) 2 commits
 - fetch --prune: run prune before fetching
 - fetch --prune: always print header url

 Fetching 'frotz' branch with git fetch, while having
 'frotz/nitfol' remote-tracking branch from an earlier fetch, would
 error out, primarily because the command has not been told to
 remove anything on our side. In such a case, git fetch --prune
 can be used to remove 'frotz/nitfol' to make room to fetch and
 store 'frotz' remote-tracking branch.

 Will merge to 'next'.


* jk/oi-delta-base (2013-12-26) 2 commits
 - cat-file: provide %(deltabase) batch format
 - sha1_object_info_extended: provide delta base sha1s

 Teach cat-file --batch to show delta-base object name for a
 packed object that is represented as a delta.

 Will merge to 'next'.


* jk/sha1write-void (2013-12-26) 1 commit
 - do not pretend sha1write returns errors

 Code clean-up.

 Will merge to 'next'.


* jl/submodule-recursive-checkout (2013-12-26) 5 commits
 - Teach checkout to recursively checkout submodules
 - submodule: teach unpack_trees() to update submodules
 - submodule: teach unpack_trees() to repopulate submodules
 - submodule: teach unpack_trees() to remove submodule contents
 - submodule: prepare for recursive checkout of submodules


* mh/safe-create-leading-directories (2013-12-26) 5 commits
 - rename_ref(): fix a mkdir()/rmdir() race
 - safe_create_leading_directories(): fix a mkdir/rmdir race
 - safe_create_leading_directories(): add slash pointer
 - safe_create_leading_directories(): reduce scope of local variable
 - safe_create_leading_directories(): modernize format of if chaining

 Code clean-up and protection against concurrent write access to the
 ref namespace.

 Will merge to 'next'.


* nd/add-empty-fix (2013-12-26) 1 commit
 - add: don't complain when adding empty project root

 git add -A (no other arguments) in a totally empty working tree
 used to emit an error.

 Will merge to 'next'.


* nd/commit-tree-constness (2013-12-26) 1 commit
 - commit.c: make tree a const pointer in commit_tree*()

 Code clean-up.

 Will merge to 'next'.

--
[Stalled]

* mo/subtree-split-updates (2013-12-10) 3 commits
 - subtree: add --edit option
 - subtree: allow --squash and --message with push
 - subtree: support split --rejoin --squash

 Comments?


* hv/submodule-ignore-fix (2013-12-06) 4 commits
 - disable complete ignorance of submodules for index - HEAD diff
 - always show committed submodules in summary after commit
 - teach add -f option for ignored submodules
 - fix 'git add' to skip submodules configured as ignored

 Teach git add to be consistent with git status when changes to
 submodules are set to be ignored, to avoid surprises after checking
 with git status to see there isn't any change to be further added
 and then see that git add . adds changes to them.

 I think a reroll is coming, so this may need to be replaced, but I
 needed some practice with heavy conflict resolution.  It conflicts
 with two changes to git add that have been scheduled for Git 2.0
 quite badly, and I think I got the resolution right