Re: What's cooking in git.git (Oct 2013, #02; Mon, 14)
Am 15.10.2013 22:05, schrieb Jonathan Nieder: Jens Lehmann wrote: Am 15.10.2013 21:16, schrieb Jonathan Nieder: So I suspect this will fix more scripts than it breaks, though it may still break some. :/ Hmm, I'm really not sure if we should do this or not. What convinced me was Anders's observation that the current behavior can have very bad consequences if a script is passing untrusted input in multiple arguments to git submodule foreach. Ok, that makes sense. And maybe only change that on a major version bump where people should not be terribly surprised about such a change in behavior and are more likely to read release notes? Ok with me, but please don't make it 2.0. :) But we don't want to wait for 3.0, no? ;-) -- 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 (Oct 2013, #02; Mon, 14)
Jonathan Nieder jrnie...@gmail.com writes: What's cooking in git.git (Oct 2013, #02; Mon, 14) Tying up loose ends before the hand-off. I'll try: - slurping your integration branches, - teasing the topics apart out of your 'pu', - populating my rerere database to match your confict resolution, - reconstructing the Meta/Reintegrate insn for 'pu', and - rebuilding 'pu' to make sure the end result matches yours and then push the result out to the usual places listed at http://git-blame.blogspot.com/p/git-public-repositories.html I haven't had enough time to go through the new/updated patches in tree to look at them carefully (let alone peeking into patches that are not in 'pu'), but it appears to me that the list has been busy adding quality fixes and enhancements while I was away. Thanks. -- [Stalled] ... * mg/more-textconv (2013-05-10) 7 commits (merged to 'next' on 2013-10-14 at 8a12490) + grep: honor --textconv for the case rev:path + grep: allow to use textconv filters + t7008: demonstrate behavior of grep with textconv + cat-file: do not die on --textconv without textconv filters + show: honor --textconv for blobs + diff_opt: track whether flags have been set explicitly + t4030: demonstrate behavior of show with textconv Make git grep and git show pay attention to --textconv when dealing with blob objects. There was a question about how defaulting to 'git show --textconv' would interact with the git show HEAD:file.c file.c habit. $gmane/221833 I'll move this to the Cooking category (caught it by looking at the output of Meta/cook -w). [Cooking] * ak/submodule-foreach-quoting (2013-09-27) 1 commit (merged to 'next' on 2013-10-14 at d77c5f1) + submodule foreach: skip eval for more than one argument A behavior change, but a worthwhile one: git submodule foreach was treating its arguments as part of a single command to be concatenated and passed to a shell, making writing buggy scripts too easy. This patch preserves the old just pass it to the shell behavior when a single argument is passed to 'git submodule foreach' and moves to a new skip the shell and use the arguments passed unmolested behavior when more than one argument is passed. When scripts give 'echo' and '$path' (two args), does this change allow the 'echo' command to see the value of $path (coming from $sm_path), or just the not-useful-because-not-exported variable name '$path'? The old behavior (always concatenating and passing to the shell) was similar to the 'ssh' command, while the new behavior (switching on the number of arguments) is what 'xterm -e' does. May need more thought to make sure this change is advertised well so that scripts that used multiple arguments but added their own extra layer of quoting are not broken. I suspect no amount of thinking is enough to avoid fallout from this change. People will not read advertisement and will complain. * ew/keepalive (2013-10-14) 1 commit (merged to 'next' on 2013-10-14 at 24d786f) + http: enable keepalive on TCP sockets $gmane/236154 has a follow-up to do more magic with recent curl. Thanks for leaving a good note here. Will take a look at that follow-up in tomorrow's integration cycle. * jc/revision-range-unpeel (2013-09-20) 2 commits - (possible fixup) jc/revision-range-unpeel - peel only when necessary - revision: do not peel tags used in range notation git rev-list --objects ^v1.0^ v1.0 gave v1.0 tag itself in the output, but git rev-list --objects v1.0^..v1.0 did not. Need to decide either squashing the top fixup in, or dropping it and then merge to 'next'. Funny that you did not decide as the interim maintainer ;-) I'll squash these two, per $gmane/235339, and have it advance, perhaps in tomorrow's integration cycle. * jk/format-patch-from (2013-09-20) 1 commit (merged to 'next' on 2013-09-20 at 0506530) + format-patch: print in-body From only when needed format-patch --from=whom forgot to omit unnecessary in-body from line, i.e. when whom is the same as the real author. Will merge to 'master'. There seem to be many topics marked for 'master' but have been cooking in 'next' for very long. Will start moving them later this week (i.e. not today, not tomorrow). * jc/upload-pack-send-symref (2013-09-17) 7 commits - clone: test the new HEAD detection logic ... Will merge to 'next'. Likewise for the ones slated for 'next'. 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 (Oct 2013, #02; Mon, 14)
Junio C Hamano wrote: I'll try: - slurping your integration branches, - teasing the topics apart out of your 'pu', - populating my rerere database to match your confict resolution, - reconstructing the Meta/Reintegrate insn for 'pu', and - rebuilding 'pu' to make sure the end result matches yours and then push the result out to the usual places Sounds good. The teased-apart topics can also be found at https://github.com/jrn/git [...] This patch preserves the old just pass it to the shell behavior when a single argument is passed to 'git submodule foreach' and moves to a new skip the shell and use the arguments passed unmolested behavior when more than one argument is passed. When scripts give 'echo' and '$path' (two args), does this change allow the 'echo' command to see the value of $path (coming from $sm_path), or just the not-useful-because-not-exported variable name '$path'? The latter. A quick search (web search + codesearch.debian.net) reveals that most callers to submodule foreach either pass a script as a single quoted argument (e.g., http://stackoverflow.com/questions/8364738/bash-git-submodule-foreach: git submodule foreach '[ $path = Libraries/JSONKit ] \ branch=experimental \ || branch=master; git co $branch' or http://sources.debian.net/src/jquery/1.7.2+dfsg-3/Makefile?hl=131#L131: git submodule foreach git pull \$(git config remote.origin.url) ) or pass a one-off command with no arguments intended for the shell (e.g., http://sources.debian.net/src/libreoffice/1:4.1.1-1/g?hl=352#L352, http://sources.debian.net/src/swi-prolog/6.4.1-3/scripts/newversion?hl=81#L81): git submodule foreach git push $@ git submodule foreach git tag -s -f -F $tmp $gittag So I suspect this will fix more scripts than it breaks, though it may still break some. :/ It might make sense to warn when passed multiple arguments and some include shell metacharacters, since that's probably rare, too, except it's punishing people who use multiple arguments as a way to avoid quoting issues. Probably there's no replacement for just advertising the change loudly and seeking out scripts it could break. Thanks, Jonathan -- 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 (Oct 2013, #02; Mon, 14)
Am 15.10.2013 02:12, schrieb Jonathan Nieder: * jl/submodule-mv (2013-10-13) 1 commit - mv: Fix spurious warning when moving a file in presence of submodules Moving a regular file in a repository with a .gitmodules file was producing a warning 'Could not find section in .gitmodules where path=filename'. The test can use a little cleanup. Otherwise looks good. What cleanups do you have in mind? The new test is basically a copy from another one from the same file, so maybe some other tests there need some cleanups too? ;-) -- 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 (Oct 2013, #02; Mon, 14)
Am 15.10.2013 21:16, schrieb Jonathan Nieder: So I suspect this will fix more scripts than it breaks, though it may still break some. :/ Hmm, I'm really not sure if we should do this or not. It might make sense to warn when passed multiple arguments and some include shell metacharacters, since that's probably rare, too, except it's punishing people who use multiple arguments as a way to avoid quoting issues. Probably there's no replacement for just advertising the change loudly and seeking out scripts it could break. And maybe only change that on a major version bump where people should not be terribly surprised about such a change in behavior and are more likely to read release notes? I've thought about issuing a warning on certain quoting patterns too, but dismissed that for not helping much in the scripting case. E.g. at $dayjob we have foreach commands running in the shell execution for quite some jobs on our Jenkins server; nobody would see any warnings there until we'd have the reason to dig deeper int the logs because something breaks. -- 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 (Oct 2013, #02; Mon, 14)
Jens Lehmann wrote: Am 15.10.2013 21:16, schrieb Jonathan Nieder: So I suspect this will fix more scripts than it breaks, though it may still break some. :/ Hmm, I'm really not sure if we should do this or not. What convinced me was Anders's observation that the current behavior can have very bad consequences if a script is passing untrusted input in multiple arguments to git submodule foreach. I still haven't found any examples that pass input intended for the shell to git submodule foreach in multiple arguments. I suspect no one will notice, except that some scripts (like libreoffice's g) start to work better when passed arguments containing shell metacharacters. And maybe only change that on a major version bump where people should not be terribly surprised about such a change in behavior and are more likely to read release notes? Ok with me, but please don't make it 2.0. :) [...] E.g. at $dayjob we have foreach commands running in the shell execution for quite some jobs on our Jenkins server; nobody would see any warnings there until we'd have the reason to dig deeper int the logs because something breaks. Yes, I think that's typical. Warning to stderr probably wouldn't help. Thanks, Jonathan -- 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 (Oct 2013, #02; Mon, 14)
What's cooking in git.git (Oct 2013, #02; Mon, 14) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Tying up loose ends before the hand-off. The changes described here are in the integration branches at https://googlers.googlesource.com/jrn/git git://repo.or.cz/git/jrn.git git://gitorious.org/git/jrn.git https://github.com/jrn/git -- [Stalled] * tr/merge-recursive-index-only (2013-07-07) 3 commits - merge-recursive: -Xindex-only to leave worktree unchanged - merge-recursive: untangle double meaning of o-call_depth - merge-recursive: remove dead conditional in update_stages() Holding until there is a caller to learn from. * jc/ref-excludes (2013-09-03) 2 commits - document --exclude option - revision: introduce --exclude=glob to tame wildcards People often wished a way to tell git log --branches (and git log --remotes --not --branches) to exclude some local branches from the expansion of --branches (similarly for --tags, --all and --glob=pattern). Now they have one. Needs a matching change to rev-parse. * rv/send-email-cache-generated-mid (2013-08-21) 2 commits - git-send-email: Cache generated message-ids, use them when prompting - git-send-email: add optional 'choices' parameter to the ask sub * rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits - ### DONTMERGE: needs better explanation on what config they need - pack-refs.c: Add missing call to git_config() - show-ref.c: Add missing call to git_config() The changes themselves are probably good, but it is unclear what basic setting needs to be read for which exact operation. Waiting for clarification. $gmane/228294 * jh/shorten-refname (2013-05-07) 4 commits - t1514: refname shortening is done after dereferencing symbolic refs - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD - t1514: Add tests of shortening refnames in strict/loose mode When remotes/origin/HEAD is not a symbolic ref, rev-parse --abbrev-ref remotes/origin/HEAD ought to show origin, not origin/HEAD, which is fixed with this series (if it is a symbolic ref that points at remotes/origin/something, then it should show origin/something and it already does). Expecting a reroll, as an early part of a larger series. $gmane/225137 * mg/more-textconv (2013-05-10) 7 commits (merged to 'next' on 2013-10-14 at 8a12490) + grep: honor --textconv for the case rev:path + grep: allow to use textconv filters + t7008: demonstrate behavior of grep with textconv + cat-file: do not die on --textconv without textconv filters + show: honor --textconv for blobs + diff_opt: track whether flags have been set explicitly + t4030: demonstrate behavior of show with textconv Make git grep and git show pay attention to --textconv when dealing with blob objects. There was a question about how defaulting to 'git show --textconv' would interact with the git show HEAD:file.c file.c habit. $gmane/221833 * jc/format-patch (2013-04-22) 2 commits - format-patch: --inline-single - format-patch: rename no_inline field A new option to send a single patch to the standard output to be appended at the bottom of a message. I personally have no need for this, but it was easy enough to cobble together. Tests, docs and stripping out more MIMEy stuff are left as exercises to interested parties. * jk/gitweb-utf8 (2013-04-08) 4 commits - gitweb: Fix broken blob action parameters on blob/commitdiff pages - gitweb: Don't append ';js=(0|1)' to external links - gitweb: Make feed title valid utf8 - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch Various fixes to gitweb. Drew Northup volunteered to take a look into this. $gmane/226216 * jc/show-branch (2013-06-07) 5 commits - show-branch: use commit slab to represent bitflags of arbitrary width - show-branch.c: remove all_mask - show-branch.c: abstract out flags operation - show-branch.c: lift all_mask/all_revs to a global static - show-branch.c: update comment style Waiting for the final step to lift the hard-limit before sending it out. -- [Cooking] * ak/submodule-foreach-quoting (2013-09-27) 1 commit (merged to 'next' on 2013-10-14 at d77c5f1) + submodule foreach: skip eval for more than one argument A behavior change, but a worthwhile one: git submodule foreach was treating its arguments as part of a single command to be concatenated and passed to a shell, making writing buggy scripts too easy. This patch preserves the old just pass it to the shell behavior when a single argument is passed to 'git submodule foreach' and moves to a new skip the shell and use
Re: What's cooking in git.git (Oct 2013, #02; Mon, 14)
Jonathan Nieder wrote: What's cooking in git.git (Oct 2013, #02; Mon, 14) Could you have a look at the minor f-e-r enhancement I posted? [1] Thanks. [1]: http://thread.gmane.org/gmane.comp.version-control.git/235483 -- 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
