Junio C Hamano wrote:
> Well, having said all that, I do not think I personally mind if
> ./configure learned to include a "compile small program and run it
> to determine byte order on the build machine" as part of "we make a
> reasonable effort" as long as it cleanly excludes cross building
>
On Wed, Aug 1, 2018 at 1:39 AM Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>
> > While 3secs timeout seems plenty, and indeed is sufficient in most
> > cases, on rare occasions it's just not quite enough: I saw this test
> > fail in Travis CI build jobs two, maybe three times because 'git
> >
Hi Eric,
On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine wrote:
> This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> object corruption when "rebase -i --root" swaps in a new commit as root.
> Unfortunately, those bugs made it into v2.18.0 and have already
> corrupted at
On Wed, Aug 01, 2018 at 12:19:42AM +, brian m. carlson wrote:
> On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> > Hello,
> >
> > me and my colleague are struggling with automation of verifying git
> > repositories and we have encountered that git verify-commit and
> >
Am 31.07.2018 um 17:50 schrieb Jeff King:
> On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
>
>> Bisecting around, this might be the commit that introduced the breakage.
>>
>> https://github.com/git/git/commit/d8febde
>>
>> I really hope that it hasn't been broken for 5 years and
Am 31.07.2018 um 23:06 schrieb Junio C Hamano:
> Jeff King writes:
>
>> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>> ...
>> So here it is fixed, and with a commit message. I'm not happy to omit a
>> regression test, but I actually couldn't come up with a minimal one that
>>
Jonathan Tan writes:
> This looks good to me. I've checked that refname_match (and
> branch_merge_matches(), which returns the result of refname_match()
> directly) is only used in "if" contexts, so making it return a value
> other than 1 is fine.
Yes, the log message should say that existing
On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> Hello,
>
> me and my colleague are struggling with automation of verifying git
> repositories and we have encountered that git verify-commit and
> verify-tag accepts untrusted signatures and exit successfully.
I don't have
Hi Junio,
During recent development, I found out that `v5` has some issues and shouldn't
be merged into `next`. I implemented more options and ran a couple of regression
tests from which I figured out that certain choices I made in those commits
need to be reconsidered.
During recent
Hi,
SZEDER Gábor wrote:
> While 3secs timeout seems plenty, and indeed is sufficient in most
> cases, on rare occasions it's just not quite enough: I saw this test
> fail in Travis CI build jobs two, maybe three times because 'git
> update-ref' timed out.
I suspect these tests will fail with
> That is, something like this, perhaps. The resulting behaviour
> should match how "git rev-parse X" would give precedence to tag X
> over branch X by going this route. What do you think?
[snip]
> static const struct ref *find_ref_by_name_abbrev(const struct ref *refs,
> const char *name)
>
The test 'no bogus intermediate values during delete' in
't1404-update-ref-errors.sh', added in 6a2a7736d8 (t1404: demonstrate
two problems with reference transactions, 2017-09-08), tries to catch
undesirable side effects of deleting a ref, both loose and packed, in
a transaction. To do so it is
> What leaves me even more confused is that the entire log message
> does not make it clear what the end-user observable problem the
> patch is trying to solve.
>
> Is this "we sometimes follow and sometimes fail to follow refs while
> fetching"? Does it affect all protocol versions and
> On Mon, Jul 30, 2018 at 03:56:01PM -0700, Jonathan Tan wrote:
>
> > Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
> > 2018-06-28) allows transports to report the refs that they have fetched
> > in a new out-parameter "fetched_refs". If they do so,
> >
The trash directory of a failed test might contain invaluable
information about the cause of the failure, but we have no access to
the trash directories of Travis CI build jobs. The only feedback we
get from there is the build job's trace log, so...
Modify 'ci/print-test-failures.sh' to create a
Junio C Hamano writes:
> In order to resolve this correctly with the precedence rules, I
> think you need to make refname_match() return the precedence number
> (e.g. give 1 to "%.*s", 2 to "refs/%.*s", etc., using the index in
> ref_rev_parse_rules[] array), and make this loop keep track of the
Jonathan Tan writes:
> When matching a non-wildcard LHS of a refspec against a list of refs,
> find_ref_by_name_abbrev() returns the first ref that matches using the
> DWIM rules used by refname_match() in refs.c, even if an exact match
> occurs later in the list of refs.
When you have
On Tue, Jul 31, 2018 at 7:15 AM Phillip Wood wrote:
> Single quotes should be escaped as \' not \\'. Note that this only
> affects authors that contain a single quote and then only external
> scripts that read the author script and users whose git is upgraded from
> the shell version of rebase -i
Jeff King writes:
> On Mon, Jul 30, 2018 at 03:56:01PM -0700, Jonathan Tan wrote:
>
>> Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
>> 2018-06-28) allows transports to report the refs that they have fetched
>> in a new out-parameter "fetched_refs". If they do so,
>>
Hi,
Jonathan Tan wrote:
> When matching a non-wildcard LHS of a refspec against a list of refs,
> find_ref_by_name_abbrev() returns the first ref that matches using the
> DWIM rules used by refname_match() in refs.c, even if an exact match
> occurs later in the list of refs.
>
> This causes
When matching a non-wildcard LHS of a refspec against a list of refs,
find_ref_by_name_abbrev() returns the first ref that matches using the
DWIM rules used by refname_match() in refs.c, even if an exact match
occurs later in the list of refs.
This causes unexpected behavior when (for example)
Jeff King writes:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> ...
> So here it is fixed, and with a commit message. I'm not happy to omit a
> regression test, but I actually couldn't come up with a minimal one that
> tickled the problem, because we're playing around with
Jeff King writes:
>> Presumably we are already in an error codepath, so if it is
>> absolutely necessary, then we can issue a lstat() to grab the inum
>> for the path we are about to create, iterate over the previously
>> checked out paths issuing lstat() and see which one yields the same
>>
Stefan Beller writes:
> The 'expect'ed outcome has been taken by running the 'range-diff | decode'.
>
> Signed-off-by: Stefan Beller
> ---
> t/t3206-range-diff.sh | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/t/t3206-range-diff.sh
On Tue, Jul 31, 2018 at 7:15 AM Phillip Wood wrote:
> The calling code treated NULL as a valid return value, so fix this by
> returning and integer and passing in a parameter to receive the author.
It might be difficult for future readers (those who didn't follow the
discussion) to understand
On Tue, Jul 31, 2018 at 03:52:26PM -0400, George Shammas wrote:
> This is the fastest I ever seen an open source project respond to an issue
> I reported. Thanks for being awesome!
You're welcome. My speed is an inverse to how embarrassingly long we
carried the bug for. ;)
> > Signed-off-by:
On Tue, Jul 31, 2018 at 01:12:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> > ...
> >> collapses two (or more) paths if we go that way. We only need to
> >> report "we tried to check out X but it seems your
On Tue, Jul 31, 2018 at 1:37 PM Han-Wen Nienhuys wrote:
> Highlight keywords in remote sideband output.
Prefix with the module you're touching, don't capitalize, and drop the
period. Perhaps:
sideband: highlight keywords in remote sideband output
> The highlighting is done on the
Stefan Beller writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
>
> $ git init test && cd test
> $ git config foo."Bar".key test
> $ git config foo."bar".key test
> $ tail -n 3 .git/config
>
Hello,
me and my colleague are struggling with automation of verifying git
repositories and we have encountered that git verify-commit and
verify-tag accepts untrusted signatures and exit successfully.
We have done some investigation of the GPG verification changes in git
repository which I
Jeff King writes:
> On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> ...
>> collapses two (or more) paths if we go that way. We only need to
>> report "we tried to check out X but it seems your filesystem equates
>> something else that is also in the project to X".
>
> Heh. See
On 31/07/2018 16:25, Ævar Arnfjörð Bjarmason wrote:
...the real trick is using these macros outside of GCC / glibc and on
older GCC versions. See the github link above, you basically end up with
a whitelist of how it looks on different systems / compilers. Sometimes
both are defined, sometimes
Ben Peart writes:
> The biggest change in this version was suggested in feedback to the last
> patch. I have turned on the optimzation by default if sparse-checkout is
> not on so that most users do not have to set anything and they will get the
> benefit of the optimization.
Sounds like a
I have a Businesss Proposal for you, Can you do it? If yes please get back to
me for more details.
On 31 July 2018 at 16:40, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> I think there is an error in the test harness.
>>
>> On 31 July 2018 at 10:46, SZEDER Gábor wrote:
+ test_must_fail git-p4 submit --dry-run >errs 2>&1 &&>
+ ! grep "Would apply" err
>>
This is the fastest I ever seen an open source project respond to an issue
I reported. Thanks for being awesome!
On Tue, Jul 31, 2018 at 3:05 PM Jeff King wrote:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>
> > On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
>
Han-Wen Nienhuys writes:
> The highlighting is done on the client-side. Supported keywords are
> "error", "warning", "hint" and "success".
>
> The colorization is controlled with the config setting "color.remote".
>
> Co-authored-by: Duy Nguyen
> Signed-off-by: Han-Wen Nienhuys
Thanks. I'll
On 7/29/2018 5:28 AM, Jeff King wrote:
On Sun, Jul 29, 2018 at 07:26:41AM +0200, Duy Nguyen wrote:
strcasecmp() will only catch a subset of the cases. We really need to
follow the same folding rules that the filesystem would.
True. But that's how we handle case insensitivity internally.
On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > Is it worth attempting to also warn about paths that only differ in
> > UTF-normalization on relevant MacOS systems?
>
> I hate to bring up a totally different approach this late in the
> party, but I
Alban Gruin writes:
> This patch series rewrite the interactive rebase from shell to C.
Thanks.
> It is based on ffc6fa0e39 ("Fourth batch for 2.19 cycle", 2018-07-24).
> The v4 was based on b7bd9486 ("Third batch for 2.19 cycle", 2018-07-18).
> I wanted to make sure my series works well with
On Mon, Jul 30, 2018 at 03:56:01PM -0700, Jonathan Tan wrote:
> Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
> 2018-06-28) allows transports to report the refs that they have fetched
> in a new out-parameter "fetched_refs". If they do so,
> transport_fetch_refs() makes
Elijah Newren writes:
> Is it worth attempting to also warn about paths that only differ in
> UTF-normalization on relevant MacOS systems?
I hate to bring up a totally different approach this late in the
party, but I wonder if it makes more sense to take advantage of
"clone" being a command
Nguyễn Thái Ngọc Duy writes:
> Another thing we probably should do is catch in "git checkout" too,
> not just "git clone" since your linux/unix colleage colleague may
> accidentally add some files that your mac/windows machine is not very
> happy with.
Then you would catch it not in checkout
On Tue, Jul 31, 2018 at 02:55:51PM -0400, Eric Sunshine wrote:
> > I hesitate to make any suggestion here, as I think we may have passed
> > a point of useful cost/benefit in sinking more time into this script.
> > But...is switching to awk or perl an option? Our test suite already
> > depends on
On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > +...
> > > + } else if (cmp > 0) {
> > > /* path2 does not appear in one */
> > > + score +=
On Tue, Jul 31, 2018 at 8:50 AM Jeff King wrote:
> On Mon, Jul 30, 2018 at 05:38:06PM -0400, Eric Sunshine wrote:
> > I considered that, but it doesn't handle nested here-docs, which we
> > actually have in the test suite. For instance, from t9300-fast-import:
> > [...]
> > Nesting could be
On Mon, Jul 30, 2018 at 8:27 AM, Nguyễn Thái Ngọc Duy wrote:
> Paths that only differ in case work fine in a case-sensitive
> filesystems, but if those repos are cloned in a case-insensitive one,
> you'll get problems. The first thing to notice is "git status" will
> never be clean with no
On Mon, Jul 30, 2018 at 05:27:55PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Paths that only differ in case work fine in a case-sensitive
> filesystems, but if those repos are cloned in a case-insensitive one,
> you'll get problems. The first thing to notice is "git status" will
> never be clean with
Elijah Newren writes:
> Should git notes show up in a range-diff? I happened to have
> notes.displayref=refs/notes/amlog
> set in my git.git repo, and saw the below in my range-diff:
>
> On Tue, Jul 31, 2018 at 10:12 AM, Elijah Newren wrote:
>> 1: 4a1c9c3368 ! 1: 00f94a8b41 t1015:
Ævar Arnfjörð Bjarmason writes:
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 97d3217df9..5b624caf58 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -49,11 +49,16 @@ endif::git-pull[]
>
> -f::
> --force::
> > +fetch.negotiationAlgorithm::
> > + Control how information about the commits in the local repository is
> > + sent when negotiating the contents of the packfile to be sent by the
> > + server. Set to "skipping" to use an algorithm that skips commits in an
> > + effort to converge
This moves the rebase--helper modes still used by
git-rebase--preserve-merges.sh (`--shorten-ids`, `--expand-ids`,
`--check-todo-list`, `--rearrange-squash` and `--add-exec-commands`) to
rebase--interactive.c.
git-rebase--preserve-merges.sh is modified accordingly, and
rebase--helper.c is removed
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 rewrites the part of init_revisions_and_shortrevisions() needed by
`--complete-action` (which initialize $shortrevisions) from shell to C.
When `upstream` is empty, it means that the user launched a `rebase
--root`, and `onto` contains the ID of an empty commit. As a range
between an empty
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 v4.
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 v4.
This removes git-rebase--interactive.sh, as its functionnality has been
replaced by git-rebase--interactive2.
git-rebase--interactive2.c is then renamed to git-rebase--interactive.c.
Signed-off-by: Alban Gruin
---
No changes since v4.
.gitignore| 1 -
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 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
This refactors append_todo_help() to write its message to a buffer
instead of the todo-list. This is needed for the rewrite of
complete_action(), which will come after the next commit.
As rebase--helper still needs the file manipulation part of
append_todo_help(), it is extracted to a temporary
If the todo list generated by `--make-script` is empty,
complete_action() writes a noop, but if it has only commented-out
commands, it will abort with the message "Nothing to do", and does not
launch the editor. This adds a new test to ensure that
complete_action() behaves this way.
This rewrites checkout_onto() from shell to C.
A new command (“checkout-onto”) is added to rebase--helper.c. The shell
version is then stripped.
Signed-off-by: Alban Gruin
---
No changes since v4.
builtin/rebase--helper.c | 7 ++-
git-rebase--interactive.sh | 25
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 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 return the code 2 when the todo
list
Instead of skip_unnecessary_picks() printing its result to stdout, it
returns it into a struct object_id, as the rewrite of complete_action()
(to come in the next commit) will need it.
rebase--helper then is modified to fit this change.
Signed-off-by: Alban Gruin
---
No changes since v4.
This makes rebase_path_todo(), get_missing_commit_check_level() and the
enum check_level accessible outside sequencer.c, renames check_level to
missing_commit_check_level, and prefixes its value names by
MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum will eventually be
This adds a new function, run_command_silent_on_success(), to
redirect the stdout and stderr of a command to a strbuf, and then to run
that command. This strbuf is printed only if the command fails. It is
functionnaly similar to output() from git-rebase.sh.
run_git_commit() is then refactored to
This patch series rewrite the interactive rebase from shell to C.
It is based on ffc6fa0e39 ("Fourth batch for 2.19 cycle", 2018-07-24).
The v4 was based on b7bd9486 ("Third batch for 2.19 cycle", 2018-07-18).
I wanted to make sure my series works well with 'bb/pedantic',
'jk/empty-pick-fix', and
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
This also introduces the source file rebase-interactive.c. This file
will contain functions necessary for interactive rebase
This rewrites (the misnamed) setup_reflog_action() from shell to C. The
new version is called prepare_branch_to_be_rebased().
A new command is added to rebase--helper.c, “checkout-base”, as well as
a new flag, “verbose”, to avoid silencing the output of the checkout
operation called by
This rewrites the edit-todo functionality from shell to C.
To achieve that, a new command mode, `edit-todo`, is added, and the
`write-edit-todo` flag is removed, as the shell script does not need to
write the edit todo help message to the todo list anymore.
The shell version is then stripped in
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(), which takes
the editor as a
Ævar Arnfjörð Bjarmason writes:
> The test suite only incidentally (and unintentionally) tested for the
> current behavior of eager tag clobbering on "fetch". This follow-up to
> the previous "push tests: assert re-pushing annotated tags" change
> tests for it explicitly.
>
> Signed-off-by:
On Wed, Jul 18, 2018 at 8:22 AM, Derrick Stolee wrote:
> The following test fails because the repo has ambiguous merge-bases, and
> the commit-graph changes the walk order so we select a different one.
> This alters the resulting merge from the expected result.
>
> t6024-recursive-merge.sh, Test
Ævar Arnfjörð Bjarmason writes:
> The is often the name of the branch you would want to push, but
> -it can be any arbitrary "SHA-1 expression", such as `master~4` or
> -`HEAD` (see linkgit:gitrevisions[7]).
> +it can be any arbitrary expression to a commit, such as `master~4` or
> +`HEAD`
The highlighting is done on the client-side. Supported keywords are
"error", "warning", "hint" and "success".
The colorization is controlled with the config setting "color.remote".
Co-authored-by: Duy Nguyen
Signed-off-by: Han-Wen Nienhuys
---
Documentation/config.txt| 9 +++
---
config.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/config.h b/config.h
index b95bb7649..d39256eb1 100644
--- a/config.h
+++ b/config.h
@@ -178,10 +178,16 @@ struct config_set {
};
extern void git_configset_init(struct config_set *cs);
-extern int
squash in Duy's patch
Han-Wen Nienhuys (2):
Document git config getter return value.
Highlight keywords in remote sideband output.
Documentation/config.txt| 9 +++
config.h| 10 ++-
help.c | 1 +
help.h
On 7/31/2018 12:50 PM, Ben Peart wrote:
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
In the performance game of whack-a-mole, that call to repair cache-tree
is now looking quite expensive...
Yeah and I think we can whack that mole too. I did some measurement.
Best case possible, we just
Junio C Hamano writes:
> As the number of his or her own topics each contributor needs to
> keep track of by definition is the number of all topics I need to
s/is the/is smaller than the/;
Sorry for the noise X-<.
> take care of, I do not want to have to keep track of things myself
> more
On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +...
> > + } else if (cmp > 0) {
> > /* path2 does not appear in one */
> > + score += score_missing(two.entry.mode, two.entry.path);
> > +
Should git notes show up in a range-diff? I happened to have
notes.displayref=refs/notes/amlog
set in my git.git repo, and saw the below in my range-diff:
On Tue, Jul 31, 2018 at 10:12 AM, Elijah Newren wrote:
> 1: 4a1c9c3368 ! 1: 00f94a8b41 t1015: demonstrate directory/file conflict
>
Jeff King writes:
> +...
> + } else if (cmp > 0) {
> /* path2 does not appear in one */
> + score += score_missing(two.entry.mode, two.entry.path);
> + update_tree_entry();
> + continue;
> +
read_index_unmerged() has two intended purposes:
* return 1 if there are any unmerged entries, 0 otherwise
* drops any higher-stage entries down to stage #0
There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that
This patch series fixes several "recovery" commands that outright fail
or do not fully recover when directory-file conflicts are present.
This includes:
* git read-tree --reset HEAD
* git am --skip
* git am --abort
* git merge --abort (or git reset --merge)
* git reset --hard
Several "recovery" commands outright fail or do not fully recover
when directory-file conflicts are present. This includes:
* git read-tree --reset HEAD
* git am --skip
* git am --abort
* git merge --abort
* git reset --hard
Add testcases documenting these shortcomings.
Signed-off-by:
From: Ben Peart
Skip merging the commit, updating the index and working directory if and
only if we are creating a new branch via "git checkout -b ."
Any other checkout options will still go through the former code path.
If sparse_checkout is on, require the user to manually opt in to this
Stefan Beller writes:
>> I wonder though if all those changes to the testsuite shouldn't be
>> merged.
>
> I think Stolee doesn't want this to be merged after rereading
> subject and the commit message.
Yes, I understand that, and for the most part I agree with it. This
commit main purpose is
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote:
I ran "git checkout" on a large repo and averaged the results of 3 runs.
This clearly demonstrates the benefit of the optimized unpack_trees()
as even the final "diff-index" is essentially a 3rd
I'm testing origin/next on Windows with a few other topics on top.
The first test fails like this. Do you see what is wrong?
Where should I start looking? Is it perhaps that upload-pack
is responding too soon so that fetch does not send 'have c1'?
this is the console output
On Tue, Jul 31, 2018 at 2:41 AM Stefan Beller wrote:
> > Taking a step back, was there anything that prompted these patches?
>
> I am flailing around on how to approach the ref store and the repository:
> * I dislike having to pass a repository 'r' twice. (current situation after
> patch 1.
On Tue, Jul 31, 2018 at 08:53:23AM -0700, Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> Interesting. I've never used the "-s subtree" strategy without
>
On Fri, Jul 27, 2018 at 5:59 AM, Ben Peart wrote:
> Sending this update as Elijah is on vacation. This only updates the test
> case based on feedback from the list.
Thanks! One less thing for me to catch up on. :-)
On Mon, Jul 30, 2018 at 10:40 AM, Stefan Beller wrote:
> On Mon, Jul 30, 2018 at 9:00 AM Nguyễn Thái Ngọc Duy
> wrote:
>>
>> One of the things I notice when watching a normal git user face a
>> merge conflicts is the output is very verbose (especially when there
>> are multiple conflicts) and
Jeff King writes:
> The problem introduced in that commit is that each iteration through the
> loop advances the tree pointers.
Ah, indeed.
The original used tree_entry_extract() and update_tree_entry()
separately, but the update does tree_entry() on both sides.
> So the assertion in that
Alban Gruin writes:
>> Hmph, from reading your other message
>>
>>
>> https://public-inbox.org/git/dce8c99b-51e9-4ed1-8ae4-28049cb6e...@gmail.com/
>>
>> I got an impression that a rerolled version is coming anyway. Is
>> this fix so urgent that it needs tobe squashed in in the meantime
>>
On 07/30, brian m. carlson wrote:
> On Mon, Jul 30, 2018 at 10:50:51AM -0700, Brandon Williams wrote:
> > On 07/29, brian m. carlson wrote:
> > > The object ID parsing machinery is aware of "@" as a synonym for "HEAD"
> > > and this is documented accordingly in gitrevisions(7). The push
> > >
Hi Junio,
Le 31/07/2018 à 17:23, Junio C Hamano a écrit :
> Alban Gruin writes:
>
>> As pointed out by SZEDER Gábor, git-rebase.sh wrote to to 'quiet' with
>> an `echo`:
>>
>> echo "$GIT_QUIET" > "$state_dir/quiet"
>>
>> This mean that even if $GIT_QUIET is empty, a newline is written to
>>
While debugging this, I did try -X subtree=src/ however the effect was the
same.
On Tue, Jul 31, 2018 at 11:53 AM Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
>
George Shammas writes:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
Interesting. I've never used the "-s subtree" strategy without
"-Xsubtree=..." to explicitly tell where the thing should go for a
long time, so I am
1 - 100 of 153 matches
Mail list logo
