On August 11, 2019 8:39 PM, Junio C Hamano wrote:
> Jeff King writes:
>
> > IMHO scripting around "action" commands like checkout is less bad than
> > around "output" commands like log. The general action of "switch to
> > this branch" is unlikely to be changed much over the years (or via
> > con
Jeff King writes:
> IMHO scripting around "action" commands like checkout is less bad than
> around "output" commands like log. The general action of "switch to this
> branch" is unlikely to be changed much over the years (or via config),
> but the output of log, etc, is.
>
> There are no guarant
On Fri, Aug 09, 2019 at 11:05:34AM -0700, Phil Hord wrote:
> On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano wrote:
> >
> > Jeff King writes:
> >
> > > I don't know of any plans for checkout in particular, but I think the
> > > docs for restore/switch make it clear that it's way too early to star
On August 9, 2019 1:45 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > On 01 Aug 2019 13:05:12, Junio wrote:
> >> >> *snip*
> >
> > I think this got missed in the shuffle, but I am getting questions
> > about the topic from my own team that I cannot answer.
> >
> > I noticed that th
On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > I don't know of any plans for checkout in particular, but I think the
> > docs for restore/switch make it clear that it's way too early to start
> > scripting around them:
> >
> > $ git grep EXPERIMENTAL Documenta
Jeff King writes:
> I don't know of any plans for checkout in particular, but I think the
> docs for restore/switch make it clear that it's way too early to start
> scripting around them:
>
> $ git grep EXPERIMENTAL Documentation/
> Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL.
"Randall S. Becker" writes:
> On 01 Aug 2019 13:05:12, Junio wrote:
>> >> *snip*
>
> I think this got missed in the shuffle, but I am getting questions
> about the topic from my own team that I cannot answer.
>
> I noticed that the switch and restore commands are now available
> in 2.23.0 but are
On Fri, Aug 9, 2019 at 4:41 AM Jeff King wrote:
>
> On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:
>
> > The long form you give there is to be used in case the old email
> > address is not a unique key. See 'git help shortlog'.
> >
> > The problem we have at work is that one woman's ol
On August 9, 2019 12:29 PM, Jeff King wrote:
> On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:
>
> > On 01 Aug 2019 13:05:12, Junio wrote:
> > > >> *snip*
> >
> > I think this got missed in the shuffle, but I am getting questions about the
> topic from my own team that I cannot
On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:
> On 01 Aug 2019 13:05:12, Junio wrote:
> > >> *snip*
>
> I think this got missed in the shuffle, but I am getting questions about the
> topic from my own team that I cannot answer.
>
> I noticed that the switch and restore comm
On 01 Aug 2019 13:05:12, Junio wrote:
> >> *snip*
I think this got missed in the shuffle, but I am getting questions about the
topic from my own team that I cannot answer.
I noticed that the switch and restore commands are now available in 2.23.0 but
are not discussed in recent What's Cooking o
On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:
> The long form you give there is to be used in case the old email
> address is not a unique key. See 'git help shortlog'.
>
> The problem we have at work is that one woman's old email address
> includes her deadname, like . I will
> lea
Hi Ariadne,
On Thu, Aug 08, 2019 at 10:21:02PM -0500, Ariadne Conill wrote:
> Hello,
>
> On Thu, Aug 8, 2019 at 10:07 PM Phil Hord wrote:
> >
> > The issue of deadnaming aside, turning on log.mailmap by default is
> > the sensible thing to do given that other Git features already honor
> > it tha
Hello,
On Thu, Aug 8, 2019 at 10:07 PM Phil Hord wrote:
>
> The issue of deadnaming aside, turning on log.mailmap by default is
> the sensible thing to do given that other Git features already honor
> it that way. Having it ignored-by-default (but only sometimes) just
> adds confusion when a mai
The issue of deadnaming aside, turning on log.mailmap by default is
the sensible thing to do given that other Git features already honor
it that way. Having it ignored-by-default (but only sometimes) just
adds confusion when a mailmap is available.
> > > - The '.mailmap' provides a list of trans
Hello,
On Thu, Aug 8, 2019 at 9:07 PM Taylor Blau wrote:
>
> Hi Ariadne,
>
> Thank you for replying. I'm replying myself to the quoted hunks below,
> and I very much appreciate your input. I would like to note that I
> myself did not come up with these concerns alone, they were merely
> suggested
Hi Ariadne,
Thank you for replying. I'm replying myself to the quoted hunks below,
and I very much appreciate your input. I would like to note that I
myself did not come up with these concerns alone, they were merely
suggested to me by a coworker, and I found them concerning.
I am not myself tran
Hello,
On August 8, 2019 8:13:15 PM EDT, Taylor Blau wrote:
>Hi Junio,
>
>On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'nex
Hi Junio,
On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano 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'. The ones marked with '.' do not appear in any of
> the integrat
On Thu, Jul 25, 2019 at 5:19 PM Junio C Hamano wrote:
> [Stalled]
>
> * cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit
> - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana
>
> Compilation fix.
>
> Will be rerolled together with patches from the
> jk/no-system-incl
On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal
wrote:
> > In general, once submitted, avoid rebasing unless needed to integrate
> > with someone else's work and clean up conflicts.
>
> I have not checked but git/git:master is like 569 commits ahead of
> r1walz/git:master, there _might_ be conflicts
Hi Elijah
On Sat, 27 Jul 2019 13:40:13 -0700 Elijah Newren wrote:
>
> Let me attempt to answer on Junio's behalf...
:)
> [...]
> There are four, including Junio's commit he had to add in order to
> make the series merge with pu (a rename of your t3431 to the
> unoccupied t3433 slot). He label
Hi Rohit,
Let me attempt to answer on Junio's behalf...
On Sat, Jul 27, 2019 at 12:48 PM Rohit Ashiwal
wrote:
>
> Hi Junio
>
> On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:
> >
> > * ra/rebase-i-more-options (2019-07-23) 4 commits
> > - SQUASH???
>
> There are only 3 commits in this
Hi Junio
On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:
>
> [...]
> [New Topics]
>
> * bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit
> (merged to 'next' on 2019-07-23 at 8bd5a68618)
> + grep: print the pcre2_jit_on value
>
> BUG() message fix.
>
> The codepath may want to
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 25 Jul 2019, Junio C Hamano wrote:
>
>> The seventh batch is in; I've merged fix-up topics that has been in
>> 'master' for some time (i.e. up to the third batch of this cycle)
>> down to 'maint'.
>
> Would you terribly mind also merging `js/gcc
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> The seventh batch is in; I've merged fix-up topics that has been in
> 'master' for some time (i.e. up to the third batch of this cycle)
> down to 'maint'.
Would you terribly mind also merging `js/gcc-8-and-9` into `maint`?
Otherwise, the CI
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The seventh batch is in; I've merg
27 matches
Mail list logo
