Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> Dear Pratyush,
>
> I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> the stage-list. But I think it should be disabled, like the 'Revert
> Hunk' and 'Revert Line' menu entry.
>
> Can you confirm this?
Technically, it need not be dis
<4>,
> + <5>,
> + <6>,
> + <7>;
There is little variation in the lines, but if that is what occurs in
real life, so be it.
This patch is good. Thanks!
Reviewed-by: Johannes Sixt
-- Hannes
Am 19.10.19 um 00:04 schrieb Denton Liu:
> diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
> index 34ac28c056..9e62d43cac 100755
> --- a/t/t7408-submodule-reference.sh
> +++ b/t/t7408-submodule-reference.sh
> @@ -123,7 +123,7 @@ test_expect_success 'missing submodule al
Am 17.10.19 um 07:08 schrieb Birger Skogeng Pedersen:
> Hi Pratyush,
>
> On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
>> I mentioned this earlier, and I'll mention this again: I'm not sure
>> whether this feature would be a good thing for the larger population. So
>> this _might_ not end
[Removed bouncing addresses of Matthieu Moy and William Duclot from Cc]
Am 16.10.19 um 22:32 schrieb Stephen Boyd:
> diff --git a/t/t4018/dts-nodes-multiline-prop
> b/t/t4018/dts-nodes-multiline-prop
> new file mode 100644
> index ..db4b4bdda686
> --- /dev/null
> +++ b/t/t4018/dts-nod
Am 08.10.19 um 16:43 schrieb Stephen Boyd:
> Quoting Johannes Sixt (2019-10-05 07:09:11)
>> Am 04.10.19 um 23:30 schrieb Stephen Boyd:
>>> --- /dev/null
>>> +++ b/t/t4018/dts-nodes-multiline-prop
>>> @@ -0,0 +1,12 @@
>>> +/ {
>>> + labe
Am 09.10.19 um 03:19 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> We do not want to have it for *all* cases, where we return -1 - pos, but
>> only for those cases, where the result was actually encoded by
>> index_pos_to_insert_pos().
>
> Yup, I agree with
Am 08.10.19 um 14:04 schrieb Johannes Schindelin:
> So you got what you wished for:
> https://public-inbox.org/git/pull.378.git.gitgitgad...@gmail.com
After having seen the result I do not wish for it anymore. (Not that I
had "wished" for it in the first place...) It does not make the result
any m
Am 08.10.19 um 08:48 schrieb Johannes Schindelin via GitGitGadget:
> We have just introduced the helper `index_pos_to_insert_pos()` to help
> avoiding underflows when returning `-1 - pos` for cases where we want to
> return an insert position, using the ones' complement (as `int`).
We do not want
Am 06.10.19 um 02:02 schrieb Junio C Hamano:
> Johannes Schindelin writes:
>
>>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a
>>> corresponding extract_pos_and_found_condition() and use it everywhere,
>>> it is more obfuscating than necessary.
>>
>> I do disagree here. No o
Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> While reviewing some dts diffs recently I noticed that the hunk header
> logic was failing to find the containing node. This is because the regex
> doesn't consider properties that may span multiple lines, i.e.
>
> property = ,
>
Am 04.10.19 um 11:55 schrieb Johannes Schindelin:
> On Fri, 4 Oct 2019, Junio C Hamano wrote:
>> These three look good and too similar to each other, which makes me
>> wonder if we want to allow them simply write
>>
>> return insert_pos_as_negative_offset(nr);
>>
>> with something like
>>
>>
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
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
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 (looking at
> git-gui.sh:4141).
Ah! That explains why
Am 26.09.19 um 19:31 schrieb Birger Skogeng Pedersen:
> Every once in a while, I get the "This repository currently has
> approximately (some number) loose objects." popup dialog.
>
> I don't want to sound arrogant, but I find this popup along with the
> dialog showing after that prints the result
Am 23.09.19 um 12:04 schrieb Alexandr Miloslavskiy via GitGitGadget:
> From: Alexandr Miloslavskiy
>
> After I discovered that UTF-16-LE-BOM test was bugged and still
> succeeded, I decided that better tests are required. Possibly the best
> option here is to compare git results against hardcoded
Am 23.09.19 um 10:37 schrieb SZEDER Gábor:
> On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
>> Huh? For signed cutoff and positive CUTOFF_DATE_SLOP,
>> cutoff - CUTOFF_DATE_SLOP < cutoff is ALWAYS true. Signed interger
>> underflow is undefined beh
Am 22.09.19 um 21:53 schrieb SZEDER Gábor:
> On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
>> On 22/09/2019 19:01, SZEDER Gábor wrote:
>>> +/*
>>> + * One day. See the 'name a rev close to epoch' test in t6120 when
>>> + * changing this value
>>> + */
>>> +#define CUTOFF_DATE_SLOP
Am 18.09.19 um 23:44 schrieb Kamil Domański:
> On 9/18/19 8:28 AM, Johannes Sixt wrote:
>> Am 18.09.19 um 02:11 schrieb Kamil Domański:
>>> DESCRIPTION
>>> ---
>>> @@ -21,6 +21,11 @@ commit IDs.
>>> OPTIONS
>>> ---
>
Am 18.09.19 um 02:11 schrieb Kamil Domański:
> Create a '--count' option for ls-remote, based on the one from
> for-each-ref. This allows e.g. to return only the first result
> from a sorted list of refs.
>
> Signed-off-by: Kamil Domański
> ---
> Documentation/git-ls-remote.txt | 11 ---
id the confusion.
Shorten the language to say "X does Y" in place of "X does not Z, but Y".
Cross-reference the referred-to commands like the rest of the file does.
Enumerate git-show because it includes the description as well.
Mention porcelain commands before plumbing comm
- Replace "SHA-1" by "object name", the modern name for hashes.
- Correct a few grammar weaknesses.
- Do not accidentally format a phrase in teletype font where quotes are
intended.
Signed-off-by: Johannes Sixt
---
I do not have the toolchain to check that a correc
age to say "X does Y" in place of "X does not Z, but Y".
Cross-reference the referred-to commands like the rest of the file does.
Mention porcelain commands before plumbing commands because I guess that
the paragraph is read more frequently in their context.
Signed-off-by:
Am 14.09.19 um 23:15 schrieb Pratyush Yadav:
> On 14/09/19 02:24PM, Birger Skogeng Pedersen wrote:
>> When the user
>> stages the last file in the "Unstaged Changes" widget, no file is
>> selected and the diff view becomes blank. When this is the case, I
>> would prefer that git-gui automatically s
Am 13.09.19 um 16:32 schrieb Pratyush Yadav:
> Is partial single and partial double click behaviour acceptable? Or
> should we make the entire row double click only? Or something else that
> I missed?
I don't mind adding the suggested double-click action, but removing the
single-click action wou
Am 11.09.19 um 19:48 schrieb Pratyush Yadav:
> Since this entire debate essentially boils down to personal preference,
> there is no clear answer. So I'll just go with the author's
> implementation.
Fair enough.
-- Hannes
Am 10.09.19 um 21:21 schrieb Pratyush Yadav:
> If there are no further objections with the series, I will merge it in.
No objections. I use it in production.
-- Hannes
Am 04.09.19 um 22:10 schrieb Bert Wesarg:
> The commit message widget does not wrap the next and has a configurable
> fixed width to avoid creating too wide commit messages. Though this was
> only enforced in the GUI. Now we also check the commit message at commit
> time for long lines and ask the
Am 04.09.19 um 22:43 schrieb Bert Wesarg:
> these people did not saw the entered text anyway. they would have
> needed to change the option (default to 75 characters) to see what
> they have typed. which could have been garbage to begin with.
Huh? When I type overly long line, all text scrolls out
Am 04.09.19 um 21:55 schrieb Bert Wesarg:
> I use my left thumb to press the left Alt key and it does not feel
> mildly awkward. As Alt is also used for the mnemonics, there will
> probably more of mildly awkward key combinations, wont there?
That may well be the case. However, it is the commit me
Am 04.09.19 um 21:20 schrieb Birger Skogeng Pedersen:
> On Wed, Sep 4, 2019 at 8:59 PM Johannes Sixt wrote:
>> Many keyboards do not have a right Alt-key. That means that Alt+1 to
>> Alt+4 combinations must be typed single-handed with the left hand. This
>> is mildly awkw
Am 04.09.19 um 16:30 schrieb Birger Skogeng Pedersen:
> The user cannot change focus between the list of files, the diff view and
> the commit message widgets without using the mouse (clicking either of
> the four widgets).
>
> With this patch, the user may set ui focus to the previously selected
Am 04.09.19 um 19:46 schrieb Pratyush Yadav:
> On 04/09/19 08:24AM, Johannes Sixt wrote:
>> That is worth a try. The check box title offers a natural hotkey then:
>> "_A_mend last commit", Alt-a.
>
> Right now, the binding proposed is Ctrl-e. My mental model for t
Am 03.09.19 um 14:45 schrieb Pratyush Yadav:
> Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it
> immediately takes me to the "Amend last commit" option. Then I can press
> space to select it and Tab again to get back to the commit message.
That works on Windows with Ctrl+S
Am 27.08.19 um 18:27 schrieb Giuseppe Crino':
> Hello, to debug some issues I built and installed git via
>
> $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> $ sudo make install
> $ git --version # git version 2.23.0.40.g4d8aada92f
>
> But it seems there's still some optimization going on
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
> However, I'm sure that a large percentage of developers out there will
> agree with me that having to use force (-f) to delete every cloned
> repo is annoying, and even worse, it creates the bad habit of always
> force-deleting everything.
IMO, t
Am 24.08.19 um 08:57 schrieb Bert Wesarg:
> On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>> On the other hand, if I had to actually move my hand over to a mouse or
>> trackpad and actually "click" on something then I would be super
>> annoyed. That would be simply horrible with RSI in min
Am 23.08.19 um 19:03 schrieb Pratyush Yadav:
> So how about we keep a copy of the diff in another variable. This allows
> us to enable undoing of reverts. The obvious limitations are that
> firstly, unless we use a stack/deque that means only one undo is
> allowed. I'm not sure if using an undo
Am 22.08.19 um 21:32 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 22.08.19 um 20:02 schrieb Saravanan Shanmugham (sarvi):
>>> We have a diskimage/fileysystem that has a 50G Git repository + 900G
>>> of binary/build articles and untracked files. When we m
Am 22.08.19 um 20:02 schrieb Saravanan Shanmugham (sarvi):
> We have a diskimage/fileysystem that has a 50G Git repository + 900G
> of binary/build articles and untracked files. When we mount such a
> diskimage, The verify first “git status” command can take as long
> 40-50minutes. Subsequent “git
Am 22.08.19 um 19:49 schrieb Thomas Gummerer:
> Right, the above is why I think 'touch' is a good idea here. Short of
> system clocks jumping around, which will most likely break more than
> this test anyway it guarantees that the timestamp is equal or greater
> than the timestamp of the index, wh
Am 21.08.19 um 16:56 schrieb Thomas Gummerer:
> On 08/20, Johannes Sixt wrote:
>> Am 20.08.19 um 08:56 schrieb Thomas Gummerer:
>>> Fix the test by updating the mtime of test.r, ...
>>
>>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>>> ind
Am 20.08.19 um 21:29 schrieb Pratyush Yadav:
> On 20/08/19 09:21PM, Johannes Sixt wrote:
>> Please don't do this. This confirmation dialog is unacceptable in my
>> workflow. I use reversals of hunks and lines frequently, almost like a
>> secondary code editor. My safety n
Am 19.08.19 um 23:41 schrieb Pratyush Yadav:
> Just like the user can select lines to stage or unstage, add the
> ability to revert selected lines.
>
> Signed-off-by: Pratyush Yadav
> + if {$revert} {
> + set query "[mc "Revert changes in file %s?" \
> + [shor
Am 20.08.19 um 08:56 schrieb Thomas Gummerer:
> Fix the test by updating the mtime of test.r, ...
> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> index e10f5f787f..66f75005d5 100755
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
> @@ -390,6 +390,7 @@ test_expect_success
Am 20.08.19 um 09:31 schrieb Denton Liu:
> Oops, this should read
>
> git_version="$(git --version >version && sed "s/.* //"
Am 19.08.19 um 22:44 schrieb Stephen Boyd:
> Quoting Johannes Sixt (2019-08-19 11:40:47)
>> Am 17.08.19 um 00:56 schrieb Stephen Boyd:
>>> diff --git a/t/t4018/dts-labels b/t/t4018/dts-labels
>>> new file mode 100644
>>> index ..27cd4921cfb6
>
Am 17.08.19 um 00:56 schrieb Stephen Boyd:
> The Linux kernel receives many patches to the devicetree files each
> release. The hunk header for those patches typically show nothing,
> making it difficult to figure out what node is being modified without
> applying the patch or opening the file and
Am 13.08.19 um 16:18 schrieb Pratyush Yadav:
> Now, I want to add a similar feature, but one that discards/resets the
> selected lines. And I'd like to avoid the hack that git-gui's
> apply_range_or_line is. So, is there a cleaner way to do this that does
> not involve generating a diff and then
Am 16.07.19 um 21:01 schrieb Junio C Hamano:
> but as long as we declare that we take "{ 0 }" as a mere convention
> [...], I am perfectly fine with it, and if it is hidden
> behind a macro, that would be even better ;-)
And I thought that "Avoid macros!" would be a welcome guideline...
I think w
Am 15.07.19 um 16:46 schrieb Jeff King:
> On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
>>> But it does fall down
>>> when the first element _has_ to be a struct (like, say, any user of our
>>> hashmap.[ch] interface).
>>
>> No, it does no
Am 14.07.19 um 02:51 schrieb Jeff King:
> I wonder if we could come up with a definition of INIT_ZERO such that:
>
> struct foo bar = { INIT_ZERO };
>
> worked everywhere. IMHO that is more readable than "{}" anyway.
Not when = {} becomes a well-established way to express
zero-initialization.
Am 13.07.19 um 23:29 schrieb Junio C Hamano:
> I do not think this position is maintainable, especially if you
> agree with me (and everybody else, including sparse) that this is a
> bad idea:
>
>> struct string_list dup_it = { 0, 0, 0, 1, 0 };
>
> The way I read "6.7.8 Initialization" (sorry,
Am 13.07.19 um 12:44 schrieb Johannes Sixt:
> Am 12.07.19 um 18:44 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> Am 12.07.19 um 00:03 schrieb Ramsay Jones:
>>>> diff --git a/range-diff.c b/range-diff.c
>>>> index ba1e9a4265..0f24a4ad12
Am 12.07.19 um 18:44 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 12.07.19 um 00:03 schrieb Ramsay Jones:
>>> diff --git a/range-diff.c b/range-diff.c
>>> index ba1e9a4265..0f24a4ad12 100644
>>> --- a/range-diff.c
>>> +++ b/range-diff.c
Am 12.07.19 um 00:03 schrieb Ramsay Jones:
> diff --git a/range-diff.c b/range-diff.c
> index ba1e9a4265..0f24a4ad12 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -102,7 +102,7 @@ static int read_patches(const char *range, struct
> string_list *list)
> }
>
> i
Am 10.07.19 um 20:40 schrieb Junio C Hamano:
> Heiko Voigt writes:
>
>> behavior. How about '--all-include-head'. Then e.g.
>>
>> git rev-parse --all-include-head --all --not origin/master
>>
>> would include the head ref like you proposed below?
>>
>> What do you think? Or would you rather g
Am 02.07.19 um 19:20 schrieb Junio C Hamano:
> Derrick Stolee writes:
>
>> On 7/1/2019 2:35 PM, Junio C Hamano wrote:
>>> Jeff King writes:
>>>
> First, we create a (temporary) merge commit of both branches (M3)
>
>
> R1---R2---R3---R4---R5---R6---R7---M3
>
Am 01.07.19 um 14:30 schrieb Derrick Stolee:
> On 7/1/2019 8:11 AM, Johannes Schindelin wrote:
>> Or we stop introducing new Perl calls, and use the perfectly fine
>> `test-tool path-utils file-size` command:
>>
>> https://github.com/git/git/blob/v2.22.0/t/helper/test-path-utils.c#L302-L312
>>
>> T
Am 01.07.19 um 00:25 schrieb Jeff King:
> On Sun, Jun 30, 2019 at 10:59:34PM +0200, Johannes Sixt wrote:
>
>> Am 30.06.19 um 21:48 schrieb Eric Sunshine:
>>> On Sun, Jun 30, 2019 at 2:57 PM Johannes Sixt wrote:
>>>> diff --git a/t/t5319-multi-pack-index
Am 30.06.19 um 21:48 schrieb Eric Sunshine:
> On Sun, Jun 30, 2019 at 2:57 PM Johannes Sixt wrote:
>> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
>> @@ -443,7 +443,7 @@ test_expect_success 'repack with minimum size does not
>
On my Windows system where the POSIX commands are provided by MSYS2,
I observe this output:
$ ls -l Makefile
-rw-r--r-- 1 Johannes Sixt 197121 101780 Jun 30 09:33 Makefile
Notice the blank in the user name. Obviously, extracting the size
of a file by counting columns won't work. But two tes
Am 30.06.19 um 15:05 schrieb Lars Schneider:
>> On Jun 24, 2019, at 11:58 AM, Jeff King wrote:
>> You'd have to split the renames into separate delete/adds, since they
>> can have a circular dependency. E.g. renaming "foo" to "bar" and "bar"
>> to "foo", you must remove "foo" and "bar" both, and t
Am 23.06.19 um 10:28 schrieb Dimitriy:
> brian m. carlson wrote:
>>
>> On 2019-06-22 at 21:42:33, Johannes Sixt wrote:
>>> Am 22.06.19 um 11:36 schrieb Dimitriy Ryazantcev:
>>>> diff --git a/strbuf.c b/strbuf.c
>>>> index 0e18b259ce..0a3ebc374
Am 22.06.19 um 11:36 schrieb Dimitriy Ryazantcev:
> Signed-off-by: Dimitriy Ryazantcev
> ---
> progress.c | 4 +++-
> strbuf.c | 16
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/progress.c b/progress.c
> index a2e8cf64a8..61d8cf5d04 100644
> --- a/prog
Am 19.06.19 um 20:39 schrieb Jeff King:
> But without that, I have to wonder what problem we are really solving.
You have a point here.
> Now it's baked into the binary. Later it will be baked into the
> distribution, but we still don't want anybody to touch it because their
> changes will be ove
Am 19.06.19 um 13:30 schrieb Johannes Schindelin:
> Interesting side note: I just realized that t6050-replace.sh does indeed
> contain
>
> test_i18ngrep "Needed a single revision" err
>
> so I wonder why that works.
Why should it not work? If GIT_TEST_GETTEXT_POISON is on, it pretends
succ
Am 19.06.19 um 05:49 schrieb Jeff King:
> On Tue, Jun 18, 2019 at 10:32:47PM +0200, Johannes Sixt wrote:
>
>> Am 17.06.19 um 18:54 schrieb Boxuan Li:
>>> diff --git a/templates/this--userdiff b/templates/this--userdiff
>>> new file mode 100644
>>> index 0
Am 19.06.19 um 01:12 schrieb Eric Sunshine:
> On Tue, Jun 18, 2019 at 8:24 AM Johannes Schindelin via GitGitGadget
> wrote:
>> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
>> @@ -474,7 +474,8 @@ test_expect_success MINGW 'redirect std handles' '
>> printf ".git\nfatal: Needed a single re
Am 18.06.19 um 22:32 schrieb Johannes Sixt:
> Am 17.06.19 um 18:54 schrieb Boxuan Li:
>> The userdiff.c has been rewritten to avoid hard-coded built-in
>> driver patterns. Now we ship
>> $(sharedir)/git-core/templates/userdiff that can be read using
>> git_config_fro
Am 17.06.19 um 18:54 schrieb Boxuan Li:
> The userdiff.c has been rewritten to avoid hard-coded built-in
> driver patterns. Now we ship
> $(sharedir)/git-core/templates/userdiff that can be read using
> git_config_from_file() interface, using a very narrow callback
> function that understands only
Am 18.06.19 um 03:29 schrieb brian m. carlson:
> On 2019-06-17 at 19:05:03, Johannes Schindelin wrote:
>> I guess it does not *really* matter all that much, but this does spawn a
>> new process (and I think it actually spawns 4 on Windows, for reasons, and
>> spawning processes is super expensive o
Am 13.06.19 um 01:31 schrieb brian m. carlson:
> [0] AFAIUI, Windows doesn't have RPATH-like functionality, and from what
> I've read, the same-directory behavior may be going away due to security
> concerns. I don't use Windows, so any solution there is fine as long as
> Dscho is happy.
The solu
Am 12.06.19 um 17:03 schrieb Shawn Landden:
> If a patch has been applied upstream AND THEN reverted, rebase still
> drops the patch, requiring the use of relative rebase git rebase -i
> HEAD~5 et cetera.
>
> git rebase should detect reverts as well.
You have the same patch that upstream has. Per
s helps on Windows, where test_cmp avoids spawning a process when
there is no difference.
Signed-off-by: Johannes Sixt
---
t/t7610-mergetool.sh | 135 ---
1 file changed, 90 insertions(+), 45 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
`awk`.
Signed-off-by: Johannes Sixt
---
git-mergetool.sh | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 8a937f680f..e3f6d543fb 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -279,15 +279,30
git-mergetool spawns an enormous amount of processes. For this reason,
the test script, t7610, is exceptionally slow, in particular, on
Windows. Most of the processes are invocations of git. There are
also some that can be replaced with shell builtins. Do so with `expr`.
Signed-off-by: Johannes
se having no && at the end.
Signed-off-by: Johannes Sixt
---
t/t7610-mergetool.sh | 170 +--
1 file changed, 85 insertions(+), 85 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 5b61c10a9c..b67440882b 100755
--- a/
ost
clean-ups.
- Commit message tweaks; see below.
- Did not include measurement results in the commit messages, because
I would have to repeat the measurement method every time.
Johannes Sixt (4):
t7610-mergetool: do not place pipelines headed by `yes` in subshells
t7610-mergetool: us
Am 10.06.19 um 19:21 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> +# here, $IFS is just a LF
>> +for line in $f
>> +do
>> +mode=${line%% *}# 1st word
>> +sha1=${line#"$mode "}
>> +
Am 10.06.19 um 19:17 schrieb Junio C Hamano:
> Johannes Sixt writes:
>> git-mergetool spawns an enormous amount of processes. For this reason,
>> the test script, t7610, is exceptionally slow, in particular, on
>> Windows. Most of the processes are invocations of git, but t
I just used git-send-email the first time since ages. When it finished,
I saw a stream of 16 warnings:
Warning: unable to close filehandle properly: Bad file descriptor during
global destruction.
The invocation was this:
git send-email --to git@vger.kernel.org patches
where the argument 'pat
mands
The reduction of processes is not as dramatic as I hoped, but still
more than 10%.
Johannes Sixt (3):
t7610-mergetool: do not place pipelines headed by `yes` in subshells
mergetool: dissect strings with shell variable magic instead of `expr`
mergetool: use shell variable magic instead of
se having no && at the end.
Signed-off-by: Johannes Sixt
---
t/t7610-mergetool.sh | 170 +--
1 file changed, 85 insertions(+), 85 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 5b61c10a9c..b67440882b 100755
--- a/
: Johannes Sixt
---
git-mergetool.sh | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 88fa6a914a..8a937f680f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -228,9 +228,8 @@ stage_submodule
` and `awk`.
Signed-off-by: Johannes Sixt
---
git-mergetool.sh | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 8a937f680f..e3f6d543fb 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -279,15 +279,30
Am 04.06.19 um 00:00 schrieb Drew DeVault:
> On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:
>> I have to wonder how --check works when 'am' applies multiple patches.
>>
>> When the second patch in a patch series depends on that the first patch
>> i
Am 03.06.19 um 16:25 schrieb Drew DeVault:
> +--check::
> + Instead of applying the patch(es), see if they are
> + applicable to the current working tree and/or the index
> + file and detects errors.
I have to wonder how --check works when 'am' applies multiple patches.
When the secon
Am 30.05.19 um 20:59 schrieb Ævar Arnfjörð Bjarmason:
>
> On Thu, May 30 2019, Johannes Sixt wrote:
>
>> - Do not enforce (but assume) syntactic correctness of language
>> constructs that go into hunk headers: we only want to ensure that
>> the keywords actually
then be liberal in what follows, assuming that the text that is
matched is syntactially correct.
Signed-off-by: Johannes Sixt
---
Am 28.05.19 um 23:01 schrieb Marc-André Lureau:
> Both of these changes were based on your recommendations. Would you
> mind sending a follow-up patch yourself?
Hi Ramsay,
I had a brief look at the series. IMO, it is a mistake to appease
-Wmissing-field-initializer.
We have two sorts of initializers:
- zero initializers: they just want to null out every field,
like CHILD_PROCESS_INIT and ad-hoc initializers of structs
such as xpparam_t pp = { 0 }
Am 28.05.19 um 18:34 schrieb Junio C Hamano:
> Marc-André Lureau writes:
>
>> Ok, I am adding:
>> ...
>> sure, I thought it was already covered.
>> ...
>> I think that would be fine, ok I am changing it
>
> Thanks, both.
>
> The previous round has already hit 'next' (which means that we won't
>
Am 28.05.19 um 18:37 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Junio will very likely appreciate if you resend with these fixes applied.
>
> Heh, thanks, for spotting, but this round has already been in 'next'
> so any updates should be done incremen
Am 28.05.19 um 07:42 schrieb LU Chuck:
>> From: Philip Oakley
>> The three dots is provided in the literal EXAMPLES section of the man page.
>> That is
>> probably an error, as I think it is meant to be an ellipsis to indicate
>> 'insert other
>> options here'.
>>
>> Simply remove the three dots
Am 27.05.19 um 10:01 schrieb LU Chuck:
> Hi team,
>
> The issue comes from https://github.com/git-for-windows/git/issues/2206.
>
> I want to re-write history by filter-branch command over a range of
> commits, but the command did not work.
> I have referred to the following three doc
Am 23.05.19 um 01:57 schrieb Maksim Odnoletkov:
> The problem with current behaviour is it makes it hard to use stash in
> scripts. A natural stash use case is: wrap some operation requiring a
> clean working tree with a stash push-pop pair. But that doesn't work
> properly when working tree is alr
> The word_regex pattern finds identifiers, integers, floats and
> operators, according to the Rust Reference Book.
>
> Signed-off-by: Marc-André Lureau
Acked-by: Johannes Sixt
> ---
> Documentation/gitattributes.txt | 2 ++
> t/t4018-diff-funcname.sh| 1 +
> t/t4
Am 20.05.19 um 19:04 schrieb marcandre.lur...@redhat.com:
> From: Marc-André Lureau
>
> This adds xfuncname and word_regex patterns for Rust, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The word_regex patter
Test cases for
> the hunk header patterns of matlab and octave under
> t/t4018 are added.
Thank you! This patch looks good. With or without the grammar and style
fixes below:
Acked-by: Johannes Sixt
Junio will very likely appreciate if you resend with these fixes applied.
>
> Signed
1 - 100 of 1357 matches
Mail list logo
