Jeff King writes:
> Hmm, I see the early parts of this graduated to 'next'. I'm not sure
> everything there is completely correct, though. E.g. I'm not sure of the
> reasoning in df75281e78 (ewah/bitmap: always allocate 2 more words,
> 2019-09-13).
> ...
> I'm sorry for being so slow on giving it
Elijah Newren writes:
>> And the draft copy I locally have for the next issue of what's cooking
>> has the comment removed already.
>>
>> Anything I missed?
>
> I was looking at the commit message for the merge commit where you
> merged in v2 of the series...
Ah, sorry, yes you are right, the me
Bert Wesarg writes:
> Having 'format.outputDirectory' is convenient, but being able to process
> all produced patches via a wildcard command is even more so. I.e.,
> using an argument like '/*'. Neither '-o' nor
> 'format.outputDirectory' can be parameterized to produce a new unique
> directory.
Bert Wesarg writes:
> Signed-off-by: Bert Wesarg
> ---
Squash these two into a single step. If "-o "
forgets to create necessary leading directories, it is just a bug.
Thanks.
Denton Liu writes:
> On Thu, Oct 03, 2019 at 05:03:14AM +0900, Junio C Hamano wrote:
>> Denton Liu writes:
>>
>> > which is in the middle of the log message. I expect the line to be
>> > reported as something in the range of 198-203,...
>>
>> That comes from not knowing who is complaining and
Johannes Schindelin writes:
> While at it, I invert the logic in v2: instead of forcing a prefix, I
> now force no prefix (and reduce the strip level from 1 to 0 when parsing
> the diff header).
Ah, that approach would also work and may be conceptually cleaner
than requiring a/ and b/ prefix and
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> From: Johannes Schindelin
>>
>> When parsing the diffs, `range-diff` expects to see the prefixes `a/`
>> and `b/` in the diff headers.
>
> If so, passing src/dst prefix as command line option is a much
> better solut
Hi,
I made some fixes to the punctuation and capitalization in the comments
you added. You can take a look at [0].
Just to be sure, I get the following text in git-gui when I ran your
example:
<<< HEAD
+Proin bibendum purus ut est tristique, non pharetra dui consectetur.
||| merge
Hi Bert,
> Subject: format-patch: document and exercise that -o does only create the
> trailing directory
s/does only create/only creates/ ?
Anyway, as a prepatory patch, I don't think that it's necessary. Maybe
it's just me but I assume that most tools create at most one directory
deep. Even m
On Wed, Oct 2, 2019 at 1:10 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I see you picked up this corrected series in pu; thanks. However,
> > your merge commit, 2a99d6b6ff7c ("Merge branch
> > 'en/fast-imexport-nested-tags' into pu", 2019-10-02), claims "Seems to
> > break t9300 whe
On 2019-10-01 2:00 p.m., Pratyush Yadav wrote:
So here's what I propose: why don't we try to do something similar? What
about running `git-gc --auto` in the background when the user makes a
commit (which I assume is the most common operation in git-gui). This
would be disabled when the user sets
Hi Junio,
On Thu, 3 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > When parsing the diffs, `range-diff` expects to see the prefixes `a/`
> > and `b/` in the diff headers.
>
> If so, passing src/dst prefix as command lin
On Thu, Oct 03, 2019 at 05:03:14AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > which is in the middle of the log message. I expect the line to be
> > reported as something in the range of 198-203,...
>
> That comes from not knowing who is complaining and what it is
> reading. In thi
Elijah Newren writes:
> I see you picked up this corrected series in pu; thanks. However,
> your merge commit, 2a99d6b6ff7c ("Merge branch
> 'en/fast-imexport-nested-tags' into pu", 2019-10-02), claims "Seems to
> break t9300 when merged to 'pu'.". I know v1 did that and I could
> reproduce, bu
On Thu, Oct 03, 2019 at 04:44:55AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Applying: dir: special case check for the possibility that pathspec is
> > NULL
> > error: corrupt patch at line 87
>
> This refers to line 87 of the input file, not a line that begins
> with "@@
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When parsing the diffs, `range-diff` expects to see the prefixes `a/`
> and `b/` in the diff headers.
If so, passing src/dst prefix as command line option is a much
better solution, I think. diff.noprefix may not st
On Wednesday, 2 October 2019 18:10:44 CEST Jeff King wrote:
> On Sun, Sep 22, 2019 at 02:36:37AM +0400, Alicenab wrote:
>
> > Hi there!
> > I have a translated ProGit2 book to Azerbaijan language.
> > As code of country name name for our country(az) have already taken, I have
> > created "aze" ver
Denton Liu writes:
> which is in the middle of the log message. I expect the line to be
> reported as something in the range of 198-203,...
That comes from not knowing who is complaining and what it is
reading. In this case, "git apply" issues a warning because it is
fed .git/rebase-apply/patch
On Wed, Oct 02, 2019 at 11:05:13AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> When parsing the diffs, `range-diff` expects to see the prefixes `a/`
> and `b/` in the diff headers.
>
> These prefixes can be forced off via the config setting
> `diff.noprefi
Denton Liu writes:
> Applying: dir: special case check for the possibility that pathspec is
> NULL
> error: corrupt patch at line 87
This refers to line 87 of the input file, not a line that begins
with "@@ -87,count...", doesn't it? If the sender hand edits a
patch without correct
Am 01.10.19 um 20:00 schrieb Pratyush Yadav:
> So here's what I propose: why don't we try to do something similar? What
> about running `git-gc --auto` in the background when the user makes a
> commit (which I assume is the most common operation in git-gui). This
> would be disabled when the use
necessary because the
> inconsistencies caused by not doing things the code updated by the
> earlier steps do (e.g. leaving number of commits recorded in
> total_nr and done_nr stale) were masked by re-reading the info from
> the on-disk file. And this step exposes these inconsistencie
On Wed, Oct 2, 2019 at 2:05 PM Johannes Schindelin via GitGitGadget
wrote:
> When parsing the diffs, `range-diff` expects to see the prefixes `a/`
> and `b/` in the diff headers.
>
> These prefixes can be forced off via the config setting
> `diff.noprefix=true`. As `range-diff` is not prepared for
Hi Johannes,
Le 02/10/2019 à 10:20, Johannes Schindelin a écrit :
> Hi,
>
> On Fri, 27 Sep 2019, Phillip Wood wrote:
>
>> Hi Alban
>>
>> Thanks for removing some more unnecessary work reloading the the todo list.
>>
>> On 25/09/2019 21:13, Alban Gruin wrote:
>>> Currently, complete_action() call
Hi Junio and Johannes,
Le 02/10/2019 à 10:59, Junio C Hamano a écrit :
> Johannes Schindelin writes:
>
>> Hi Junio,
>>
>> On Wed, 2 Oct 2019, Junio C Hamano wrote:
>>
>>> Alban Gruin writes:
>>>
`total_nr' is the total amount of items, done and toto, that are in a
todo list. But unli
On Tue, Oct 1, 2019 at 11:33 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > * other commands (archive, bisect, clean?, gitk, shortlog, blame,
> > fsck?, etc.) likely need to pay attention to sparsity patterns as
> > well, but there are some special cases:
>
> "git archive" falls into th
On Sun, Sep 22, 2019 at 02:36:37AM +0400, Alicenab wrote:
> Hi there!
> I have a translated ProGit2 book to Azerbaijan language.
> As code of country name name for our country(az) have already taken, I have
> created "aze" version of it.
> I hope it will be no problem for you.
> Partial translatio
On Thu, Sep 05, 2019 at 11:39:26AM -0700, Jonathan Tan wrote:
> > I'm not really opposed to what you're doing here, but I did recently
> > think of another possible use for .promisor files. So it seems like a
> > good time to bring it up, since presumably we'd have to choose one or
> > the other.
On Fri, Sep 13, 2019 at 08:06:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
> >
> >> This comment has nothing to do with the change, but the way the
> >> patch is presented is quite hard to follow, in that the preimage
On 10/2/19 12:04 AM, Junio C Hamano wrote>>
>> Well, if you write
>>
>> enum { BIT_0 = 1, BIT_1 = 2, BIT_3 = 4 } var;
>>
>> it's pretty much a promise that the normal value for the var is one
>> of these listed values to your readers.
>
> ... that is why compilers give a warning when you writ
Hi Junio,
On Mon, Sep 30, 2019 at 2:10 PM Elijah Newren wrote:
>
> This series improves the incremental export story for fast-export and
> fast-import (--export-marks and --import-marks fell a bit short),
> fixes a couple small export/import bugs, and enables handling nested
> tags. In particula
On Tue, Oct 1, 2019 at 12:39 PM Elijah Newren wrote:
>
> On Tue, Oct 1, 2019 at 12:35 PM Denton Liu wrote:
> >
> > Hi Elijah,
> >
> > Sorry for dragging out this thread for so long...
> >
> > On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
> >
> > [...]
> >
> > > diff --git a/t/t00
ut it looks pretty good to me.
My only complaint is that I think putting the new "private" bits of the
progress API into the header (with a comment) is a lesser evil than
re-declaring them in test-progress.c (if only because the compiler could
tell us if the two get out of sync). But I can live with it either way.
-Peff
On Wed, Sep 25, 2019 at 01:21:01AM -0700, Denton Liu wrote:
> Fix these problems by emulating the compile process better, including
> test compiling dummy *.hcc C sources generated from the *.h files and
> passing $(ALL_CFLAGS) into the compiler for the $(HCO) target so that
> these custom flags c
h/cleanups topic and get them
> advance together, as I do not expect any one of them to be blocking
> the other two.
Just re-posting this follow-on from the earlier thread (it goes on top
of the third one):
-- >8 --
Subject: git_mkstemps_mode(): replace magic numbers with computed value
On Wednesday 2019-10-02 15:55, Jeff King wrote:
So instead of this:
$ git fetch origin master
try this:
$ git fetch origin
It creates the master branch. This is what I'm trying to avoid.
or even this:
$ git fetch origin master:refs/remotes/origin/master
Bingo. It's ugly but it works
On Wed, Oct 02, 2019 at 11:41:53AM +0200, Johannes Schindelin wrote:
> Hi Michal,
>
> On Wed, 2 Oct 2019, Michal Suchánek wrote:
>
> > I get a crash in range-diff. It used to work in the past but I don't use
> > it often so can't really say if this is a regression or a particular
> > data trigger
On Wed, Oct 02, 2019 at 03:10:12PM +0200, Martin Nicolay wrote:
> I don't know if this is a lack of understanding or a software or
> documentation bug.
>
> man git-fetch says about tags:
>By default, any tag that points into the histories being fetched is
>also fetched; the effect
On Wed, Oct 02, 2019 at 05:32:13PM +0530, Rohit Sarkar wrote:
> Hi,
> I was looking into writing a patch for the issue [1] where if an user has
> multiple remotes each with a remote tracking branch of the same name say
> xyz, 'git checkout xyz' fails with "error: pathspec 'xyz' did not match any
>
On 10/2/2019 2:18 AM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> Is that the expected behavior? In a sparse-checkout, wouldn't you _want_
>> Git to report things outside the cone?
>
> That should be optional, I would think. When you declare "by
> default, this the subset of the project
Hi Phillip,
On Wed, 2 Oct 2019, Phillip Wood wrote:
> On 02/10/2019 09:16, Johannes Schindelin wrote:
> >
> > On Fri, 27 Sep 2019, Phillip Wood wrote:
> >
> > > Hi Alban
> > >
> > > On 25/09/2019 21:13, Alban Gruin wrote:
> > > > [...]
> > > >builtin/rebase.c | 5 +
> > > >1 file chang
Hi Junio,
On Wed, 2 Oct 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 2 Oct 2019, Junio C Hamano wrote:
> >
> >> Alban Gruin writes:
> >>
> >> > `total_nr' is the total amount of items, done and toto, that are in a
> >> > todo list. But unlike `nr', it was not updated
Hi Michal,
On Wed, 2 Oct 2019, Michal Suchánek wrote:
> I get a crash in range-diff. It used to work in the past but I don't use
> it often so can't really say if this is a regression or a particular
> data triggering the crash.
It would always be helpful to add a Minimal, Complete & Verifiable
Hi Dscho
On 02/10/2019 09:16, Johannes Schindelin wrote:
Hi,
On Fri, 27 Sep 2019, Phillip Wood wrote:
Hi Alban
On 25/09/2019 21:13, Alban Gruin wrote:
>>> [...]
builtin/rebase.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index e8319d59
Hi Junio,
On Wed, 2 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > - sudo apt-get install -y coccinelle &&
> > + sudo apt-get install -y coccinelle coccinelle libcurl4-openssl-dev
> > libssl-dev libexpat-dev gettext &&
>
> I think "s/coccin
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 2 Oct 2019, Junio C Hamano wrote:
>
>> Alban Gruin writes:
>>
>> > `total_nr' is the total amount of items, done and toto, that are in a
>> > todo list. But unlike `nr', it was not updated when an item was
>> > appended to the list.
>>
>> s/am
Hi,
On Fri, 27 Sep 2019, Phillip Wood wrote:
> Hi Alban
>
> Thanks for removing some more unnecessary work reloading the the todo list.
>
> On 25/09/2019 21:13, Alban Gruin wrote:
> > Currently, complete_action() calls sequencer_continue() to do the
> > rebase. Even though the former already has
Hi,
On Fri, 27 Sep 2019, Phillip Wood wrote:
> Hi Alban
>
> On 25/09/2019 21:13, Alban Gruin wrote:
> > get_replay_opts() did not fill `squash_onto' if possible, meaning that
>
> I'm not sure what you mean by 'if possible' here, I think the sentance makes
> sense without that.
>
> > this field sh
Hi Junio,
On Wed, 2 Oct 2019, Junio C Hamano wrote:
> Alban Gruin writes:
>
> > `total_nr' is the total amount of items, done and toto, that are in a
> > todo list. But unlike `nr', it was not updated when an item was
> > appended to the list.
>
> s/amount/number/, as amount is specifically for
Hi,
On Wed, 11 Sep 2019, Jeff Hostetler wrote:
> On 9/10/2019 9:54 AM, Garima Singh wrote:
> > Ping :) Any thoughts on this?
> >
> > On 8/27/2019 12:56 PM, Garima Singh via GitGitGadget wrote:
> > > Emit trace2_cmd_mode() messages for each commit-graph sub-command.
> > >
> > > The commit graph co
Pratyush,
On Tue, Oct 1, 2019 at 7:31 PM Pratyush Yadav wrote:
>
> On 01/10/19 05:22PM, Bert Wesarg wrote:
> > On Tue, Oct 1, 2019 at 4:24 PM Pratyush Yadav
> > wrote:
> > >
> > > Hi,
> > >
> > > I don't see any difference between v3 and v2 of this patch. What changed
> > > in this version?
> >
On Tue, Oct 1, 2019 at 8:00 PM Pratyush Yadav wrote:
> So here's what I propose: why don't we try to do something similar? What
> about running `git-gc --auto` in the background when the user makes a
> commit (which I assume is the most common operation in git-gui). This
> would be disabled when t
Junio C Hamano writes:
> William Baker writes:
>
>> Although my debugger might not be the smartest, I haven't noticed any
>> downsides to switching this to an enum.
>
> Well, if you write
>
> enum { BIT_0 = 1, BIT_1 = 2, BIT_3 = 4 } var;
>
> it's pretty much a promise that the normal value
"Chris Zehner via GitGitGadget" writes:
> - that begin with a hash.
> + Put a backslash ("`\`") in front of each hash for patterns
> + containing a hash.
> +
> + - A # after a pattern will be treated as the start of a comment.
> + Put a backslash ("`\`") in front of each hash for patterns
"Chris Zehner via GitGitGadget" writes:
> Why make this change?
> =
>
> Add the ability to use # to put comments after ignore patterns. This is
> useful for documenting the reason for particular ignore patterns inclusion
> and structure.
>
> Right now a common convention in .g
Elijah Newren writes:
> * other commands (archive, bisect, clean?, gitk, shortlog, blame,
> fsck?, etc.) likely need to pay attention to sparsity patterns as
> well, but there are some special cases:
"git archive" falls into the same class as fast-(im|ex)port; it
should ignore the sparse cone by
Derrick Stolee writes:
> Is that the expected behavior? In a sparse-checkout, wouldn't you _want_
> Git to report things outside the cone?
That should be optional, I would think. When you declare "by
default, this the subset of the project I am interested in", we
should honor it, I would think.
"Johannes Schindelin via GitGitGadget"
writes:
> - sudo apt-get install -y coccinelle &&
> + sudo apt-get install -y coccinelle coccinelle libcurl4-openssl-dev
> libssl-dev libexpat-dev gettext &&
I think "s/coccinelle //" is necessary here (assuming that "apt-get install"
is the
All three patches looked sensible.
Even though there is no dependency or relationships among them
(beyond that they got written at the same time by the same person),
I'll just queue them on a single ah/cleanups topic and get them
advance together, as I do not expect any one of them to be blocking
Jeff King writes:
> ... This is really an internal implementation
> detail of how the slab code works. It would be nice if callers didn't
> have to care about it. Perhaps we ought to have a slab foreach()
> function that encapsulates this, which would let this caller do
> something like:
>
> co
Alex Henrie writes:
> On Mon, Sep 30, 2019 at 3:48 AM Junio C Hamano wrote:
>>
>> Alex Henrie writes:
>>
>> > Well, I admit that code clarity is somewhat subjective. To me it's not
>> > obvious that "if (q->nr <= j)" means "if the loop exited normally",
I agree that it is subjective, but "if c
"Johannes Schindelin via GitGitGadget"
writes:
> With the en/merge-recursive-cleanup patches already having advanced to next,
> the problem I discovered when rebasing Git for Windows' branch thicket
> becomes quite relevant now: t3030.35 fails consistently in the MSVC build &
> test (this part of
William Baker writes:
> Although my debugger might not be the smartest, I haven't noticed any
> downsides to switching this to an enum.
Well, if you write
enum { BIT_0 = 1, BIT_1 = 2, BIT_3 = 4 } var;
it's pretty much a promise that the normal value for the var is one
of these listed v
* Junio C. Hamano:
>> Is there a way to get the patch data, as parsed by git apply or git
>> am, and dump it back in patch format, without actually applying the
>> patch to a working tree?
>
> So, "the patch data as used by apply" is what you get from mailinfo.
> If it is a patch that applies to w
William Baker writes:
> I saw that the code base is currently a mix of #define and enums when it
> comes to flags (e.g. dir_struct.flags and rebase_options.flags are both
> enums) and so using one here would not be something new stylistically.
Yes. But it is a different matter to spread a bad
Florian Weimer writes:
> git mailinfo splits a message into headers, commit message, and patch
> text, but does not actually parse the patch text. As a result, the
> patch portion produced by git mailinfo can contain something that
> looks like a patch, but actually isn't.
Yes, mailinfo is abou
. leaving number of commits recorded in
total_nr and done_nr stale) were masked by re-reading the info from
the on-disk file. And this step exposes these inconsistencies
because the extra reading from the file no longer happens.
That is my reading of the series---did I get it right?
I wonder if that c
Alban Gruin writes:
> `total_nr' is the total amount of items, done and toto, that are in a
> todo list. But unlike `nr', it was not updated when an item was
> appended to the list.
s/amount/number/, as amount is specifically for something
that cannot be counted.
Perhaps a stupid language ques
On Tue, Oct 1, 2019 at 3:29 PM Derrick Stolee wrote:
>
> On 10/1/2019 9:06 AM, Matheus Tavares Bernardino wrote:
> > Hi,
> >
> > During Git Summit it was mentioned that git-grep searches outside
> > sparsity pattern which is not aligned with user expectation. I took a
> > quick look at it and it s
Hey,
I face same issue a few days ago. Initially I thought `~/.zsh/_git` should be a
dictionary. I’ve made all required actions, but completion didn't work. After a
few hours I found that it should be just a file instead of a dictionary.
I have two ideas how to patch this comments to help anot
On Tue, Oct 1, 2019 at 12:35 PM Denton Liu wrote:
>
> Hi Elijah,
>
> Sorry for dragging out this thread for so long...
>
> On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
>
> [...]
>
> > diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> > index 192c94eccd..a840919967 1007
Hi Elijah,
Sorry for dragging out this thread for so long...
On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
[...]
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index 192c94eccd..a840919967 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -
On Tue, Oct 1, 2019 at 11:41 AM Denton Liu wrote:
>
> Hi Elijah,
>
> On Tue, Oct 01, 2019 at 11:30:05AM -0700, Elijah Newren wrote:
>
> [...]
>
> > diff --git a/dir.c b/dir.c
> > index 7ff79170fc..bd39b86be4 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -1962,8 +1962,9 @@ static enum path_treatmen
Hi Denton,
On Tue, 1 Oct 2019, Denton Liu wrote:
> Sorry for not replying or rolling this in earlier, I was waiting for
> my series to hit master before doing this change but I guess it
> doesn't really hurt to do it any earlier.
No worries, thank you for working on this!
I wonder whether it wo
Hi Elijah,
On Tue, Oct 01, 2019 at 11:30:05AM -0700, Elijah Newren wrote:
[...]
> diff --git a/dir.c b/dir.c
> index 7ff79170fc..bd39b86be4 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1962,8 +1962,9 @@ static enum path_treatment
> read_directory_recursive(struct dir_struct *dir,
>
On 10/1/2019 9:06 AM, Matheus Tavares Bernardino wrote:
> Hi,
>
> During Git Summit it was mentioned that git-grep searches outside
> sparsity pattern which is not aligned with user expectation. I took a
> quick look at it and it seems the reason is
> builtin/grep.c:grep_cache() (which also greps
ies since Elijah's careful
>> review of the RFC. There are definitely areas where this can be
>> made more robust, but I'd like to save those for a follow-up series.
>>
>> Junio: I know you didn't track this in the recent "what's cooking"
>&g
On 26/09/19 11:13PM, Johannes Sixt wrote:
> Am 26.09.19 um 21:15 schrieb Pratyush Yadav:
> > Reading the Stackoverflow link, it seems this is already possible via an
> > undocumented config variable "gui.gcwarning". I haven't tried using it
> > though, but I see no reason for it to not work (look
Hi,
On Tue, 1 Oct 2019, Pratyush Yadav wrote:
> On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> > > > wrote:
> > > > > gitdir is used in a lot o
On 01/10/19 09:46AM, Denton Liu wrote:
> Hi Pratyush,
>
> On Tue, Oct 01, 2019 at 07:44:35PM +0530, Pratyush Yadav wrote:
> > Since I have taken over maintainership of git-gui, it is a good idea to
> > point new contributors to my fork of the project, so they can see the
> > latest version of the
On 01/10/19 05:22PM, Bert Wesarg wrote:
> On Tue, Oct 1, 2019 at 4:24 PM Pratyush Yadav wrote:
> >
> > Hi,
> >
> > I don't see any difference between v3 and v2 of this patch. What changed
> > in this version?
>
> nothing, but 2/2 changed.
I don't see a v3 of 2/2 in my inbox. A search on public-i
ere this can be
> made more robust, but I'd like to save those for a follow-up series.
>
> Junio: I know you didn't track this in the recent "what's cooking"
> list, and I don't expect you to take it until I re-roll v3 to
> include the .gitignore interaction I already pointed out.
Oh, sorry, I missed this. By the way, is there any reason I wasn't
cc'ed on this round after reviewing the RFC?
Hi Pratyush,
On Tue, Oct 01, 2019 at 07:44:35PM +0530, Pratyush Yadav wrote:
> Since I have taken over maintainership of git-gui, it is a good idea to
> point new contributors to my fork of the project, so they can see the
> latest version of the project.
>
> Signed-off-by: Pratyush Yadav
Junio
Hi Johannes,
Sorry for not replying or rolling this in earlier, I was waiting for my
series to hit master before doing this change but I guess it doesn't
really hurt to do it any earlier.
On Tue, Oct 01, 2019 at 04:16:26AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schin
On Tue, Oct 1, 2019 at 6:30 AM Bert Wesarg wrote:
>
> Hi,
>
> On Tue, Oct 1, 2019 at 3:06 PM Matheus Tavares Bernardino
> wrote:
> >
> > Hi,
> >
> > During Git Summit it was mentioned that git-grep searches outside
> > sparsity pattern which is not aligned with user expectation. I took a
> > quic
On 2019-10-01 6:08 a.m., Bert Wesarg wrote:
Wrapping filenames is an unexpected experience in UX design. Disable
wrapping and add a horizontal scrollbar to the files list to remove this.
(Thanks for working on gitk and git-gui!)
I have to say I'm mildly opposed to this change. The reason is t
On Tue, Oct 1, 2019 at 4:24 PM Pratyush Yadav wrote:
>
> Hi,
>
> I don't see any difference between v3 and v2 of this patch. What changed
> in this version?
nothing, but 2/2 changed.
Bert
>
> On 30/09/19 09:54PM, Bert Wesarg wrote:
> > Replace the hand-coded call to git check-attr with the alre
On Tue, Oct 01, 2019 at 01:33:10AM +0200, Ali Utku Selen wrote:
> Fix possible segfault when cloning a submodule shallow.
Thanks. Just looking at the context, this is clearly the right thing to
be doing.
> It is possible to have unallocated slabs in shallow.c's commit_depth
> for a shallow submo
Hello,
Johannes Schindelin writes:
> On Fri, 20 Sep 2019, Mike Hommey wrote:
>> 6. Newcomers don't really have any idea /what/ they could contribute.
>> They either have to come with their own itch to scratch, or read the
>> code to figure out if there's something to fix.
>
> I think this is ver
On Mon, Sep 30, 2019 at 11:58:49PM -0700, Elijah Newren wrote:
> In commit 743474cbfa8b ("merge-recursive: provide a better label for
> diff3 common ancestor", 2019-08-17), the label for the common ancestor
> was changed from always being
>
> "merged common ancestors"
>
> to instead be
Hi,
I don't see any difference between v3 and v2 of this patch. What changed
in this version?
On 30/09/19 09:54PM, Bert Wesarg wrote:
> Replace the hand-coded call to git check-attr with the already provided one.
>
> Signed-off-by: Bert Wesarg
> ---
> lib/diff.tcl | 15 +--
> 1 fi
On 26/09/19 10:46AM, Thomas Klaeger via GitGitGadget wrote:
> From: Thomas Klaeger
>
> Git for Windows 2.x ships with an executable that starts the Git Bash
> with all the environment variables and what not properly set up. It is
> also adjusted according to the Terminal emulator option chosen wh
s in the recent "what's cooking"
list, and I don't expect you to take it until I re-roll v3 to
include the .gitignore interaction I already pointed out.
Thanks,
-Stolee
On 30/09/19 11:42AM, Johannes Schindelin wrote:
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> > > wrote:
> > > > gitdir is used in a lot of places, and I think all those would
> > > > also
> > > >
Hi,
On Tue, Oct 1, 2019 at 3:06 PM Matheus Tavares Bernardino
wrote:
>
> Hi,
>
> During Git Summit it was mentioned that git-grep searches outside
> sparsity pattern which is not aligned with user expectation. I took a
> quick look at it and it seems the reason is
> builtin/grep.c:grep_cache() (w
On 30/09/19 12:27PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
>
> > On 26/09/19 10:46AM, Thomas Klaeger via GitGitGadget wrote:
> > > From: Thomas Klaeger
> > >
> > > Git for Windows 2.x ships with an executable that starts the Git Bash
> > > with all the e
On Mon, Sep 30, 2019 at 3:31 PM Denton Liu wrote:
>
> Hi Elijah,
>
> On Mon, Sep 30, 2019 at 12:11:06PM -0700, Elijah Newren wrote:
> > Commits 404ebceda01c ("dir: also check directories for matching
> > pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
> > match files under a
On Mon, Sep 30, 2019 at 3:55 PM Elijah Newren wrote:
>
> In commit 743474cbfa8b ("merge-recursive: provide a better label for
> diff3 common ancestor", 2019-08-17), the label for the common ancestor
> was changed from always being
>
> "merged common ancestors"
>
> to instead be based on t
Am 30.09.19 um 12:27 schrieb Johannes Schindelin:
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
>>> + if {$cmdLine != $normalized && [file exists $cmdLine]} {
>>
>> Why the $cmdLine != $normalized? When would they be equal? The string
>> substitution should always change $cmdLine.
>
> Except when
; previous value of promisors) is also free()'d. This double-free error
> was unrecoverable for the user without removing the filter or re-cloning
> the repo and hoping to miss this edge case.
>
> Now, when promisor_remote_move_to_tail() would be a no-op, just do a
> no-op. In case
801 - 900 of 116325 matches
Mail list logo
