Signed-off-by: Elijah Newren
---
bisect.h | 2 ++
pack-objects.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/bisect.h b/bisect.h
index a5d9248a47..34df209351 100644
--- a/bisect.h
+++ b/bisect.h
@@ -1,6 +1,8 @@
#ifndef BISECT_H
#define BISECT_H
+struct commit_list;
+
/*
* F
Signed-off-by: Elijah Newren
---
compat/precompose_utf8.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index a94e7c4342..6f843d3e1a 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -1,4 +1,6 @@
#i
Signed-off-by: Elijah Newren
---
alloc.h | 2 ++
apply.h | 3 +++
archive.h | 4
argv-array.h | 2 ++
attr.h| 1 +
branch.h | 2 ++
bulk-checkin.h| 2 ++
color.h | 2 ++
column.h
'branch_track' feels more closely related to branching, and it is
needed later in branch.h; rather than #include'ing cache.h in branch.h
for this small enum, just move the enum and the external declaration
for git_branch_track to branch.h.
Signed-off-by: Elijah Newren
---
branch.h | 11
Signed-off-by: Elijah Newren
---
urlmatch.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/urlmatch.h b/urlmatch.h
index bb0f4dee8d..dfa1b2b71d 100644
--- a/urlmatch.h
+++ b/urlmatch.h
@@ -1,4 +1,6 @@
#ifndef URL_MATCH_H
+#define URL_MATCH_H
+
#include "string-list.h"
#include
--
2.
Signed-off-by: Elijah Newren
---
xdiff/xdiff.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 2356da5f78..5233550c9e 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -27,6 +27,8 @@
extern "C" {
#endif /* #ifdef __cplusplus */
+#include /* for size
Signed-off-by: Elijah Newren
---
sha1dc/sha1.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/sha1dc/sha1.h b/sha1dc/sha1.h
index 1e4e94be54..e9ca7a83ac 100644
--- a/sha1dc/sha1.h
+++ b/sha1dc/sha1.h
@@ -14,6 +14,7 @@ extern "C" {
#ifndef SHA1DC_NO_STANDARD_INCLUDES
#include
+#include
Since both functions are using the same data type, they should either both
refer to it as void *, or both use the real type (struct alloc_state *).
Opt for the latter.
Signed-off-by: Elijah Newren
---
alloc.c | 2 +-
alloc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/
I was bit yet again by compilation errors when adding a #include of
some header file to some new place, and decided to determine which
header files were missing their own necessary #include's and forward
declarations. This patch series is the result. A few notes:
* Patch 1: This patch is the b
Signed-off-by: Elijah Newren
---
ewah/ewok.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ewah/ewok.h b/ewah/ewok.h
index 84b2a29faa..67a68e291a 100644
--- a/ewah/ewok.h
+++ b/ewah/ewok.h
@@ -19,6 +19,8 @@
#ifndef __EWOK_BITMAP_H__
#define __EWOK_BITMAP_H__
+#include "../git-compat-u
Hi Jonathan and Git developers,
I poked around today and figured out how to reorder the command
listings in the manual page, they are taken from git/command-list.txt
so I just reorder the lines in that file (after disabling sorting in
git/Documentation/cmd-list.perl).
I haven't reordered the whol
On Fri, Aug 10, 2018 at 04:39:14PM -0700, Stefan Beller wrote:
> > IMHO the whole for_each_*_object() interface should go in there (it even
> > has packed_git defined there already!). I think I'd still just as soon
> > do it on top of this series, but it might not be too bad to do as part
> > of a
On Fri, Aug 10, 2018 at 4:33 PM Jeff King wrote:
>
> On Fri, Aug 10, 2018 at 07:31:33PM -0400, Jeff King wrote:
>
> > On Fri, Aug 10, 2018 at 04:27:25PM -0700, Stefan Beller wrote:
> >
> > > > cache.h| 13 -
> > > > packfile.h | 8 ++--
> > > > 2 files changed, 14 insertions(
On Fri, Aug 10, 2018 at 07:31:33PM -0400, Jeff King wrote:
> On Fri, Aug 10, 2018 at 04:27:25PM -0700, Stefan Beller wrote:
>
> > > cache.h| 13 -
> > > packfile.h | 8 ++--
> > > 2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > rubs me the wrong way. ;-)
> >
> >
On Fri, Aug 10, 2018 at 04:27:25PM -0700, Stefan Beller wrote:
> > cache.h| 13 -
> > packfile.h | 8 ++--
> > 2 files changed, 14 insertions(+), 7 deletions(-)
>
> rubs me the wrong way. ;-)
>
> cache.h is such a misnomer of a name, and a kitchen sink
> of a file in the Gi
On Fri, Aug 10, 2018 at 4:09 PM Jeff King wrote:
>
> These flags were split between cache.h and packfile.h,
> because some of the flags apply only to packs. However, they
> share a single numeric namespace, since both are respected
> for the packed variant. Let's make sure they're defined
> togeth
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related
We're not really doing the batch-show operation in these
callbacks, but just collecting the set of objects. That
distinction will become more important in a future patch, so
let's rename them now to avoid cluttering that diff.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 18 +---
The test for --batch-all-objects in t1006 covers a variety
of object storage situations, but one thing it doesn't cover
is that we avoid mentioning duplicate objects. We won't have
any because running "git repack -ad" will have packed them
all and deleted the loose ones.
This does work (because we
We currently iterate over objects within a pack in .idx
order, which uses the object hashes. That means that it
is effectively random with respect to the location of the
object within the pack. If you're going to access the actual
object data, there are two reasons to move linearly through
the pack
We already mention the local/alternate behavior of these
functions, but we can help clarify a few other behaviors:
- there's no need to mention LOCAL_ONLY specifically, since
we already reference the flags by type (and as we add
more flags, we don't want to have to mention each)
- clarify
It's not wrong to pass our flags in an "unsigned", as we
know it will be at least as large as the enum. However,
using the enum in the declaration makes it more obvious
where to find the list of flags.
While we're here, let's also drop the "extern" noise-words
from the declarations, per our moder
These flags were split between cache.h and packfile.h,
because some of the flags apply only to packs. However, they
share a single numeric namespace, since both are respected
for the packed variant. Let's make sure they're defined
together so that nobody accidentally adds a new flag in one
location
This series is meant to replace the RFC discussion in:
https://public-inbox.org/git/20180808231210.242120-1-jonathanta...@google.com/
and
https://public-inbox.org/git/20180808155045.gb1...@sigill.intra.peff.net/
The general idea is that accessing objects in packfile order is way
kinder to t
Changes applied, as suggested by jonathanta...@google.com:
- Re-ordered patches so 3-5 actually come first
- Sadly, as a result of the above, many of the tests in the "treat
missing trees like missing blobs" patch had to be moved to the filter
implementation patch, since it doesn't seem possibl
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by: Matthew
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. A missing tree
will cause an error if --missing indicates an error should be caused,
and the hash is printed even if the tree is missing.
In list-objects.c we no longer pri
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 158 +++--
1 file changed, 74 insertions(+), 84 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index c99c47ac1.
Teach list-objects the "tree:none" filter which allows for filtering
out all tree and blob objects (unless other objects are explicitly
specified by the user). The purpose of this patch is to allow smaller
partial clones.
The name of this filter - tree:none - does not explicitly specify that
it al
Currently, list-objects.c incorrectly treats all root trees of commits
as USER_GIVEN. Also, it would be easier to mark objects that are
non-user-given instead of user-given, since the places in the code
where we access an object through a reference are more obvious than
the places where we access a
On Thu, Aug 09, 2018 at 03:03:24PM -0700, Jonathan Tan wrote:
> On Wed, Aug 8, 2018 at 4:25 PM, Jeff King wrote:
> > Even if you just use the oid to do a separate lookup in the object
> > database, there's still a benefit in accessing the objects in pack
> > order.
>
> You're probably right, but
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 in regular diffs, these lines are colored bold via
DIFF_METAINFO.
This improves colors of the range-diff, see last patch for details.
This is a partial resend of
https://public-inbox.org/git/20180804015317.182683-1-sbel...@google.com/
and is also available via
git fetch https://github.com/stefanbeller/git sb/range-diff-better-colors
It applies on the (just r
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.
It could also be useful for experimentation in new patch formats, i.e.
we could teach git to emit moved
By providing a string as the first part of the emission we can extend
it later more easily.
While at it, document emit_line_0.
Signed-off-by: Stefan Beller
---
diff.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/diff.c b/diff.c
index af9316c
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 lines
Signed-off-by: Stefan Beller
---
range-diff.c | 15
emit_line_0 has no nested conditions, but puts out all its arguments
(if set) in order. There is still a slight confusion with set
and set_sign, but let's defer that to a later patch.
'first' used be output always no matter if it was 0, but that got lost
at "diff: add an internal option to dual-co
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index 01095a59d3d..e50cd312755 100644
--- a/diff.c
+++ b/diff.c
@@ -622,11 +622,12 @@ static void check_blank_at_eof(mmfile_t
The 'expect'ed outcome has been taken by running the 'range-diff | decode'.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/t3206-range-diff.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-dif
Due to the previous condition we know "set_sign != NULL" at that point.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index ae131495216..f6df18af913 100644
--- a/diff.c
+++ b/diff.c
@@
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/test-lib-functions.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 2b2181dca09..be8244c47b5 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -42,
The order shall be all colors first, then the content, flags at the end.
The colors are in order.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index f6df18af913..ab6e6a88a56
This is also avaliable as
git fetch https://github.com/stefanbeller/git sb/range-diff-colors
and is a resend of sb/range-diff-colors.
It is rebased on the version of range-diff that Johannes just sent out
(pr-1/dscho/branch-diff-v5 in GGG repo), and squashes the fisup commit
(which had to be adap
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
'set's to 'set_sign' as we want to have color before the sign
for now.
S
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 --
1 file changed, 12 insertions(+), 14 deletions(-)
dif
As a user I wondered what the diff algorithms are about. Offer at least
a basic explanation on the differences of the diff algorithms.
Signed-off-by: Stefan Beller
---
Not sure if this is finished, I just want to put out the state that I
have sitting on my disk.
Documentation/diff-options.tx
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 whether the new diff do
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 th
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, the
apparentl
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 lin
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 posti
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: Johannes Schindelin
---
color.h
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/compl
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 machiner
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 o
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 developer due to
the fact that it requires the hungarian and numpy Python packages which ar
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
ind
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 fil
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 another step closer to
f
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: Johannes
From: Thomas Rast
These are essentially lifted from https://github.com/trast/tbdiff, with
light touch-ups to account for the command now being named `git
range-diff`.
Apart from renaming `tbdiff` to `range-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The underlying r
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 op
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 diffe
On 08/10, Stefan Beller wrote:
> > > + cfg_file = xstrfmt("%s/config", subrepo.gitdir);
> >
> > As I mentioned here:
> > https://public-inbox.org/git/20180807230637.247200-1-bmw...@google.com/T/#t
> >
> > This lines should probably be more like:
> >
> > cfg_file = repo_git_path(&subre
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 'options' list after the call
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) and hit /submit.
>
> OK.
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote:
> Steps to reproduce:
>
> 1. Create a new file.
> 2. Stage the file.
> 3. Add the file to .gitignore.
> 4. Stage the .gitignore.
> 5. Commit changes.
>
> I imagined that the file would now be removed from the stage (because
> it
> > + cfg_file = xstrfmt("%s/config", subrepo.gitdir);
>
> As I mentioned here:
> https://public-inbox.org/git/20180807230637.247200-1-bmw...@google.com/T/#t
>
> This lines should probably be more like:
>
> cfg_file = repo_git_path(&subrepo, "config");
>
Why? You did not mention the
On 08/03, Stefan Beller wrote:
> e98317508c0 (submodule: ensure core.worktree is set after update,
> 2018-06-18) was overly aggressive in calling connect_work_tree_and_git_dir
> as that ensures both the 'core.worktree' configuration is set as well as
> setting up correct gitlink file pointing at th
On 08/10, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Introduce a helper function "submodule_name_to_gitdir()" (and the
> > submodule--helper subcommand "gitdir") which constructs a path to a
> > submodule's gitdir, located in the provided repository's "modules"
> > directory.
> >
> >
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 'options' list after the call to
> > diff_setup_done(). It's pretty much a one-line fix, but
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) and hit /submit.
OK. Obviously receiving, applying and inspecting that result will
not be
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 flock;
> > +
> > + flock.l_type = lock_it ? F_WRLCK : F_UNL
Brandon Williams writes:
> Introduce a helper function "submodule_name_to_gitdir()" (and the
> submodule--helper subcommand "gitdir") which constructs a path to a
> submodule's gitdir, located in the provided repository's "modules"
> directory.
>
> This consolidates the logic needed to build up a
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
> > >
> > > The line starting with --- is red (default removed
Le 10/08/2018 à 22:27, Junio C Hamano a écrit :
> If we are planning to make all the backend responsible for stashing
> away before they run and applying the stash after they are done,
> then it might make sense to have the application side on the backend
> as the first step. But if what you need
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:
> > > >
> > > > git range-diff --no-patch
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 if the dual color mode still
> >
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 file changed, 229 insertions(+)
> >
> > [...]
> >
> > +CONFIGURATI
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
> > `+` before a context line. That happens when
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 looking for them.
>
> While ther
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 oneline, too, and indicates
> > wi
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:
> > > >
> > > > [...]
> > > >
> > > > +static void find_exact_matches(struct string
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
> > > > wrote:
> > > > > On 07/21, Johannes Schind
Alban Gruin writes:
>> Hmph. It is easy enough to do the clean-up ourselves in this code,
>> instead of asking the caller to do so. On the other hand, stashing
>> of local changes is done by the caller, so it feels a bit strange
>> way to divide the labor between the two parts.
>>
>> Other tha
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 ranges to
> > compare are typicall
"Johannes Schindelin via GitGitGadget"
writes:
> +
> +#ifndef GIT_WINDOWS_NATIVE
> +int lock_or_unlock_fd_for_appending(int fd, int lock_it)
> +{
> + struct flock flock;
> +
> + flock.l_type = lock_it ? F_WRLCK : F_UNLCK;
> +
> + /* (un-)lock the whole file */
> + flock.l_whence =
On Fri, Aug 10, 2018 at 9:40 PM Elijah Newren wrote:
>
> On Fri, Aug 10, 2018 at 12:30 PM Duy Nguyen wrote:
> > On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
> ...
> > > Why do we still need to go through add_index_entry()? I thought that
> > > the whole point was that you already checke
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
fc
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` facili
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 bu
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 the functi
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows than elsewhere. (And even if it is apparently
impossible to trigger on L
On Fri, Aug 10, 2018 at 12:30 PM Duy Nguyen wrote:
> On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
...
> > Why do we still need to go through add_index_entry()? I thought that
> > the whole point was that you already checked that at the current path,
> > the trees being unpacked were all
Hi Junio,
Le 10/08/2018 à 21:25, Junio C Hamano a écrit :
> Alban Gruin writes:
>
>> This rewrites complete_action() from shell to C.
>>
>> A new mode is added to rebase--helper (`--complete-action`), as well as
>> a new flag (`--autosquash`).
>>
>> Finally, complete_action() is stripped from gi
1 - 100 of 158 matches
Mail list logo