From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2013, #02; Mon, 14)
Date: Tue, 15 Oct 2013 11:32:12 -0700 [thread overview]
Message-ID: <xmqqiowye66r.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20131015001231.GA9464@google.com> (Jonathan Nieder's message of "Mon, 14 Oct 2013 17:12:31 -0700")
Jonathan Nieder <jrnieder@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.
next prev parent reply other threads:[~2013-10-15 18:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 18:45 What's cooking in git.git (Oct 2013, #01; Mon, 14) Jonathan Nieder
2013-10-15 0:12 ` What's cooking in git.git (Oct 2013, #02; " Jonathan Nieder
2013-10-15 5:05 ` Ramkumar Ramachandra
2013-10-15 18:32 ` Junio C Hamano [this message]
2013-10-15 19:16 ` Jonathan Nieder
2013-10-15 19:42 ` Jens Lehmann
2013-10-15 20:05 ` Jonathan Nieder
2013-10-16 17:53 ` Jens Lehmann
2013-10-15 19:45 ` Jens Lehmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqiowye66r.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.