Hi Stefan,
On Tue, 14 Aug 2018, Stefan Beller wrote:
> On Tue, Aug 14, 2018 at 11:54 AM Johannes Schindelin
> wrote:
> >
> > On Mon, 13 Aug 2018, Stefan Beller wrote:
> >
> > > > > The later lines that indicate a change to the Makefile will be
> &g
From: Johannes Schindelin
The `chainlint` target compares actual output to expected output, where
the actual output is generated from files that are specifically checked
out with LF-only line endings. So the expected output needs to be
checked out with LF-only line endings, too.
Signed-off
it. Especially when it would break the
build otherwise.
Johannes Schindelin (1):
chainlint: fix for core.autocrlf=true
t/.gitattributes | 1 +
1 file changed, 1 insertion(+)
base-commit: 1d89318c48d233d52f1db230cf622935ac3c69fa
Published-As:
https://github.com/gitgitgadget/git/releases/tags/pr-19
Hi Stefan,
On Mon, 13 Aug 2018, Stefan Beller wrote:
> > > The later lines that indicate a change to the Makefile will be treated as
> > > context both in the outer and inner diff, such that those lines stay
> > > regular color.
> >
> > While I am a fan of having those lines colored correctly, I
diff marker, but instead to refer to the color
> +of the rest of the line. A value of `NULL` indicates that the rest
> +of the line wants to be colored the same as the diff marker.
>
> +Helped-by: Johannes Schindelin
>
he
is the author, I assembled this. Maybe I should move him to the footer, as
an Original-Authored-By:?
Junio?
Ciao,
Dscho
>
> > Signed-off-by: Johannes Schindelin
> > ---
> > t/.gitattributes | 1 +
> > t/t3206-range-diff.sh | 145 ++
> > t/t3
From: Johannes Schindelin
The way the guard was put, the code was declaring an unused variable on
Windows. No need to do that, so let's fix it.
Signed-off-by: Johannes Schindelin
---
entry.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index
: it is based on nd/clone-case-smashing-warning.
Johannes Schindelin (1):
mark_colliding_entries(): fix incorrect #if...#endif guard
entry.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
base-commit: f80218bf4e65ccc06cc9173c0ac5a5520d380f36
Published-As:
https://github.com/gitgitgadget
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> emit_line_0 has no nested conditions, but puts out all its arguments
> (if set) in order.
Well, currently `emit_line_0()` *has* nested conditions: `first == '\n'`
inside `len == 0`.
And these nested conditions make things hard to read, so
Hi,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
Well, my rationale for having the explicit `reverse` parameter is: this
code is complex enough, introducing some magic "this and that implies
this" makes it much harder to understand.
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> All lines that use emit_line_0 multiple times per line, are combined
> into a single call to emit_line_0, making use of the 'set' argument.
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> ---
> diff.c | 26
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> For now just change the signature, we'll reason about the actual
> change in a follow up patch.
>
> Pass 'set_sign' (which is output before the sign) and 'set' which
> controls the color after the first character. Hence, promote any
>
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> The order shall be all colors first, then the content, flags at the end.
Okay.
> The colors are in order.
In order of what? Of the wavelength?
(I agree that the order now makes more sense, and that the diff is
correct.)
Ciao,
Dscho
>
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> Due to the previous condition we know "set_sign != NULL" at that point.
I trust your judgement on that, also on how likely this previous condition
is to keep guaranteeing that assumption.
Thank you,
Dscho
> Signed-off-by: Stefan Beller
>
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> +test_expect_success 'dual-coloring' '
> + sed -e "s|^:||" >expect <<-\EOF &&
> + :1: a4b = 1: f686024 s/5/A/
> + :2: f51d370 ! 2:
> 4ab067d s/4/A/
> + :@@ -2,6 +2,8 @@
That's a neat trick to have an indented
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> The range-diff coloring is a bit fuzzy when it comes to special lines of
> a diff, such as indicating new and old files with +++ and ---, as it
> would pickup the first character and interpret it for its coloring, which
> seems annoying as
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> This change itself only changes the internal communication and should
> have no visible effect to the user. We instruct the diff code that produces
> the inner diffs to use X, Y, Z instead of the usual markers for new, old
> and context
Hi Steafn,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> This will prove useful in range-diff in a later patch as we will be able to
> differentiate between adding a new file (that line is starting with +++
> and then the file name) and regular new lines.
Very good!
> It could also be useful for
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> By providing a string as the first part of the emission we can extend
> it later more easily.
Thank you for working on this!
> While at it, document emit_line_0.
>
> [...]
>
> +/*
> + * Emits
> + * LF
> + * if they are present.
Hi,
On Mon, 13 Aug 2018, Johannes Schindelin via GitGitGadget wrote:
> The incredibly useful git-tbdiff [https://github.com/trast/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 deve
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
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, what is normally passed
to `git log`.
Signed-off-by: Johannes Schindelin
---
contrib
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 | 229
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 about what was actually changed, the
non-dual color mode is substantially worse in that regard
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
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
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
From: Johannes Schindelin
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or
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
This not only uses "dashed stand-ins" for "pairs" where one side is
missing (i.e. unmatched commits that are present only in one of the two
commit ranges), but also adds onelines for the reader's pleasure.
This change brings `git range-diff` yet
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
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
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 linear assignment algorithm.
The core of this patch is a straight port of the ideas of tbdiff
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
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: Joh
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
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
p!
that I almost missed).
* Renamed branch --diff, which had been renamed from branch-diff (which was
picked to avoid re-using tbdiff) to range-diff.
* Renamed hungarian.c and its header to linear-assignment.c
* Made --dual-color the default, and changed it to still auto-detect
whether co
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
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
Hi Thomas,
On Sun, 12 Aug 2018, Thomas Gummerer wrote:
> On 08/10, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > [..]
> >
> > @@ -13,15 +14,38 @@ NULL
> > int cmd_range_diff(int argc, const char **argv, const char *pre
From: Johannes Schindelin
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or
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
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
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 linear assignment algorithm.
The core of this patch is a straight port of the ideas of tbdiff
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
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
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
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: Joh
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 about what was actually changed, the
non-dual color mode is substantially worse in that regard
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, what is normally passed
to `git log`.
Signed-off-by: Johannes Schindelin
---
contrib
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 | 229
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
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
p!
that I almost missed).
* Renamed branch --diff, which had been renamed from branch-diff (which was
picked to avoid re-using tbdiff) to range-diff.
* Renamed hungarian.c and its header to linear-assignment.c
* Made --dual-color the default, and changed it to still auto-detect
whether co
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
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 not only uses "dashed stand-ins" for "pairs" where one side is
missing (i.e. unmatched commits that are present only in one of the two
commit ranges), but also adds onelines for the reader's pleasure.
This change brings `git range-diff` yet
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
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
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
Hi Eric,
On Fri, 10 Aug 2018, Eric Sunshine wrote:
> On Fri, Aug 10, 2018 at 5:12 PM Johannes Schindelin
> wrote:
> > On Mon, 30 Jul 2018, Eric Sunshine wrote:
> > > I think you can attain the desired behavior by making a final
> > > parse_options() call with empty
Hi Junio,
On Fri, 10 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I'll just try to get that option parsing change in that Eric suggested,
> > force-push, then wait for macOS and Linux builds to pass (trusting that
> > Windows will follow suite)
Hi Junio,
On Fri, 10 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +
> > +#ifndef GIT_WINDOWS_NATIVE
> > +int lock_or_unlock_fd_for_appending(int fd, int lock_it)
> > +{
> > + struct flock floc
Hi Stefan,
On Wed, 8 Aug 2018, Stefan Beller wrote:
> On Wed, Aug 8, 2018 at 6:05 AM Johannes Schindelin
> wrote:
>
> > > [...]
> > > > diff --git a/Makefile b/Makefile
> > > > --- a/Makefile
> > > > +++ b/Makefile
Hi Eric,
On Mon, 30 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 30, 2018 at 5:26 PM Thomas Gummerer wrote:
> > On 07/30, Johannes Schindelin wrote:
> > > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> > > > There's one more thing that I noticed here:
>
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > After using this command extensively for the last two months, this
> > developer came to the conclusion that even i
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > Documentation/git-range-diff.txt | 229 +++
> > 1 f
Hi Stefan,
On Mon, 23 Jul 2018, Stefan Beller wrote:
> On Sat, Jul 21, 2018 at 3:05 PM Johannes Schindelin via GitGitGadget
> wrote:
> >
> > From: Johannes Schindelin
> >
> > When displaying a diff of diffs, it is possible that there is an outer
> > `+` befo
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > We are comparing complete, formatted commit messages with patches. There
> > are no function names here, so stop l
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > This change brings `git range-diff` yet another step closer to
> > feature parity with tbdiff: it now shows the
Hi Thomas,
On Mon, 30 Jul 2018, Thomas Gummerer wrote:
> On 07/30, Johannes Schindelin wrote:
> >
> > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> >
> > > On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > > >
> > > > [...]
&
Hi Thomas,
On Mon, 30 Jul 2018, Thomas Gummerer wrote:
> On 07/30, Johannes Schindelin wrote:
> >
> > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> >
> > > On 07/29, Eric Sunshine wrote:
> > > > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer
&
Hi Eric,
On Sun, 22 Jul 2018, Eric Sunshine wrote:
> On Sat, Jul 21, 2018 at 6:05 PM Johannes Schindelin via GitGitGadget
> wrote:
> > Tab completion of `git range-diff` is very convenient, especially
> > given that the revision arguments to specify the commit ran
From: Johannes Schindelin
For some reason, t/t5552-skipping-fetch-negotiator.sh fails particularly
often on Windows due to racy tracing where the `git upload-pack` and the
`git fetch` processes compete for the same file.
We just introduced a remedy that uses fcntl(), but Windows does not have
From: Johannes Schindelin
When multiple processes try to write to the same file, it is not
guaranteed that everything works as expected: those writes can overlap,
and in the worst case even lose messages.
This happens in t/t5552-skipping-fetch-negotiator.sh, where we abuse the
`GIT_TRACE
From: Johannes Schindelin
Recently, t5552 introduced a pattern where two processes try to write to
the same GIT_TRACE file in parallel. This is not safe, as the two
processes fighting over who gets to append to the file can cause garbled
lines and may even result in data loss on Windows (where
From: Johannes Schindelin
This function will be used to make write accesses in trace_write() a bit
safer.
Note: this patch takes a very different approach for cross-platform
support than Git is historically taking: the original approach is to
first implement everything on Linux, using
fighting with Linux).
Johannes Schindelin (4):
Introduce a function to lock/unlock file descriptors when appending
mingw: implement lock_or_unlock_fd_for_appending()
trace: lock the trace file to avoid racy trace_write() calls
trace: verify that locking works
Makefile |
Hi Peff,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
>
> > So unless you are willing to ignore, to willfully keep this breakage,
> > I would suggest not to introduce the ugliness of an overridden
> >
Hi Junio,
On Thu, 9 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > This function will be used to make write accesses in trace_write() a bit
> > safer.
> > ...
&g
ermittently on Windows, however,
> reportedly even overwriting bits of the output file (i.e.,
> O_APPEND does not seem to give us an atomic position+write).
>
> Since the test only cares about the trace output from fetch,
> we can just disable the output from upload-pack. That
> doesn't so
From: Johannes Schindelin
For some reason, t/t5552-skipping-fetch-negotiator.sh fails particularly
often on Windows due to racy tracing where the `git upload-pack` and the
`git fetch` processes compete for the same file.
We just introduced a remedy that uses fcntl(), but Windows does not have
From: Johannes Schindelin
This function will be used to make write accesses in trace_write() a bit
safer.
Note: this patch takes a very different approach for cross-platform
support than Git is historically taking: the original approach is to
first implement everything on Linux, using
From: Johannes Schindelin
When multiple processes try to write to the same file, it is not
guaranteed that everything works as expected: those writes can overlap,
and in the worst case even lose messages.
This happens in t/t5552-skipping-fetch-negotiator.sh, where we abuse the
`GIT_TRACE
should
grow a HAVE_FLOCK = YesWeDo line, still. Reviewers knowledgeable in flock()
semantics: I would be much indebted if you helped me there. Also: is it safe
to call flock() on file descriptors referring not to files, but, say, pipes
or an interactive terminal?
Johannes Schindelin (4
From: Johannes Schindelin
Recently, t5552 introduced a pattern where two processes try to write to
the same GIT_TRACE file in parallel. This is not safe, as the two
processes fighting over who gets to append to the file can cause garbled
lines and may even result in data loss on Windows (where
Hi Phillip,
On Thu, 9 Aug 2018, Phillip Wood wrote:
> On 09/08/18 10:22, Johannes Schindelin wrote:
> >
> > On Mon, 6 Aug 2018, Phillip Wood wrote:
> >
> >> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
> >>>
> &g
Hi Junio,
On Sat, 4 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Thu, 2 Aug 2018, Junio C Hamano wrote:
> >
> >> * pk/rebase-in-c (2018-07-30) 3 commits
> >> - builtin/rebase: support running "git rebase "
&
Hi Eric,
On Tue, 7 Aug 2018, Eric Sunshine wrote:
> On Tue, Aug 7, 2018 at 9:54 AM Andrei Rybak wrote:
> > line-log.[ch] use left-closed, right-open interval logic. Change comment
> > and debug output to square brackets+parentheses notation to help
> > developers avoid off-by-one errors.
> >
the end of the fixup/squash chain, we
continue the loop, delaying the insertion until we know where the
fixup/squash chain ends, if any.
Johannes Schindelin (2):
t3430: demonstrate what -r, --autosquash & --exec should do
rebase --exec: make it work with --rebase-merges
seque
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh b/t
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pic
Hi Phillip,
On Mon, 6 Aug 2018, Phillip Wood wrote:
> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
> >
> > From: Johannes Schindelin
> >
> > The idea of `--exec` is to append an `exec` call after each `pick`.
> >
> > Since the
Hi Duy,
On Wed, 8 Aug 2018, Duy Nguyen wrote:
> On Wed, Aug 8, 2018 at 3:55 PM Pratik Karki wrote:
> >
> > diff --git a/builtin/rebase.c b/builtin/rebase.c
> > index 63634210c0..b2ddfa8dbf 100644
> > --- a/builtin/rebase.c
> > +++ b/builtin/rebase.c
> > @@ -585,7 +602,8 @@ int cmd_rebase(int
Hi Stefan,
On Mon, 23 Jul 2018, Stefan Beller wrote:
> On Sat, Jul 21, 2018 at 3:04 PM Johannes Schindelin via GitGitGadget
> wrote:
>
> > 1: 39272eefc ! 1: f7e70689e linear-assignment: a function to solve
> > least-cost assignment problems
>
From: Johannes Schindelin
The words "save" and "safe" are both very wonderful words, each with
their own set of meanings. Let's not confuse them with one another save
on occasion of a pun.
Signed-off-by: Johannes Schindelin
---
git-compat-util.h | 2 +-
1 file change
I stumbled over the one in git-compat-util.h while working on an unrelated
bug fix, and then got curious whether there are other places where we use
save instead of safe, too. Turns out we do not, but there was another
grammar error where a spurious . interrupted a sentence.
Johannes Schindelin
501 - 600 of 5954 matches
Mail list logo
