Re: What's cooking in git.git (Mar 2014, #08; Mon, 31)
Heiko Voigt hvo...@hvoigt.net writes: On Mon, Mar 31, 2014 at 05:29:03PM -0700, Junio C Hamano wrote: * 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 this time. Waiting for a reroll. Since Ronald and Jens picked up this topic[1], I think you can discard my series. Thanks, will do. -- 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, #08; Mon, 31)
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: I haven't reverted the merge of that submodule update topic yet; I should do that soonish. ... Sigh... This is giving me a lot of headache. As 23d25e48 (submodule: explicit local branch creation in module_clone, 2014-01-26) has been in 'master' since fairly early during this cycle, a lot of topics that are not planned to be on the 'maint' branch has forked from the tip of 'master' and are now contaminated by that commit. I think I have a preparatory patch to correctly revert 00d4ff1a (Merge branch 'wt/doc-submodule-name-path-confusion-2', 2014-03-31) and 06c27689 (Merge branch 'wk/submodule-on-branch', 2014-02-27), and also a part of 384364b (Start preparing for Git 2.0, 2014-03-07), but I am not sure what to do with them ;-)) Why not just revert on master? When merging with the topic branches, the revert should then override the contamination. That was actually not the cumbersome part. I wanted to be very sure that the revert was correctly done, and one way I know to get an independent verification is to rebuild the master branch starting all the way back from the point before the problematic topic was merged to it. Some of the topics merged to 'master' after that point, however, were forked after that original problematic merge was made, so they needed to be rebuilt before I could do so. It is worth noting that this verification can also be done in a different way. You can start at 06c27689^1, and cherry-pick -m1 (or cherry-pick for non-merge commits that update the release notes) the commits in git rev-list --reverse --first-parent 06c27689..master on top of it. That should result in the same tree object as a correct revert on top of 'master' would have. Because cherry-pick -m1 loses the other parents, the resulting history does not reflect the reality, but I am not doing this in order to replace the history of the 'master' with the result but only to make sure that the final tree matches what would have happened if the topic were not merged to 'master', so it is sufficient for the purpose of this exercise. Hope it clarifies. -- 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, #08; Mon, 31)
On Mon, Mar 31, 2014 at 05:29:03PM -0700, Junio C Hamano wrote: * 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 this time. Waiting for a reroll. Since Ronald and Jens picked up this topic[1], I think you can discard my series. Cheers Heiko [1] http://thread.gmane.org/gmane.comp.version-control.git/245341 -- 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, #08; Mon, 31)
Duy Nguyen pclo...@gmail.com writes: The basic support is there. Some bells and whistles (e.g. listing checkouts) are not, but we can add them when we see the needs. Eric and Torsten helped review but no, there hasn't much discussion about it, which may be because it's already perfect, or people are not interested. ;-) Unfortunately, this multiple checkout thing conflicts with how I use emacs (--daemon) so I'm not one of its heavy users either. I only occastionally make new, short-lived checkouts to test things. FWIW, I do keep a permanent multi-checkout and I sometimes make edits, but it is mostly for building other branches while I work on something else. When I edit working-tree files there, I do let emacsclient talk to the emacs I have files open in the primary working tree, though, so I am not sure what your issues are with emacs (--daemon). -- 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, #08; Mon, 31)
Junio C Hamano gits...@pobox.com writes: I haven't reverted the merge of that submodule update topic yet; I should do that soonish. ... Sigh... This is giving me a lot of headache. As 23d25e48 (submodule: explicit local branch creation in module_clone, 2014-01-26) has been in 'master' since fairly early during this cycle, a lot of topics that are not planned to be on the 'maint' branch has forked from the tip of 'master' and are now contaminated by that commit. I think I have a preparatory patch to correctly revert 00d4ff1a (Merge branch 'wt/doc-submodule-name-path-confusion-2', 2014-03-31) and 06c27689 (Merge branch 'wk/submodule-on-branch', 2014-02-27), and also a part of 384364b (Start preparing for Git 2.0, 2014-03-07), but I am not sure what to do with them ;-)) Anyhow... -- 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, #08; Mon, 31)
On Wed, Apr 2, 2014 at 2:17 AM, Junio C Hamano gits...@pobox.com wrote: Unfortunately, this multiple checkout thing conflicts with how I use emacs (--daemon) so I'm not one of its heavy users either. I only occastionally make new, short-lived checkouts to test things. FWIW, I do keep a permanent multi-checkout and I sometimes make edits, but it is mostly for building other branches while I work on something else. When I edit working-tree files there, I do let emacsclient talk to the emacs I have files open in the primary working tree, though, so I am not sure what your issues are with emacs (--daemon). The --daemon part is probably not worth mentioning because I always have one emacs window open. The problem is switch-buffer based on file name can be confusing (git.c and git.c2, which belongs to which checkout?). I ended up modifying files in the wrong checkout all the time. -- 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
Re: What's cooking in git.git (Mar 2014, #08; Mon, 31)
Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: I haven't reverted the merge of that submodule update topic yet; I should do that soonish. ... Sigh... This is giving me a lot of headache. As 23d25e48 (submodule: explicit local branch creation in module_clone, 2014-01-26) has been in 'master' since fairly early during this cycle, a lot of topics that are not planned to be on the 'maint' branch has forked from the tip of 'master' and are now contaminated by that commit. I think I have a preparatory patch to correctly revert 00d4ff1a (Merge branch 'wt/doc-submodule-name-path-confusion-2', 2014-03-31) and 06c27689 (Merge branch 'wk/submodule-on-branch', 2014-02-27), and also a part of 384364b (Start preparing for Git 2.0, 2014-03-07), but I am not sure what to do with them ;-)) Why not just revert on master? When merging with the topic branches, the revert should then override the contamination. It makes some sense then to rewrite the submodule update topic branch so that when it gets reintroduced, its commits are not negated by the branch revert on master. Sounds like a stock case out of the using Git with topic branches book, so what am I missing? -- David Kastrup -- 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, #08; Mon, 31)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. More topics merged to 'master', some of which are fallouts from GSoC microprojects, some are updates to docs. C/C++ funcname pattern update is now in. I haven't reverted the merge of that submodule update topic yet; I should do that soonish. 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] * an/branch-config-message (2014-03-24) 1 commit (merged to 'next' on 2014-03-26 at 26f9741) + branch.c: install_branch_config: simplify if chain * ca/doc-config-third-party (2014-03-21) 1 commit (merged to 'next' on 2014-03-25 at 731e011) + config.txt: third-party tools may and do use their own variables * dp/makefile-charset-lib-doc (2014-03-23) 1 commit (merged to 'next' on 2014-03-25 at b32e3ad) + Makefile: describe CHARSET_LIB better * dt/tests-with-env-not-subshell (2014-03-19) 1 commit (merged to 'next' on 2014-03-25 at 19fe25f) + tests: use env to run commands with temporary env-var settings (this branch is used by jk/tests-cleanup.) * dw/doc-status-no-longer-shows-pound-prefix (2014-03-21) 1 commit (merged to 'next' on 2014-03-25 at 2683eb6) + doc: status, remove leftover statement about '#' prefix * hs/simplify-bit-setting-in-fsck-tree (2014-03-20) 1 commit (merged to 'next' on 2014-03-25 at 08efd68) + fsck: use bitwise-or assignment operator to set flag * ib/rev-parse-parseopt-argh (2014-03-23) 2 commits (merged to 'next' on 2014-03-25 at d9083ed) + t1502: protect runs of SPs used in the indentation + rev-parse --parseopt: option argument name hints (this branch is used by jc/rev-parse-argh-dashed-multi-words.) Teaches the rev-parse --parseopt mechanism used by scripted Porcelains to parse command line options and give help text how to supply argv-help (the placeholder string for an option parameter, e.g. key-id in --gpg-sign=key-id). * jk/tests-cleanup (2014-03-21) 12 commits (merged to 'next' on 2014-03-26 at 4a72b49) + t0001: drop subshells just for cd + t0001: drop useless subshells + t0001: use test_must_fail + t0001: use test_config_global + t0001: use test_path_is_* + t0001: make symlink reinit test more careful + t: prefer git config --file to GIT_CONFIG + t: prefer git config --file to GIT_CONFIG with test_must_fail + t: stop using GIT_CONFIG to cross repo boundaries + t: drop useless sane_unset GIT_* calls + t/test-lib: drop redundant unset of GIT_CONFIG + t/Makefile: stop setting GIT_CONFIG (this branch uses dt/tests-with-env-not-subshell.) * js/userdiff-cc (2014-03-21) 10 commits (merged to 'next' on 2014-03-25 at 8c0e585) + userdiff: have 'cpp' hunk header pattern catch more C++ anchor points + t4018: test cases showing that the cpp pattern misses many anchor points + t4018: test cases for the built-in cpp pattern + t4018: reduce test files for pattern compilation tests + t4018: convert custom pattern test to the new infrastructure + t4018: convert java pattern test to the new infrastructure + t4018: convert perl pattern tests to the new infrastructure + t4018: an infrastructure to test hunk headers + userdiff: support unsigned and long long suffixes of integer constants + userdiff: support C++ -* and .* operators in the word regexp Improves the pattern to match the hunk-header for C/C++. * mm/status-porcelain-format-i18n-fix (2014-03-26) 1 commit (merged to 'next' on 2014-03-26 at 41680fc) + status: disable translation when --porcelain is used * mr/msvc-link-with-lcurl (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at 3281dab) + MSVC: allow linking with the cURL library * wt/doc-submodule-name-path-confusion-1 (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at 225f241) + doc: submodule.* config are keyed by submodule names * wt/doc-submodule-name-path-confusion-2 (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at ec5bcf3) + doc: submodule.*.branch config is keyed by name -- [New Topics] * cb/aix (2014-03-31) 2 commits - tests: don't rely on strerror text when testing rmdir failure - dir.c: make git_fnmatch() not inline Will merge to 'next'. * jc/fix-diff-no-index-diff-opt-parse (2014-03-31) 1 commit - diff-no-index: correctly diagnose error return from diff_opt_parse() diff --no-index -Mq a b fell into an infinite loop. Will merge to 'next'. * mr/opt-set-ptr (2014-03-31) 3 commits - parse-options: remove unused OPT_SET_PTR - parse-options: add cast to correct pointer type to OPT_SET_PTR - MSVC: fix t0040-parse-options crash OPT_SET_PTR() implementation was broken on IL32P64 platforms. We may just want directly to go to the endgame of removing OPT_SET_PTR macro, which nobody
Re: What's cooking in git.git (Mar 2014, #08; Mon, 31)
On Tue, Apr 1, 2014 at 7:29 AM, Junio C Hamano gits...@pobox.com wrote: * nd/multiple-work-trees (2014-03-25) 28 commits - count-objects: report unused files in $GIT_DIR/repos/... - gc: support prune --repos - gc: style change -- no SP before closing bracket - prune: strategies for linked checkouts - checkout: detach if the branch is already checked out elsewhere - checkout: clean up half-prepared directories in --to mode - checkout: support checking out into a new working directory - use new wrapper write_file() for simple file writing - wrapper.c: wrapper to open a file, fprintf then close - setup.c: support multi-checkout repo setup - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() - setup.c: convert check_repository_format_gently to use strbuf - setup.c: detect $GIT_COMMON_DIR in is_git_directory() - setup.c: convert is_git_directory() to use strbuf - git-stash: avoid hardcoding $GIT_DIR/logs/ - *.sh: avoid hardcoding $GIT_DIR/hooks/... - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects - $GIT_COMMON_DIR: a new environment variable - commit: use SEQ_DIR instead of hardcoding sequencer - fast-import: use git_path() for accessing .git dir instead of get_git_dir() - reflog: avoid constructing .lock path with git_path - *.sh: respect $GIT_INDEX_FILE - git_path(): be aware of file relocation in $GIT_DIR - path.c: group git_path(), git_pathdup() and strbuf_git_path() together - path.c: rename vsnpath() to do_git_path() - git_snpath(): retire and replace with strbuf_git_path() - path.c: make get_pathname() call sites return const char * - path.c: make get_pathname() return strbuf instead of static buffer A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. What is the doneness of this thing? I remember reading it through once and sent review comments on earlier parts, but have there been a lot of discussions on this topic? The basic support is there. Some bells and whistles (e.g. listing checkouts) are not, but we can add them when we see the needs. Eric and Torsten helped review but no, there hasn't much discussion about it, which may be because it's already perfect, or people are not interested. Unfortunately, this multiple checkout thing conflicts with how I use emacs (--daemon) so I'm not one of its heavy users either. I only occastionally make new, short-lived checkouts to test things. -- 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
