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.
> > ...
> > To set a precedent for a better approach, let's
On Fri, Aug 10, 2018 at 9:29 AM Duy Nguyen wrote:
> On Wed, Aug 8, 2018 at 8:23 PM Elijah Newren wrote:
> > > +* cache-tree would be invalidated and we would never get here
> > > +* in the first place.
> > > +*/
> > > + for (i = 0; i < nr_entries; i++) {
> > > +
> Matthew DeVore (5):
> revision: invert meaning of the USER_GIVEN flag
> list-objects-filter: implement filter only:commits
> list-objects: store common func args in struct
> list-objects: refactor to process_tree_contents
> rev-list: handle missing tree objects properly
Firstly, run
Hi Philip
Thanks for CC'ing me Peff.
On 10/08/18 19:27, Jeff King wrote:
On Thu, Aug 09, 2018 at 08:17:36PM -0700, Philip White wrote:
I’d like to report what I suspect is a bug in Git, tested in 2.18 and
2.14. (I’d be delighted to be corrected if it is my own
misunderstanding.) I’m
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
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
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
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`
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
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(,
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.
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
---
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
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
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
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
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
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 another step closer to
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 named `git
range-diff`.
Apart from renaming `tbdiff` to `range-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The underlying
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
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
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
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
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
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
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
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
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
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
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
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)
-
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
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. ;-)
> >
> >
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
Nguyễn Thái Ngọc Duy writes:
> +static void mark_duplicate_entries(const struct checkout *state,
> +struct cache_entry *ce, struct stat *st)
> +{
> + int i;
> + int *count = state->nr_duplicates;
> +
> + if (!count)
> +
Hi,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > > which means every write() will be atomically positioned at the end of
>
This rewrites init_basic_state() from shell to C. The call to
write_basic_state() in cmd_rebase__helper() is replaced by a call to the
new function.
The shell version is then stripped from git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
No changes since v5.
This rewrites the part of interactive rebase which initializes the
basic state, make the script and complete the action, as a buitin, named
git-rebase--interactive2 for now. Others modes (`--continue`,
`--edit-todo`, etc.) will be rewritten in the next commit.
git-rebase--interactive.sh is
This rewrites the part of init_revisions_and_shortrevisions() needed by
`--make-script` from shell to C. The new version is called
get_revision_ranges(), and is a static function inside of
rebase--helper.c. As this does not initialize $shortrevision, the
original shell version is not yet
This removes the modes `--skip-unnecessary-picks`, `--append-todo-help`,
and `--checkout-onto` from rebase--helper.c, the functions of
git-rebase--interactive.sh that were rendered useless by the rewrite of
complete_action(), and append_todo_help_to_file() from
rebase-interactive.c.
This rewrites the submodes of interactive rebase (`--continue`,
`--skip`, `--edit-todo`, and `--show-current-patch`) in C.
git-rebase.sh is then modified to call directly git-rebase--interactive2
instead of git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
No changes since v5.
This rewrites write_basic_state() from git-rebase.sh in C. This is the
first step in the conversion of init_basic_state(), hence the mode in
rebase--helper.c is called INIT_BASIC_STATE. init_basic_state() will be
converted in the next commit.
The part of read_strategy_opts() that parses the
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
> Abandon the previous approach of mutating all new objects implicitly in
> add_pending_object by inverting the meaning of the bit (it is now
> NOT_USER_GIVEN) and only setting the flag when we need to.
>
> This more accurately tracks if a tree was provided directly by the user.
> Without this
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
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(+)
> >
> > [...]
> >
> >
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
>
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
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 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
>
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
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
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
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.
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
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
@@
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(-)
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
On Fri, Aug 10, 2018 at 11:34:59AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > As this buglet looks like a recurring theme, and a proper fix is
> > preferable over repeated work-arounds. To me it looks like we need
> > some sort of locking on Windows. Unless your friends at
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
> > upload-pack for the sole
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
"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
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
On Fri, Aug 10, 2018 at 9:39 AM Duy Nguyen wrote:
>
> On Wed, Aug 8, 2018 at 8:46 PM Elijah Newren wrote:
> > > @@ -701,6 +702,24 @@ static int traverse_by_cache_tree(int pos, int
> > > nr_entries, int nr_names,
> > If we're going to go this route, I think we should first check that
> > o->fn
Jeff King writes:
> I have tried to help with the actual problem, by identifying the root
> cause (that the trace code's strategy is not fundamentally broken, but
> that it relies on O_APPEND whose guarantees are obviously not portable
> to Windows) and exploring possible solutions there
On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
>
> On Fri, Aug 10, 2018 at 9:39 AM Duy Nguyen wrote:
> >
> > On Wed, Aug 8, 2018 at 8:46 PM Elijah Newren wrote:
> > > > @@ -701,6 +702,24 @@ static int traverse_by_cache_tree(int pos, int
> > > > nr_entries, int nr_names,
>
> > > If we're
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
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
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
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
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:
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
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
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
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
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 :
> > + 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(, "config");
>
Why? You did not mention the
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.
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
>
Johannes Sixt writes:
> As this buglet looks like a recurring theme, and a proper fix is
> preferable over repeated work-arounds. To me it looks like we need
> some sort of locking on Windows. Unless your friends at Microsoft have
> an ace in their sleeves that lets us have atomic O_APPEND the
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 git-rebase--interactive.sh.
>
> The original complete_action() would
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
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
> >
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
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
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
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
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
On Fri, Aug 10, 2018 at 07:04:08PM +0100, Paul Jolly wrote:
> I've tried to skim through the archive, but I couldn't find anything
> that describes what I'm seeing. Apologies if that's because I missed
> something/used the wrong search terms, or this is an intentional
> change in behaviour.
>
>
There are lots of suggestions on optimizing this stuff, but since this
problem does not affect me to begin with, I'm reluctant to make more
changes and going to stay simple, stupid and slow. I could continue to
do small updates if needed. But for bigger changes, consider this
patch dropped by me.
1 - 100 of 158 matches
Mail list logo
