I was excited to see the RUNTIME_PREFIX for POSIX systems patchset go
by earlier this year. Although I didn't see any mention of it being
included in the 2.18.0 release notes, it does appear that it was merged
in for this release.
Has anyone else tried to get it working? It doesn't appear to be
On 03/07/18 15:34, Jeff King wrote:
> On Fri, Jun 29, 2018 at 02:10:59AM +0100, Ramsay Jones wrote:
>
>> On 28/06/18 23:03, Jeff King wrote:
>>> On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
>> [snip]
>>> Yes, it can go in quickly. But I'd prefer not to keep it in the long
>>>
On 07/03/2018 07:53 PM, Joshua Nelson wrote:
> diff --git a/t/t3104-ls-tree-optional-args.sh
> b/t/t3104-ls-tree-optional-args.sh
> new file mode 100755
> index 0..e9d8389bc
> --- /dev/null
> +++ b/t/t3104-ls-tree-optional-args.sh
> @@ -0,0 +1,63 @@
> +#!/bin/sh
> +
>
Use syntax similar to `git-checkout` to make optional for
`ls-tree`. If is omitted, default to HEAD. Infer arguments as
follows:
1. If args start with '--', assume to be HEAD
2. If exactly one arg precedes '--', treat the argument as
3. If more than one arg precedes '--', exit with an error
On 07/03/2018 03:15 AM, Eric Sunshine wrote:
> Thanks for contributing to Git. As this seems to be your first
> submission to the project, don't be alarmed by the extent and nature
> of the review comments. They are intended to help you polish the
> submission, and are not meant with ill-intent.
Agreed, ls-tree when called with no arguments was the main use case I
wrote this for; the rest was mostly because other commands allow greater
ambiguity and I wanted to make the syntax consistent.
I don't mind doing this for rev-list as well if that's a useful feature.
On 07/03/2018 06:55 PM,
On Tue, Jul 3, 2018 at 3:05 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> On Mon, Jul 2, 2018 at 8:58 PM, Joshua Nelson wrote:
>>> use syntax similar to `git-checkout` to make optional for
>>> `ls-tree`. if is omitted, default to HEAD. infer arguments as
>>> follows:
>>>
>>> 1. if
On Tue, Jul 03, 2018 at 06:05:16PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Jun 29 2018, Mike Hommey wrote:
>
> > On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Fri, Jun 29 2018, Mike Hommey wrote:
> >>
> >> > I noticed some slowness when
Tiago Botelho writes:
> git rev-list --first-parent --bisect-all F..E >revs &&
> test_line_count = 9 revs &&
> for rev in E e1 e2 e3 e4 e5 e6 e7 e8
> do
> grep "^$(git rev-parse $rev) " revs ||
> {
> echo "$rev not shown" >&2 &&
> return 1
> }
> done &&
> sed -e
On Tue, Jul 03, 2018 at 10:15:19AM -0400, Jeff King wrote:
> On Tue, Jul 03, 2018 at 04:06:50PM +0900, Mike Hommey wrote:
>
> > I had a first shot at that a few months ago, but the format of the
> > metadata branch made it impossible to push to github, hitting its push
> > size limit. With some
Johannes Schindelin writes:
> Seriously again, I sent a new iteration:
>
> https://public-inbox.org/git/pull.1.v3.git.gitgitgad...@gmail.com/
Thanks, will take a look but it is likely that I'll run out of time
today, so please be a bit patient.
Elijah Newren writes:
> On Mon, Jul 2, 2018 at 8:58 PM, Joshua Nelson wrote:
>> use syntax similar to `git-checkout` to make optional for
>> `ls-tree`. if is omitted, default to HEAD. infer arguments as
>> follows:
>>
>> 1. if args start with --
>> assume to be HEAD
>> 2. if exactly
On Tue, Jul 03, 2018 at 11:41:42AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > When the reference buffer is empty, diff_delta returns NULL without
> > really attempting anything, yet fast-import counts that as a delta
> > attempt.
>
> But that is an attempt nevertheless, no?
> On Jul 3, 2018, at 3:27 PM, Elijah Newren wrote:
>
> Hi Philip,
>
> On Tue, Jul 3, 2018 at 1:40 PM, Philip Prindeville
> wrote:
>> Hi.
>>
>> I tried to import into git a repo that I was working on (because it just
>> seemed easier), but when I tried to export the repo back out after
Teach 'git grep --only-matching', a new option to only print the
matching part(s) of a line.
For instance, a line containing the following (taken from README.md:27):
(`man gitcvs-migration` or `git help cvs-migration` if git is
Is printed as follows:
$ git grep --line-number --column
Hi,
Attached here is a third re-roll of my series to teach 'git grep
--only-matching'. (I didn't mention it in the thread, but I _thought_
that twice would be enough, so I think Peff's advice about not counting
on anything being the final re-roll of something applies to my thoughts,
too ;-) ).
The grep code invokes show_line() to display the contents of a matched
or context line in its output. Part of this execution is to print a line
header that includes information such as the kind, the line- and
column-number and etc. of that match.
To prepare for the addition of an option to print
Pratik Karki writes:
> +static struct commit *peel_committish(const char *name)
> +{
> + struct object *obj;
> + struct object_id oid;
It by itself is not a big enough deal to warrant a reroll, but
please make it a habit to leave a blank line between the
declarations and the first
On Fri, 29 Jun 2018 at 12:21, Johannes Schindelin
wrote:
>
> Hi Junio,
>
> On Thu, 28 Jun 2018, Junio C Hamano wrote:
>
> > What I meant by "many separte grep calls" was to contrast these two
> > approaches:
> >
> > * Have one typical output spelled out as "expect", take an output
> >from an
Pratik Karki writes:
> The motivation behind this commit is to extract the core part of
> do_reset() from sequencer.c and move it to a new detach_head_to()
> function in checkout.c.
>
> Here the index only gets locked after performing the first part of
> `do_reset()` rather than before which
Greetings,
We are contracted probate researchers. This is an investigation about a late
client with whom you share the same surname; your assistance will be greatly
appreciated. Are you aware of any investment made by such a person with us?
Please clarify,
EmaiL Reply to :
Pratik Karki writes:
> The function present in `git-legacy-rebase.sh` are used by backends
> so, this refactor tries to extract the functions out so that, the
> `git-legacy-rebase.sh` can be retired easily as the
> `git-rebase--common.sh` will provide the functions for now.
Makes sense.
Pratik Karki writes:
> This commit imitates the strategy that was used to convert the
> difftool to a builtin, see be8a90e (difftool: add a skeleton for the
> upcoming builtin, 2017-01-17) for details: This commit renames the
> shell script `git-rebase.sh` to `git-legacy-rebase.sh` and hands off
On 06/05, Thomas Gummerer wrote:
> The previous round was at
> <20180520211210.1248-1-t.gumme...@gmail.com>.
>
> Thanks Junio for the comments on the previous round.
>
> Changes since v2:
> - lowercase the first letter in some error/warning messages before
>marking them for translation
> -
Hi.
I tried to import into git a repo that I was working on (because it just seemed
easier), but when I tried to export the repo back out after making my changes I
found it choking on a few things.
It was explained to me (by the Bitkeeper folks) that git meta-data doesn’t
accurately track
Jeff King writes:
> On Mon, Jul 02, 2018 at 03:08:54PM -0500, Taylor Blau wrote:
>
>> Attached is the second re-roll of my series to teach 'git grep
>> --only-matching'. Since last time, not much has changed. The change I
>> did include is summarized below, and an inter-diff is attached as
>>
Alban Gruin writes:
> +static int run_git_checkout(struct replay_opts *opts, const char *commit,
> + int verbose, const char *action)
> +{
> + struct child_process cmd = CHILD_PROCESS_INIT;
> +
> + cmd.git_cmd = 1;
> +
> + argv_array_push(, "checkout");
>
Alban Gruin writes:
> Subject: Re: [GSoC][PATCH v2 5/7] sequencer: add a new function to silence a
> command, except if it fails.
Lose the full-stop at the end.
> This adds a new function, run_command_silent_on_success(), to
> redirect the stdout and stderr of a command to a strbuf, and then
Alban Gruin writes:
> As part of the rewrite of interactive rebase, the sequencer will need to
> open the sequence editor to allow the user to edit the todo list.
> Instead of duplicating the existing launch_editor() function, this
> refactors it to a new function, launch_specified_editor(),
Alban Gruin writes:
> + ret = fputs(buf.buf, todo);
> + if (ret < 0)
> + error_errno(_("Could not append help text to '%s'"),
> rebase_path_todo());
Error checking fputs() return is an improvement from the version
that has been queued on 'pu'. I think messages given to
Alban Gruin writes:
> -enum check_level {
> - CHECK_IGNORE = 0, CHECK_WARN, CHECK_ERROR
> -};
> -
> -static enum check_level get_missing_commit_check_level(void)
> +enum missing_commit_check_level get_missing_commit_check_level(void)
The new name definitely is better than "check_level" in
Elijah Newren writes:
> ...[merge will] abort if there are any changes registered in the index
> relative to the `HEAD` commit. (One exception is when the changed index
> entries are in the state that would result from the merge already.)
>
> While this high-level description does
Elijah Newren writes:
> `git merge-recursive` does a three-way merge between user-specified trees
> base, head, and remote. Since the user is allowed to specify head, we can
> not necesarily assume that head == HEAD.
Makes sense.
Elijah Newren writes:
> Modify index_has_changes() to take a struct istate* instead of just
> operating on the_index. This is only a partial conversion, though,
> because we call do_diff_cache() which implicitly assumes work is to be
> done on the_index. Ongoing work is being done elsewhere to
Eric Sunshine writes:
> It is split out from an earlier series[1] which additionally extended
> --chain-lint to work within subshells. I decided to make this an
> independent series because these (hopefully) non-controversial changes
> all stand on their own merit, and because I don't want to
Eric Sunshine writes:
> Signed-off-by: Eric Sunshine
> ---
> t/t3102-ls-tree-wildcards.sh| 2 +-
> t/t4010-diff-pathspec.sh| 4 ++--
> t/t9400-git-cvsserver-server.sh | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/t/t3102-ls-tree-wildcards.sh
Eric Sunshine writes:
> test_expect_success 'merge my-side@{u} records the correct name' '
> (
> - cd clone || exit
> - git checkout master || exit
> - git branch -D new ;# can fail but is ok
> + cd clone &&
> + git checkout master &&
> + test_might_fail git branch -D
Greetings,
We are contracted probate researchers. This is an investigation about a late
client with whom you share the same surname; your assistance will be greatly
appreciated. Are you aware of any investment made by such a person with us?
Please clarify,
EmaiL Reply to :
Mike Hommey writes:
> When the reference buffer is empty, diff_delta returns NULL without
> really attempting anything, yet fast-import counts that as a delta
> attempt.
But that is an attempt nevertheless, no? Attempted and failed to
find anything useful, that is. What problem are you trying
On Tue, Jul 03, 2018 at 10:45:51AM -0700, Junio C Hamano wrote:
> > I'm open to the idea that the new checks are too restrictive (both this
> > and the gitmodulesParse error we're discussing in [1]). They definitely
> > outlaw things that _used_ to be OK. And the security benefit is a little
> >
On Tue, Jul 3, 2018 at 2:31 PM Elijah Newren wrote:
> On Thu, Jun 28, 2018 at 2:40 PM, Junio C Hamano wrote:
> > * ds/multi-pack-index (2018-06-25) 24 commits
>
> pu fails to build for me (with the standard 'make DEVELOPER=1 ...'),
> and it appears to come from this series:
>
> midx.c:567:15:
Hi Derrick,
On Thu, Jun 28, 2018 at 2:40 PM, Junio C Hamano wrote:
> * ds/multi-pack-index (2018-06-25) 24 commits
> - midx: clear midx on repack
> - packfile: skip loading index if in multi-pack-index
> - midx: prevent duplicate packfile loads
> - midx: use midx in approximate_object_count
Duy Nguyen writes:
> A singe patch conversion would look like below. But for that to
> happen, convert.c, rerere, ws.c and read-cache.c have to be converted
> first to not use the_index.
Yes, that was pretty much what I was driving at. I do not have any
trouble seeing a patch that converts
On Tue, Jul 03, 2018 at 12:55:19PM -0400, Jeff King wrote:
> We don't need to use backslash continuation, as the "&&"
> already provides continuation (and happily soaks up empty
> lines between commands).
OK. That seems correct according to my recollection.
> We can also expand the multi-line
Alban Gruin writes:
> The patches about append_todo_help() and edit-todo are not up to date,
> so I’ll resend them in a few minutes
Good.
Michael Haggerty writes:
> So if `N ≫ M`, there is necessarily a lot of repetition among the `N +
> M` lines that the hunk could possibly overlay. Specifically, it must
> consist of `floor((N + M)/M)` identical copies of the hunk, plus
> possibly a few leftover lines constituting the start of
Brandon Williams writes:
> I 100% think that we need to continue these refactorings with both the
> object store as well as with the_index (removing the index macros and
> removing the dependency on global state). The whole compat macros most
> definitely was a failed experiment as we still
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 28 Jun 2018, Junio C Hamano wrote:
>
>> * as/safecrlf-quiet-fix (2018-06-11) 1 commit
>> (merged to 'next' on 2018-06-13 at b163674843)
>> + config.c: fix regression for core.safecrlf false
>>
>> Fix for 2.17-era regression around
Jeff King writes:
>> A small testcase to reproduce looks like this:
>>
>> $ git init bar; cd bar
>> $ git fast-import <> commit refs/heads/bar
>> committer Bar 0 +
>> data 0
>>
>> M 16
Greetings,
We are contracted probate researchers. This is an investigation about a late
client with whom you share the same surname; your assistance will be greatly
appreciated. Are you aware of any investment made by such a person with us?
Please clarify,
EmaiL Reply to :
We don't need to use backslash continuation, as the "&&"
already provides continuation (and happily soaks up empty
lines between commands).
We can also expand the multi-line printf into a
here-document, which lets us use line breaks more naturally
(and avoids another continuation that required us
On Fri, Jun 29 2018, Mike Hommey wrote:
> On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Jun 29 2018, Mike Hommey wrote:
>>
>> > I noticed some slowness when fast-importing data from the Firefox mercurial
>> > repository, where fast-import spends more
Jeff King writes:
> One thing I almost did in the example I gave above was to literally call
> the encoding name by a "real" one. I.e.:
>
> echo '*.txt working-tree-encoding=iso-8859-1' >.gitattributes
> git config encoding.iso-8859-1.replace latin1
>
> or something. But I wondered if it was
On Tue, Jul 03, 2018 at 10:37:29AM -0400, Jeff King wrote:
> On Mon, Jul 02, 2018 at 03:08:54PM -0500, Taylor Blau wrote:
>
> > Attached is the second re-roll of my series to teach 'git grep
> > --only-matching'. Since last time, not much has changed. The change I
> > did include is summarized
On Mon, Jul 02, 2018 at 03:08:54PM -0500, Taylor Blau wrote:
> Attached is the second re-roll of my series to teach 'git grep
> --only-matching'. Since last time, not much has changed. The change I
> did include is summarized below, and an inter-diff is attached as
> always.
>
> - Initialize
On Fri, Jun 29, 2018 at 02:10:59AM +0100, Ramsay Jones wrote:
> On 28/06/18 23:03, Jeff King wrote:
> > On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
> [snip]
> > Yes, it can go in quickly. But I'd prefer not to keep it in the long
> > term if it's literally doing nothing.
>
>
On Tue, Jul 03, 2018 at 04:06:50PM +0900, Mike Hommey wrote:
> I had a first shot at that a few months ago, but the format of the
> metadata branch made it impossible to push to github, hitting its push
> size limit. With some pre-processing work, I was able to push the data
> to github, with the
Recent version of PHP supports interface, trait, abstract class and
final class. This patch fixes the PHP hunk header regexp to support
all of these keywords.
Signed-off-by: Kana Natsuno
---
t/t4018/php-abstract-class | 4
t/t4018/php-final-class| 4
t/t4018/php-interface |
A later patch changes the built-in PHP pattern. These test cases
demonstrate aspects of the pattern that we do not want to change.
Signed-off-by: Kana Natsuno
---
t/t4018/php-class| 4
t/t4018/php-function | 4
t/t4018/php-method | 7 +++
3 files changed, 15 insertions(+)
Recent version of PHP supports interface, trait, abstract class and
final class. This patch fixes the PHP hunk header regexp to support
all of these keywords.
Kana Natsuno (2):
t4018: add missing test cases for PHP
userdiff: support new keywords in PHP hunk header
Hi Junio,
On Thu, 28 Jun 2018, Junio C Hamano wrote:
> * js/branch-diff (2018-05-16) 19 commits
> - fixup! Add a function to solve least-cost assignment problems
> - completion: support branch-diff
> - branch-diff: add a man page
> - branch-diff --dual-color: work around bogus white-space
Add test cases to cover the new X509/gpgsm support. Most of them
resemble existing ones. They just switch the format to X509 and set the
signingkey when creating signatures. Validation of signatures does not
need any configuration of git, it does need gpgsm to be configured to
trust the
Create a struct that holds the format details for the supported formats.
At the moment that is still just "PGP". This commit prepares for the
introduction of more formats, that might use other programs and match
other signatures.
Signed-off-by: Henning Schild
---
gpg-interface.c | 80
Add "gpg.format" where the user can specify which type of signature to
use for commits. At the moment only "PGP" is supported and the value is
not even used. This commit prepares for a new types of signatures.
Signed-off-by: Henning Schild
---
Documentation/config.txt | 4
gpg-interface.c
This commit allows git to create and check X509 type signatures using
gpgsm.
Signed-off-by: Henning Schild
---
Documentation/config.txt | 5 -
gpg-interface.c | 10 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt
gnupg does print the keyid followed by a space and the signer comes
next. The same pattern is also used in gpgsm, but there the key length
would be 40 instead of 16. Instead of hardcoding the expected length,
find the first space and calculate it.
Signed-off-by: Henning Schild
---
Hi Junio,
On Thu, 28 Jun 2018, Junio C Hamano wrote:
> * ag/rebase-i-rewrite-todo (2018-06-15) 3 commits
> - rebase--interactive: rewrite the edit-todo functionality in C
> - editor: add a function to launch the sequence editor
> - Merge branch 'bc/t3430-fixup' into ag/rebase-i-rewrite-todo
>
The combination of verify_signed_buffer followed by parse_gpg_output is
available as check_signature. Use that instead of implementing it again.
Signed-off-by: Henning Schild
---
builtin/receive-pack.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git
This commit turns parse_gpg_output into an internal function, the only
outside user was migrated in an earlier commit.
Signed-off-by: Henning Schild
---
gpg-interface.c | 2 +-
gpg-interface.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/gpg-interface.c
Valid values are already covered by all tests that use GPG, now also
test what happens if we go for an invalid one.
Signed-off-by: Henning Schild
---
t/t7510-signed-commit.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
This series adds support for signing commits with gpgsm.
The first two patches are cleanups of gpg-interface, while the next
four prepare for the introduction of the actual feature in patch 7.
Finally patch 8 extends the testsuite to cover the new feature.
This series can be seen as a follow up
Hi Junio & Aaron,
On Thu, 28 Jun 2018, Junio C Hamano wrote:
> * as/sequencer-customizable-comment-char (2018-06-28) 1 commit
> - sequencer: use configured comment character
>
> Honor core.commentchar when preparing the list of commits to replay
> in "rebase -i".
As per
Hi Junio,
On Thu, 28 Jun 2018, Junio C Hamano wrote:
> * jh/partial-clone (2018-06-12) 1 commit
> (merged to 'next' on 2018-06-13 at 818f864b0c)
> + list-objects: check if filter is NULL before using
>
> The recent addition of "partial clone" experimental feature kicked
> in when it
Hi Junio,
On Thu, 28 Jun 2018, Junio C Hamano wrote:
> * as/safecrlf-quiet-fix (2018-06-11) 1 commit
> (merged to 'next' on 2018-06-13 at b163674843)
> + config.c: fix regression for core.safecrlf false
>
> Fix for 2.17-era regression around `core.safecrlf`.
Is this `maint` material?
From: Johannes Schindelin
This command does not do a whole lot so far, apart from showing a usage
that is oddly similar to that of `git tbdiff`. And for a good reason:
the next commits will turn `range-branch` into a full-blown replacement
for `tbdiff`.
At this point, we ignore tbdiff's color
From: Johannes Schindelin
At this stage, `git range-diff` can determine corresponding commits
of two related commit ranges. This makes use of the recently introduced
implementation of the Hungarian algorithm.
The core of this patch is a straight port of the ideas of tbdiff, the
apparently
From: Johannes Schindelin
When showing what changed between old and new commits, we show a diff of
the patches. This diff is a diff between diffs, therefore there are
nested +/- signs, and it can be relatively hard to understand what is
going on.
With the --dual-color option, the preimage and
From: Johannes Schindelin
When diffing diffs, it can be quite daunting to figure out what the heck
is going on, as there are nested +/- signs.
Let's make this easier by adding a flag in diff_options that allows
color-coding the outer diff sign with inverted colors, so that the
preimage and
The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
what changed between two iterations sent to the Git mailing list) is slightly
less useful for this developer due to the fact that it requires the `hungarian`
and `numpy` Python packages which are for some reason really
From: Johannes Schindelin
The main information in the `range-diff` view comes from the list of
matching and non-matching commits, the diffs are additional information.
Indenting them helps with the reading flow.
Signed-off-by: Johannes Schindelin
---
builtin/range-diff.c | 10 ++
1
From: Johannes Schindelin
This "color" simply reverts background and foreground. It will be used
in the upcoming "dual color" mode of `git range-diff`, where we will
reverse colors for the -/+ markers and the fragment headers of the
"outer" diff.
Signed-off-by: Johannes Schindelin
---
color.h
From: Johannes Schindelin
As pointed out by Elijah Newren, tbdiff has this neat little alignment
trick where it outputs the commit pairs with patch numbers that are
padded to the maximal patch number's width:
1: cafedead = 1: acefade first patch
[...]
314: beefeada <
From: Johannes Schindelin
Arguably the most important part of `git range-diff`'s output is the
list of commits in the two branches, together with their relationships.
For that reason, tbdiff introduced color-coding that is pretty
intuitive, especially for unchanged patches (all dim yellow, like
From: Johannes Schindelin
The bulk of this patch consists of a heavily butchered version of
tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from
https://github.com/trast/tbdiff.
Signed-off-by: Johannes Schindelin
---
Documentation/git-range-diff.txt | 235
From: Johannes Schindelin
Tab completion of `git range-diff` is very convenient, especially
given that the revision arguments to specify the commit ranges to
compare are typically more complex than, say, your grandfather's `git
log` arguments.
Signed-off-by: Johannes Schindelin
squash! WIP
From: Johannes Schindelin
After using this command extensively for the last two months, this
developer came to the conclusion that even if the dual color mode still
leaves a lot of room for confusion what was actually changed, the
non-dual color mode is substantially worse in that regard.
From: Johannes Schindelin
This change brings `git range-diff` yet another step closer to
feature parity with tbdiff: it now shows the oneline, too, and indicates
with `=` when the commits have identical diffs.
Signed-off-by: Johannes Schindelin
---
range-diff.c | 66
From: Johannes Schindelin
We are comparing complete, formatted commit messages with patches. There
are no function names here, so stop looking for them.
Signed-off-by: Johannes Schindelin
---
range-diff.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/range-diff.c b/range-diff.c
From: Johannes Schindelin
When comparing commit messages, we need to keep in mind that they are
indented by four spaces. That is, empty lines are no longer empty, but
have "trailing whitespace". When displaying them in color, that results
in those nagging red lines.
Let's just right-trim the
From: Johannes Schindelin
When showing the diff between corresponding patches of the two branch
versions, we have to make up a fake filename to run the diff machinery.
That filename does not carry any meaningful information, hence tbdiff
suppresses it. So we should, too.
Signed-off-by:
From: Thomas Rast
These are essentially lifted from https://github.com/trast/tbdiff, with
light touch-ups to account for the command now being an option of `git
branch`.
Apart from renaming `tbdiff` to `range-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The
From: Johannes Schindelin
When displaying a diff of diffs, it is possible that there is an outer
`+` before a context line. That happens when the context changed between
old and new commit. When that context line starts with a tab (after the
space that marks it as context line), our diff
From: Johannes Schindelin
Just like tbdiff, we now show the diff between matching patches. This is
a "diff of two diffs", so it can be a bit daunting to read for the
beginner.
An alternative would be to display an interdiff, i.e. the hypothetical
diff which is the result of first reverting the
From: Johannes Schindelin
The problem solved by the code introduced in this commit goes like this:
given two sets of items, and a cost matrix which says how much it
"costs" to assign any given item of the first set to any given item of
the second, assign all items (except when the sets have
From: Johannes Schindelin
This patch lets `git range-diff` use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the `git range-diff` is performed between an older vs a newer
version of the branch. As such, the user is probably more interested
On Mon, Jul 2, 2018 at 7:27 PM Stefan Beller wrote:
> On Sun, Jul 1, 2018 at 8:57 AM Michael Haggerty wrote:
> [...]
> So this suggests to have MAX_BORING to be
> "hunk size + some small constant offset" ?
That would be my suggestion, yes. There are cases where it will be
more expensive than a
Hi,
thanks for the info.
I have read the parts of the code required to create the patch, but I do not
think I really understand
the git-gui code, nor tcl/tk.
This change was requested by some of my colleagues, who are used to git-gui and
would like to
continue using it. I personally prefer
On Mon, Jul 2, 2018 at 11:58 PM Joshua Nelson wrote:
> Signed-off-by: Joshua Nelson
> ---
> diff --git t/t3104-ls-tree-optional-args.sh t/t3104-ls-tree-optional-args.sh
> @@ -0,0 +1,43 @@
> +test_expect_success 'initial setup' '
> +echo hi > test && cp test test2 && git add test test2 && git
Hi Joshua,
On Mon, Jul 2, 2018 at 8:58 PM, Joshua Nelson wrote:
The commit message could use some clarification; it currently makes
the reader think you're testing all arguments of ls-tree, when you're
only testing a few new ones. Alternatively, you could squash this
with patch 1.
>
On Mon, Jul 2, 2018 at 11:58 PM Joshua Nelson wrote:
> show [tree-ish] and [--] as optional
> ---
> diff --git builtin/ls-tree.c builtin/ls-tree.c
> @@ -26,7 +26,7 @@ static int chomp_prefix;
> static const char * const ls_tree_usage[] = {
> - N_("git ls-tree [] [...]"),
> +
1 - 100 of 104 matches
Mail list logo
