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