* Re: silent_exec_failure when calling gpg
From: Junio C Hamano @ 2018-12-11 3:44 UTC (permalink / raw)
To: John Passaro; +Cc: git, Jeff King
In-Reply-To: <CAJdN7Kj5RaAsTstx_G14a_bR5Y92M3rtWAiMNPnQWgmz4JgEOg@mail.gmail.com>
John Passaro <john.a.passaro@gmail.com> writes:
> I've noticed that in v2.19.1, when using git to pretty print
> information about the signature, if git cannot find gpg (e.g. "git
> config gpg.program nogpg"), it prints an error to stderr:
>
> $ git show -s --pretty=%G?
> fatal: cannot run nogpg: No such file or directory
> N
>
> When I build from master, that no longer happens:
>
> $ ../git/git show -s --pretty=%G?
> N
>
> Is this intentional behavior, i.e. something I can count on being the
> case in future releases? Or should I treat this as a bug report?
In general, behaviour of Porcelain commands like "git show" can and
will be changed to match interactive use by humans, and should never
be relied on in your scripts.
Having said that, I think we did not mean to kill the diagnositic
message.
> This behavior makes sense in a lot of ways. If you're interested in
> verifying commit signatures, it's hard to imagine needing a reminder
> to install the program it depends on (though the error might help you
> identify bad configuration for "gpg.program").
Quite the contrary, from a single "N", you cannot immediately tell
if the commit is not signed, if your GPG is misconfigured, or if you
have a stray gpg.program that points at nowhere.
I think the uninteded behaviour change was in 17809a98 ("Merge
branch 'jk/run-command-notdot'", 2018-10-30).
Thanks for a report.
^ permalink raw reply
* Re: [PATCH 0/3] rebase: offer to reschedule failed exec commands automatically
From: Junio C Hamano @ 2018-12-11 3:28 UTC (permalink / raw)
To: Stefan Beller; +Cc: Johannes Sixt, gitgitgadget, git
In-Reply-To: <CAGZ79kY18SCaCBvkWyeVd+oeJ4EhoJK4=QxGhJ9a77iX2sR8ew@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> I wonder if it might be better to push this mechanism
> one layer down: Instead of having a flag that changes
> the behavior of the "exec" instructions and having a
> handy '-y' short cut for the new mode, we'd rather have
> a new type of command that executes&retries a command
> ...
> By having two classes, I would anticipate fewer compatibility
> issues ('"Exec" behaves differently, and I forgot I had turned
> on the rescheduling').
It takes us back to the original proposal that started this whole
thing.
cf. <3fb5a7ff-a63a-6fac-1456-4dbc9135d088@gmail.com>
After re-reading the thread, I still do not quite follow why it was
considered better to change the way "exec" is run with the command
line option than to implement this as a new insn [*1*], but that is
where this series fit in the larger picture, I think.
[Footnote]
*1* The original proposal called it "test" which I do not think was
a great name.
^ permalink raw reply
* Re: Difficulty with parsing colorized diff output
From: Stefan Beller @ 2018-12-11 3:26 UTC (permalink / raw)
To: Jeff King; +Cc: george.w.king, git
In-Reply-To: <20181208071634.GA18272@sigill.intra.peff.net>
> (For the Git project itself, we long ago realized that putting raw color
> codes into the source is a big pain when working with diffs, and we
> instead use tools like t/test-lib-functions.sh's test_decode_color).
And also we hid the colors behind #defines and such.
> > * Context lines do not begin with reset code, but do end with a reset
> > code. It would be preferable in my opinion if they had both (like
> > every other line), or none at all.
>
> Context lines do have both. It's just that the default color for context
> lines is empty. ;)
The content itself can contain color codes.
Instead of unconditionally resetting each line, we could parse each
content line to determine if we actually have to reset the colors.
>
> But yes, I think it might be reasonable to recognize when an opening
> color is empty, and turn the closing reset into a noop in that case (or
> I guess you are also advocating the opposite: turn an empty color into a
> noop \x1b[m or similar).
>
> I think most of the coloring, including context lines, is coming from
> diff.c:emit_diff_symbol_from_struct(). Instead of unconditionally
> calling:
>
> context = diff_get_color_opt(o, DIFF_CONTEXT);
> reset = diff_get_color_opt(o, DIFF_RESET);
>
> I suspect we could have a helper like this:
>
> static const char *diff_get_reset(const char *color)
> {
> if (!color || !*color)
> return "";
> return diff_colors[DIFF_RESET];
> }
> ...
> context = diff_get_color_opt(o, DIFF_CONTEXT);
> reset = diff_get_reset(context);
Another easier way to do so would be to drop
the line
needs_reset = 1; /* 'line' may contain color codes. */
in diff.c::emit_line_0
I run the test suite and it passes (I thought we had a test
enforcing we'd reset any user provided coloring).
> > * Added lines have excess codes after the plus sign. The entire prefix
> > is, `\x1b[32m+\x1b[m\x1b[32m` translating to GREEN PLUS RESET GREEN.
> > Emitting codes after the plus sign makes the parsing more complex and
> > idiosyncratic.
Then we have broken code in diff.c::emit_line_ws_markup
in the last case ("else {") which first emits the sign via
emit_line_0 and then the rest via ws_check_emit.
It sounds like we'd want to replace `reset` in the call
of emit_line_0 with
set == set_sign ? NULL : reset
and set in the call to ws_check_emit with
set == set_sign ? NULL : set
Manually looking at some diff output of said diff we'd get
<RED>- emit_line_0(o, set_sign ? set_sign : set, NULL, !!set_sign,
reset,<RESET>
<GREEN>+<RESET> <GREEN>emit_line_0(o, set_sign ? set_sign : set,
NULL, !!set_sign, set == set_sign ? NULL : reset,<RESET>
and the issue is that we do not color the beginning white space
of the emission from ws_check_emit but maybe we should.
Another idea would be to allow Git to output its output
as if it was run through test_decode_color, slightly related:
https://public-inbox.org/git/20180804015317.182683-8-sbeller@google.com/
i.e. we'd markup the output instead of coloring it.
^ permalink raw reply
* Re: [PATCH 6/8] checkout: add --cached option
From: Junio C Hamano @ 2018-12-11 3:13 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Thomas Gummerer, Git Mailing List, Elijah Newren
In-Reply-To: <CACsJy8CfgJ4NAnbMjBFGhRWscZxJCgxtx0QwSMw7MTjeMT4gDw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> Elijah wanted another mode (and I agree) that modifies worktree but
> leaves the index alone. This is most useful (or least confusing) when
> used with <tree-ish> and would be default in restore-files. I'm not
> saying you have to implement it, but how do the new command line
> options are designed to make sense?
I'd model it after "git apply", i.e.
git restore-files [--tree=<treeish>] <pathspec>
would work only on the working tree files,
git restore-files --tree=<treeish> --cached <pathspec>
would match the entries in the index that match pathspec to the
given treeish without touching the working tree, and
git restore-files --tree=<treeish> --index <pathspec>
would be both.
I have never been happy with the phraso, the (arbitrary) distinction
between --cached/--index we use, so in the very longer term (like,
introducing synonym at 3.0 boundary and deprecating older ones at
4.0 boundary), it may not be a bad idea to rename "--index" to
"--index-and-working-tree" and "--cached" to "--index-only".
But until that happens, it would be better to use these two
consistently.
^ permalink raw reply
* Re: [PATCH 5/8] checkout: introduce --{,no-}overlay option
From: Junio C Hamano @ 2018-12-11 3:07 UTC (permalink / raw)
To: Elijah Newren
Cc: Thomas Gummerer, Git Mailing List,
Nguyễn Thái Ngọc
In-Reply-To: <CABPp-BEk+7n2wcbjETishqnMBs5DGrTEvD7gahLtEj5bZ2AYvA@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
>> Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
>> this way, so no changes are needed for the patch mode. We disallow
>> 'git checkout --overlay -p' to avoid confusing users who would expect
>> to be able to force overlay mode in 'git checkout -p' this way.
>
> Whoa...that's interesting. To me, that argues even further that the
> traditional checkout behavior was wrong all along and the choice of
> --overlay vs. --no-overlay in the original implementation was a total
> oversight. I'm really tempted to say that --no-overlay should just be
> the default in checkout too...but maybe that's too high a hill to
> climb, at least for now.
You are exhibiting a typical reaction to a shiny new toy.
The original "checkout paths out of the trees and/or the index to
recover what was lost" is modeled after "cp -R .../else/where .",
which is an overlay operation, and you wouldn't imagine complaining
that "cp -R" is wrong not to remove things in the target, to be
equivalent to "rm -fr where && cp -R .../else/where .".
Each has its own uses. We just didn't have the other half of the
pair.
If anything, I would consider "checkout -p" that does not do overlay
is a bug that needs to be fixed.
^ permalink raw reply
* Re: [PATCH 4/8] read-cache: add invalidate parameter to remove_marked_cache_entries
From: Junio C Hamano @ 2018-12-11 2:42 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Thomas Gummerer, Git Mailing List, Elijah Newren
In-Reply-To: <CACsJy8AiQvu8W4=2HLKMdg+n2HiDrcLvKPRurKvziXaJdqefRg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> I'm still a bit scared of this invalidation business in unpack-trees.
I too was (and I suspect that I would realize that I still am, if I
take another fresh look at the current code) afraid when I did the
cache-tree work and decided to invalidate it as a whole upfront.
> The thing is, we handle two separate index_state there, src_index and
> result and invalidation has to be done on the right one (because index
> extensions are on src_index until the very end of unpack-trees;
> invalidating on 'result' would be no-op and wrong).
> ...
> Yeah I think it's because cache-tree and untracked cache are already
> properly invalidated. ...
^ permalink raw reply
* Re: [PATCH 1/1] completion: complete <rev> in `git worktree add <path> <rev>`
From: SZEDER Gábor @ 2018-12-11 2:34 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <830191fbfbf95b9d568ba91ddcdd9860173a476a.1544454643.git.gitgitgadget@gmail.com>
On Mon, Dec 10, 2018 at 07:10:46AM -0800, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The second non-option argument to `git worktree`'s `add` command is an
> optional revision. Let's complete it.
>
> Inspired by https://github.com/git-for-windows/git/pull/1681.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> contrib/completion/git-completion.bash | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 9e8ec95c3c..4194b4a2e7 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2773,6 +2773,11 @@ _git_worktree ()
> add,--*)
> __gitcomp_builtin worktree_add
> ;;
> + add,*)
> + if [ $(__git_count_arguments "worktree") -eq 2 ]; then
> + __git_complete_refs
> + fi
> + ;;
Unfortunately, this seems to work only in the following case:
git worktree add path <TAB>
i.e. when the two-be-completed word is still empty. However,
git worktree add path m<TAB>
doesn't work anymore, as it lists paths instead of refs. Furthermore,
git worktree add --detach path <TAB>
git worktree add --detach path m<TAB>
git worktree add -b newbranch path <TAB>
list paths as well.
However, I presume unintentionally,
git worktree add -b <TAB>
does the right thing and lists refs, but with
git worktree add -b m<TAB>
we are back at paths instead of refs. OTOH,
git worktree add --detach <TAB>
git worktree add --lock <TAB>
will erroneously list refs.
I wrote a completion function for 'git worktree' a long while ago,
back when it had only two subcommands, which did mostly the right
thing, but I found it too convoluted for serious submission. Here it
is for inspiration:
https://public-inbox.org/git/1440190256-21794-1-git-send-email-szeder@ira.uka.de/
> list,--*)
> __gitcomp_builtin worktree_list
> ;;
> --
> gitgitgadget
^ permalink raw reply
* Re: [PATCH 5/5] midx: implement midx_repack()
From: Stefan Beller @ 2018-12-11 2:32 UTC (permalink / raw)
To: gitgitgadget
Cc: git, Jeff King, Jonathan Nieder,
Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee
In-Reply-To: <41ef671ec8361a9635dc78c078d2d84e9d985236.1544465177.git.gitgitgadget@gmail.com>
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Derrick Stolee <dstolee@microsoft.com>
>
> To repack using a multi-pack-index, first sort all pack-files by
> their modified time. Second, walk those pack-files from oldest
> to newest, adding the packs to a list if they are smaller than the
> given pack-size. Finally, collect the objects from the multi-pack-
> index that are in those packs and send them to 'git pack-objects'.
Makes sense.
With this operation we only coalesce some packfiles into a new
pack file. So to perform the "complete" repack this command
has to be run repeatedly until there is at most one packfile
left that is smaller than batch size.
Imagine the following scenario:
There are 5 packfiles A, B, C, D, E,
created last Monday thru Friday (A is oldest, E youngest).
The sizes are [A=4, B=6, C=5, D=5, E=4]
You'd issue a repack with batch size=10, such that
A and B would be repacked into F, which is
created today, size is less or equal than 10.
You issue another repack tomorrow, which then would
coalesce C and D to G, which is
dated tomorrow, size is less or equal to 10 as well.
You issue a third repack, which then takes E
(as it is the oldest) and would probably find F as the
next oldest (assuming it is less than 10), to repack
into H.
H is then compromised of A, B and E, and G is C+D.
In a way these repacks, always picking up the oldest,
sound like you "roll forward" objects into new packs.
As the new packs are newest (we have no packs from
the future), we'd cycle through different packs to look at
for packing on each repacking.
It is however more likely that content is more similar
on a temporal basis. (e.g. I am boldly claiming that
[ABC, DE] would take less space than [ABE, CD]
as produced above).
(The obvious solution to this hypothetical would be
to backdate the resulting pack to the youngest pack
that is input to the new pack, but I dislike fudging with
the time a file is created/touched, so let's not go there)
Would the object count make sense as input instead of
the pack date?
> While first designing a 'git multi-pack-index repack' operation, I
> started by collecting the batches based on the size of the objects
> instead of the size of the pack-files. This allows repacking a
> large pack-file that has very few referencd objects. However, this
referenced
> came at a significant cost of parsing pack-files instead of simply
> reading the multi-pack-index and getting the file information for
> the pack-files. This object-size idea could be a direction for
> future expansion in this area.
Ah, that also explains why the above idea is toast.
Would it make sense to extend or annotate the midx file
to give hints at which packs are easy to combine?
I guess such an "annotation worker" could run in a separate
thread / pool with the lowest priority as this seems like a
decent fallback for the lack of any better information how
to pick the packfiles.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH 3/8] entry: support CE_WT_REMOVE flag in checkout_entry
From: Junio C Hamano @ 2018-12-11 2:28 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Thomas Gummerer, Git Mailing List, Elijah Newren
In-Reply-To: <CACsJy8DQd_DcuogF2Wnj47F6ef26L1dea7M2Yi-ESZ_naQZ=kw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>> + if (ce->ce_flags & CE_WT_REMOVE) {
>> + if (topath)
>> + BUG("Can't remove entry to a path");
>> + unlink_entry(ce);
>> + return 0;
>> + }
>
> This makes the path counting in nd/checkout-noisy less accurate. But
> it's not your fault of course.
When we check out absense of one path, how do we want to count it?
Do we say "one path checked out?" when we remove one path?
> Junio, do you still want to merge that series down to 'next' or drop
> it? If it will be merged down, I'll keep a note and fix it once this
> one lands too.
Sure, I still agree with you that "git checkout" that reports what
it did when given a "<branch>", but does not report what it did when
given a "<pathspec>", is being inconsistent. If it makes it easier
to manage, I can kick nd/checkout-noisy out of 'next' to be rebased
on whatever more appropriate when rewinding its tip.
Thanks.
^ permalink raw reply
* RE: Git clone fails with fatal: the remote end hung up unexpectedly
From: Owen Ofiesh @ 2018-12-11 2:25 UTC (permalink / raw)
To: Bryan Turner; +Cc: Git Users
In-Reply-To: <CAGyf7-HHnwJyEu8G4p4A0RxJELJkEaJGMVj5nNznhWthAgS19g@mail.gmail.com>
Hi Bryan, all,
> From: Bryan Turner [mailto:bturner@atlassian.com]
> Sent: Monday, December 10, 2018 5:16 PM
> To: Owen Ofiesh <oofiesh@maxlinear.com>
> Cc: Git Users <git@vger.kernel.org>
> Subject: Re: Git clone fails with fatal: the remote end hung up unexpectedly
>
> On Mon, Dec 10, 2018 at 4:55 PM Owen Ofiesh <mailto:oofiesh@maxlinear.com> wrote:
> >
> > We are seeing an issue where git clone in Linux Ubuntu 14.04.5 LTS fails
> > with the following error using the HTTP protocol.
> >
> > The error on the client is:
> > fatal: the remote end hung up unexpectedly
> > fatal: early EOF
> > fatal: index-pack failed
> >
> > The client is writing to an NFS volume.
>
> A further detail on this (Owen correct me if I'm wrong), but the same
> clone performed to a local disk, rather than NFS, succeeds.
Correct. The clone to local disk succeeds.
One more data point. I tried this with SSH just now, and the behavior
is somewhat improved in that I am only seeing the failure on the NFS
volume so far with 1 in 6 clone attempts (5 successful). Whereas with
HTTP, we see the failure every time.
> >
> > The HTTP POST error on the server is:
> > c.a.s.i.w.filters.StreamGuardFilter The remote client has aborted the connection
> > c.a.s.i.w.filters.StreamGuardFilter Failed to flush buffer; the remote client aborted the connection
>
> Bitbucket Server developer here. I just want to clarify one thing
> here, for the list. The above is logged when the cloning client
> disconnects unexpectedly in the middle of a hosting operation (push or
> pull). So, from the server's perspective, everything was going well
> and then the client left without saying goodbye.
Correct in that we see this behavior when cloning. Small updates
(push/pull) seems to work okay. We tested this previously by cloning to
local disk, then copying to NFS, and then trying very small updates.
> > Our git repositories are managed by Atlassian's bitbucket server v5.5.1.
> >
> > We see this with the Linux git client SW v1.9.1 and v2.19.2 (doesn't seem
> > to matter the client SW version).
> >
> > The Linux git server is SW v2.9.5.
> >
> > Per discussions about this we've tried the following:
> > 1. We increased the GIT_HTTP_MAX_REQUEST_BUFFER setting on the server
> > to 100MBs.
> > 2. We set the http.postBuffer client value to 100MBs.
> > Neither of these helped.
> >
> > Any thoughts about this please?
> >
> > Note:
> > For reasons I will not enter into, we cannot use SSH for this.
> >
> > Thank you.
> >
> > end
> >
> > Regards,
> > Owen Ofiesh, SCM, Software Test and Development Manager
> > MaxLinear, Inc. | http://www.maxlinear.com
> > 5966 La Place Court Suite 100 Carlsbad, CA 92008
> > Phone: 760-517-1109
> > Cell: 858-335-1690
> > mailto:oofiesh@maxlinear.com
> >
> >
^ permalink raw reply
* Re: [PATCH 2/8] entry: factor out unlink_entry function
From: Junio C Hamano @ 2018-12-11 2:23 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Thomas Gummerer, Git Mailing List, Elijah Newren
In-Reply-To: <CACsJy8AGerhjnT0O6vT264tND78N5cbgFREzYtdmriXERu0Jtw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> I wonder if we should move the 'removal' variable in symlinks to
> 'struct checkout' to reduce another global variable. But I guess
> that's the problem for another day. It's not the focus of this series.
Before any such move, I think it is important to notice that the
thing is not thread friendly and devise a way to deal with it.
^ permalink raw reply
* Re: [PATCH] parse-options: fix SunCC compiler warning
From: Junio C Hamano @ 2018-12-11 2:13 UTC (permalink / raw)
To: Duy Nguyen; +Cc: avarab, git, sunshine, szeder.dev
In-Reply-To: <20181210152642.GA16203@duynguyen.home>
Duy Nguyen <pclouds@gmail.com> writes:
> The reason it's in parse_options_step() is because -h is also handled
> in there. Although -h does not bury exit() deep in the call chain. So
> how about this as a replacement?
So just like -h returns PARSE_OPT_HELP and causes the calling
parse_options() to exit(129), the new _COMPLETE can be used to
trigger an early & successful return?
We'd also have to cover builtin/{blame,shortlog,update-index}.c
where they switch() on the return value from parse_options_step(),
but other than that, it probably is a better approach. The users of
parse_options_step() that avoid parse_options() want to handle the
various "we stopped by hitting a non-option" cases in their own
ways, so treating this special action the same way as -h is treated
would be sensible. We _might_ want to standardize some of the case
arms in these custom switch statements that appear in these three
built-in command implementations, but that can be done more easily
if this step is done like you showed below, I think.
> -- 8< --
> diff --git a/parse-options.c b/parse-options.c
> index 3b874a83a0..6932eaff61 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -516,7 +516,7 @@ static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> show_negated_gitcomp(original_opts, -1);
> show_negated_gitcomp(original_opts, nr_noopts);
> fputc('\n', stdout);
> - exit(0);
> + return PARSE_OPT_COMPLETE;
> }
>
> static int usage_with_options_internal(struct parse_opt_ctx_t *,
> @@ -638,6 +638,8 @@ int parse_options(int argc, const char **argv, const char *prefix,
> case PARSE_OPT_HELP:
> case PARSE_OPT_ERROR:
> exit(129);
> + case PARSE_OPT_COMPLETE:
> + exit(0);
> case PARSE_OPT_NON_OPTION:
> case PARSE_OPT_DONE:
> break;
> diff --git a/parse-options.h b/parse-options.h
> index 6c4fe2016d..a650a7d220 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -208,6 +208,7 @@ extern int opterror(const struct option *opt, const char *reason, int flags);
> /*----- incremental advanced APIs -----*/
>
> enum {
> + PARSE_OPT_COMPLETE = -2,
> PARSE_OPT_HELP = -1,
> PARSE_OPT_DONE,
> PARSE_OPT_NON_OPTION,
> -- 8< --
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Stefan Beller @ 2018-12-11 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com>
> * sb/more-repo-in-api (2018-11-14) 23 commits
> (merged to 'next' on 2018-11-19 at e5d2a129da)
> [..]
> The in-core repository instances are passed through more codepaths.
>
> Will cook in 'next'.
> cf. <20181115221254.45373-1-jonathantanmy@google.com>
Looking into that.
> * sb/submodule-recursive-fetch-gets-the-tip (2018-12-09) 9 commits
> [..]
> "git fetch --recurse-submodules" may not fetch the necessary commit
> that is bound to the superproject, which is getting corrected.
>
> Ready?
I saw you picked up the latest iteration of the last patch at
https://public-inbox.org/git/20181206212655.145586-1-sbeller@google.com/
which has received no review comments, yet, and you seem to have
just taken it for replacement without looking closely.
I think it is ready, but I seem to be an optimist at times
when it comes to my own code. :-)
^ permalink raw reply
* Re: [PATCH 1/5] multi-pack-index: prepare for 'expire' verb
From: SZEDER Gábor @ 2018-12-11 1:59 UTC (permalink / raw)
To: Stefan Beller
Cc: gitgitgadget, git, Jeff King, Jonathan Nieder,
Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee
In-Reply-To: <CAGZ79kYeHgCdzNNXUnp1NaokT=Vpj4mUVt1bZb5c+EkgO2z-4w@mail.gmail.com>
On Mon, Dec 10, 2018 at 05:35:28PM -0800, Stefan Beller wrote:
> On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: Derrick Stolee <dstolee@microsoft.com>
> >
> > The multi-pack-index tracks objects in a collection of pack-files.
> > Only one copy of each object is indexed, using the modified time
> > of the pack-files to determine tie-breakers. It is possible to
> > have a pack-file with no referenced objects because all objects
> > have a duplicate in a newer pack-file.
> >
> > Introduce a new 'expire' verb to the multi-pack-index builtin.
> > This verb will delete these unused pack-files and rewrite the
> > multi-pack-index to no longer refer to those files. More details
> > about the specifics will follow as the method is implemented.
> >
> > Add a test that verifies the 'expire' verb is correctly wired,
> > but will still be valid when the verb is implemented. Specifically,
> > create a set of packs that should all have referenced objects and
> > should not be removed during an 'expire' operation.
> >
> > Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> > ---
> > Documentation/git-multi-pack-index.txt | 8 +++++
> > builtin/multi-pack-index.c | 4 ++-
> > midx.c | 5 +++
> > midx.h | 1 +
> > t/t5319-multi-pack-index.sh | 47 ++++++++++++++++++++++++++
> > 5 files changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt
> > index f7778a2c85..822d83c845 100644
> > --- a/Documentation/git-multi-pack-index.txt
> > +++ b/Documentation/git-multi-pack-index.txt
> > @@ -31,6 +31,14 @@ verify::
> > When given as the verb, verify the contents of the MIDX file
> > at `<dir>/packs/multi-pack-index`.
> >
> > +expire::
> > + When given as the verb,
>
> Can it be given in another way? Or rather "if the verb is expire",
> then ...
> (I just checked the current man page, and both write and verify use
> this pattern as well. I find it strange as this first part of the sentence
> conveys little information, but is repeated 3 times now (once for
> each verb)).
>
> Maybe we can restructure the man page to have it more like
>
> The following verbs are available:
> +write::
> + create a new MIDX file, writing to <dir>/packs/multi-pack-index.
> +
> +verify::
> + verify the contents ...
I think a s/verb/subcommand/ would help a lot, too, because that's
what we call it everywhere else.
^ permalink raw reply
* Re: [PATCH 4/5] multi-pack-index: prepare 'repack' verb
From: Stefan Beller @ 2018-12-11 1:54 UTC (permalink / raw)
To: gitgitgadget
Cc: git, Jeff King, Jonathan Nieder,
Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee
In-Reply-To: <72b213959171af3bfe4d849b925920ddbfb3d4b7.1544465177.git.gitgitgadget@gmail.com>
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Derrick Stolee <dstolee@microsoft.com>
>
> In an environment where the multi-pack-index is useful, it is due
> to many pack-files and an inability to repack the object store
> into a single pack-file. However, it is likely that many of these
> pack-files are rather small, and could be repacked into a slightly
> larger pack-file without too much effort. It may also be important
> to ensure the object store is highly available and the repack
> operation does not interrupt concurrent git commands.
>
> Introduce a 'repack' verb to 'git multi-pack-index' that takes a
> '--batch-size' option. The verb will inspect the multi-pack-index
> for referenced pack-files whose size is smaller than the batch
> size, until collecting a list of pack-files whose sizes sum to
> larger than the batch size. Then, a new pack-file will be created
> containing the objects from those pack-files that are referenced
> by the multi-pack-index. The resulting pack is likely to actually
> be smaller than the batch size due to compression and the fact
> that there may be objects in the pack-files that have duplicate
> copies in other pack-files.
This highlights an optimization problem: How do we pick the
batches optimally?
Ideally we'd pick packs that have an overlap of many
same objects to dedup them completely, next best would
be to have objects that are very similar, such that they delta
very well.
(Assuming that the sum of the resulting pack sizes is a metric
we'd want to optimize for eventually)
For now it seems we just take a random cut of "small" packs.
>
> The current change introduces the command-line arguments, and we
> add a test that ensures we parse these options properly. Since
> we specify a small batch size, we will guarantee that future
> implementations do not change the list of pack-files.
This is another clever trick that makes the test correct
despite no implementation yet. :-)
> +repack::
> + When given as the verb, collect a batch of pack-files whose
> + size are all at most the size given by --batch-size,
okay.
> but
> + whose sizes sum to larger than --batch-size.
or less if there are not enough packs.
Now it would be interesting if we can specify an upper bound
(e.g. my laptop has 8GB of ram, can I use this incremental
repacking optimally by telling git to make batches of at most
7.5G), the answer seems to follow...
> The batch is
> + selected by greedily adding small pack-files starting with
> + the oldest pack-files that fit the size. Create a new pack-
> + file containing the objects the multi-pack-index indexes
> + into thos pack-files, and rewrite the multi-pack-index to
those
> + contain that pack-file. A later run of 'git multi-pack-index
> + expire' will delete the pack-files that were part of this
> + batch.
... but the optimization seems to be rather about getting rid
of the oldest packs first instead of getting as close to the batch
size. (e.g. another way to look at this is to "find the permutation
of all packs that (each are smaller than batch size), but in sum
are the smallest threshold above the batch size).
I guess that the strategy of picking the oldest is just easiest
to implement and should be sufficient for now, but memory
bounds might be interesting to keep in mind, just as the
optimal packing from above.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Junio C Hamano @ 2018-12-11 1:49 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Elijah Newren, Git Mailing List
In-Reply-To: <875zw1aw68.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Related; Junio: I've submitted a few things in the last 2-3 weeks which
> I knew weren't making it into 2.20, but I just wanted to kick out the
> door as I had them ready. Things which are not noted in this "What's
> Cooking".
>
> I'm fine with re-submitting those once 2.21 picks up, but don't want to
> needlessly spam if your plan is to circle around and pick up those
> things you were (rightly) ignoring during the RC period.
Please consider it a time to get things reviewed by each other and a
chance to polish them before they even hit 'pu'.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Junio C Hamano @ 2018-12-11 1:48 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List
In-Reply-To: <CABPp-BGVHnaZLg4fuptVmNa=jRHg0cMDTWjv1NdLQJXPe=+ahw@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
> On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> Git 2.20 has been tagged. I'd expect that we would slow down to see
>> how stable it is and queue only the brown-paper-bag fixes for a week
>> or so, before opening the tree for the next cycle, rewinding the tip
>> of 'next', etc.
>
> Does this mean you'd prefer we continue to wait a little longer before
> sending in new series and re-rolls, or just that you are managing
> expectations about when they might be queued?
More of the latter. The best way to find bugs that matter in real
life is to use the software in the real project settings, i.e. you
guys work on your own topics using Git. I'll keep reviewing and
commenting just like other reviewers, but the new patches won't come
close to 'next' (as I said elsewhere, being in 'pu' does not count
much---it is like getting bookmarked) in the meantime.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Junio C Hamano @ 2018-12-11 1:43 UTC (permalink / raw)
To: Josh Steadmon; +Cc: git
In-Reply-To: <20181210185321.GB37614@google.com>
Josh Steadmon <steadmon@google.com> writes:
> On 2018.12.09 17:42, Junio C Hamano wrote:
>> * js/protocol-advertise-multi (2018-11-17) 1 commit
>> - protocol: advertise multiple supported versions
>>
>> The transport layer has been updated so that the protocol version
>> used can be negotiated between the parties, by the initiator
>> listing the protocol versions it is willing to talk, and the other
>> side choosing from one of them.
>>
>> How's the doneness of this one?
>
> I'm not sure if you're asking me specifically or the list in general,
> but I haven't heard any complaints about this, and there are no
> outstanding requests on the review thread.
It is both but more of the latter ;-) "I haven't seen any problem
reported, and all review comments have been addressed" by you is
also a welcome feedback.
>> * js/smart-http-detect-remote-error (2018-11-17) 3 commits
>> (merged to 'next' on 2018-11-18 at 5c6edfcb85)
>> + remote-curl: die on server-side errors
>> + remote-curl: tighten "version 2" check for smart-http
>> + remote-curl: refactor smart-http discovery
>>
>> Some errors from the other side coming over smart HTTP transport
>> were not noticed, which has been corrected.
>>
>> Will cook in 'next'.
>
> Masaya had a series that addresses this as well:
> https://public-inbox.org/git/20181127045301.103807-1-masayasuzuki@google.com/
>
> To combine these, we'd want to drop the diff to remote-curl.c in the
> final patch of this series.
OK, I'll kick the topic out of 'next' when reopening the tree for
the next cycle. Could you work with him to feed me the result of
combined effort to replace these three patches? Thanks.
^ permalink raw reply
* Re: [PATCH] terminology tweak: prune -> path limiting
From: Junio C Hamano @ 2018-12-11 1:40 UTC (permalink / raw)
To: Matthew DeVore; +Cc: git, Jonathan Nieder, matvore, dstolee, pclouds, Jeff King
In-Reply-To: <CAMfpvhKh3xewUY-g9oVJq1o=G3w9EspoQUHc1edHUx3AD4OWfg@mail.gmail.com>
Matthew DeVore <matvore@google.com> writes:
> When I tried to figure out what "prune" and "prune_data" ("data" is
> quite vague, so these two fields read like "prune_1" and "prune_2")
> referred to in "revision.h",...
It was unfortunate that 8efdc326 ("rev-lib: Make it easy to do
rename tracking (take 2)", 2006-03-10) had to rename "paths" to
"prune_data" when attempting to generalize the history
simplification mechanism by introducing "prune_fn", which can be
used instead of a fixed function, and as one half of the pair, "data
used by the prune function" made some sense.
When we partially reverted that over-generalization with 53b2c823
("revision walker: mini clean-up", 2007-11-05), we probably should
have changed the prune_data back to paths, but we didn't. Worse
yet, when we made prune_data from a void pointer to struct pathspec
at afe069d1 ("struct rev_info: convert prune_data to struct
pathspec", 2010-12-17), we really should have renamed it back to
paths, but we didn't.
So I think it is a good idea to get rid of prune_data and make it
clear it is no longer a generic thing but cannot be anything but a
pathspec. I am not sure what the bit should be called, though. It
is a bit to enable any history simplification and not limited to
pathspec limiting (e.g. simplify-by-decoration enables it, too).
^ permalink raw reply
* Re: [PATCH 1/5] multi-pack-index: prepare for 'expire' verb
From: Stefan Beller @ 2018-12-11 1:35 UTC (permalink / raw)
To: gitgitgadget
Cc: git, Jeff King, Jonathan Nieder,
Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee
In-Reply-To: <1e34b48a2051089052c0b53b0059576b5ace45de.1544465177.git.gitgitgadget@gmail.com>
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Derrick Stolee <dstolee@microsoft.com>
>
> The multi-pack-index tracks objects in a collection of pack-files.
> Only one copy of each object is indexed, using the modified time
> of the pack-files to determine tie-breakers. It is possible to
> have a pack-file with no referenced objects because all objects
> have a duplicate in a newer pack-file.
>
> Introduce a new 'expire' verb to the multi-pack-index builtin.
> This verb will delete these unused pack-files and rewrite the
> multi-pack-index to no longer refer to those files. More details
> about the specifics will follow as the method is implemented.
>
> Add a test that verifies the 'expire' verb is correctly wired,
> but will still be valid when the verb is implemented. Specifically,
> create a set of packs that should all have referenced objects and
> should not be removed during an 'expire' operation.
>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> ---
> Documentation/git-multi-pack-index.txt | 8 +++++
> builtin/multi-pack-index.c | 4 ++-
> midx.c | 5 +++
> midx.h | 1 +
> t/t5319-multi-pack-index.sh | 47 ++++++++++++++++++++++++++
> 5 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt
> index f7778a2c85..822d83c845 100644
> --- a/Documentation/git-multi-pack-index.txt
> +++ b/Documentation/git-multi-pack-index.txt
> @@ -31,6 +31,14 @@ verify::
> When given as the verb, verify the contents of the MIDX file
> at `<dir>/packs/multi-pack-index`.
>
> +expire::
> + When given as the verb,
Can it be given in another way? Or rather "if the verb is expire",
then ...
(I just checked the current man page, and both write and verify use
this pattern as well. I find it strange as this first part of the sentence
conveys little information, but is repeated 3 times now (once for
each verb)).
Maybe we can restructure the man page to have it more like
The following verbs are available:
+write::
+ create a new MIDX file, writing to <dir>/packs/multi-pack-index.
+
+verify::
+ verify the contents ...
> delete the pack-files that are tracked
> + by the MIDX file at `<dir>/packs/multi-pack-index`
We're mentioning the location a lot. Could we keep a more detailed
note in --object-dir and not go into such detail in the verbs section?
(Then the paragraph here would be more concise. That makes it
easier to understand)
> but have
> + no objects referenced by the MIDX. All objects in these pack-
> + files have another copy in a more-recently modified pack-file.
The second sentence reads like a reason on why the first is a good
thing to have, so maybe use some subordinating conjunction adverb
("because") to make tell the reader
> + Rewrite the MIDX file afterward to remove all references to
> + these pack-files.
Makes sense.
>
> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
> index 70926b5bc0..948effc1ee 100755
> --- a/t/t5319-multi-pack-index.sh
> +++ b/t/t5319-multi-pack-index.sh
> @@ -348,4 +348,51 @@ test_expect_success 'verify incorrect 64-bit offset' '
> "incorrect object offset"
> '
>
> +test_expect_success 'setup expire tests' '
> + mkdir dup &&
> + (
> + cd dup &&
> + git init &&
> + for i in $(test_seq 1 20)
> + do
> + test_commit $i
> + done &&
> + git branch A HEAD &&
> + git branch B HEAD~8 &&
> + git branch C HEAD~13 &&
> + git branch D HEAD~16 &&
> + git branch E HEAD~18 &&
> + git pack-objects --revs .git/objects/pack/pack-E <<-EOF &&
> + refs/heads/E
> + EOF
> + git pack-objects --revs .git/objects/pack/pack-D <<-EOF &&
> + refs/heads/D
> + ^refs/heads/E
> + EOF
> + git pack-objects --revs .git/objects/pack/pack-C <<-EOF &&
> + refs/heads/C
> + ^refs/heads/D
> + EOF
> + git pack-objects --revs .git/objects/pack/pack-B <<-EOF &&
> + refs/heads/B
> + ^refs/heads/C
> + EOF
> + git pack-objects --revs .git/objects/pack/pack-A <<-EOF &&
> + refs/heads/A
> + ^refs/heads/B
> + EOF
> + git multi-pack-index write
> + )
> +'
> +
> +test_expect_success 'expire does not remove any packs' '
With the clever setup, this test is already correctly testing
what the docs claims it should do, despite having
no implementation. Nice.
Although the core issue is that the packs are disjunct sets
of objects, so maybe /s/any packs/required packs/ or such?
^ permalink raw reply
* Re: Retrieving a file in git that was deleted and committed
From: Junio C Hamano @ 2018-12-11 1:19 UTC (permalink / raw)
To: Jeff King; +Cc: biswaranjan panda, Bryan Turner, git
In-Reply-To: <20181208072915.GA20697@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> You can feed a set of revisions to git-blame with the "-S" option, but I
> don't offhand know how it handles diffs (I think it would have to still
> diff each commit against its parent, since history is non-linear, and a
> list is inherently linear).
It would diff each commit against its parent specified by the file
given to the -S option. The contents of the file is fed directly to
the graft mechanism to make the fake history in effect while the
"blame" runs, and you are not limited to a linear history.
^ permalink raw reply
* Re: Git clone fails with fatal: the remote end hung up unexpectedly
From: Bryan Turner @ 2018-12-11 1:15 UTC (permalink / raw)
To: oofiesh; +Cc: Git Users
In-Reply-To: <CY4PR19MB1526704FC790724C2DC68465ADA60@CY4PR19MB1526.namprd19.prod.outlook.com>
On Mon, Dec 10, 2018 at 4:55 PM Owen Ofiesh <oofiesh@maxlinear.com> wrote:
>
> We are seeing an issue where git clone in Linux Ubuntu 14.04.5 LTS fails with the following error using the HTTP protocol.
>
> The error on the client is:
> fatal: the remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
>
> The client is writing to an NFS volume.
A further detail on this (Owen correct me if I'm wrong), but the same
clone performed to a local disk, rather than NFS, succeeds.
>
> The HTTP POST error on the server is:
> c.a.s.i.w.filters.StreamGuardFilter The remote client has aborted the connection
> c.a.s.i.w.filters.StreamGuardFilter Failed to flush buffer; the remote client aborted the connection
Bitbucket Server developer here. I just want to clarify one thing
here, for the list. The above is logged when the cloning client
disconnects unexpectedly in the middle of a hosting operation (push or
pull). So, from the server's perspective, everything was going well
and then the client left without saying goodbye.
>
> Our git repositories are managed by Atlassian's bitbucket server v5.5.1.
>
> We see this with the Linux git client SW v1.9.1 and v2.19.2 (doesn't seem to matter the client SW version).
>
> The Linux git server is SW v2.9.5.
>
> Per discussions about this we've tried the following:
> 1. We increased the GIT_HTTP_MAX_REQUEST_BUFFER setting on the server to 100MBs.
> 2. We set the http.postBuffer client value to 100MBs.
> Neither of these helped.
>
> Any thoughts about this please?
>
> Note:
> For reasons I will not enter into, we cannot use SSH for this.
>
> Thank you.
>
> end
>
> Regards,
> Owen Ofiesh, SCM, Software Test and Development Manager
> MaxLinear, Inc. | www.maxlinear.com
> 5966 La Place Court Suite 100 Carlsbad, CA 92008
> Phone: 760-517-1109
> Cell: 858-335-1690
> oofiesh@maxlinear.com
>
>
^ permalink raw reply
* Git clone fails with fatal: the remote end hung up unexpectedly
From: Owen Ofiesh @ 2018-12-11 0:48 UTC (permalink / raw)
To: git@vger.kernel.org
We are seeing an issue where git clone in Linux Ubuntu 14.04.5 LTS fails with the following error using the HTTP protocol.
The error on the client is:
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
The client is writing to an NFS volume.
The HTTP POST error on the server is:
c.a.s.i.w.filters.StreamGuardFilter The remote client has aborted the connection
c.a.s.i.w.filters.StreamGuardFilter Failed to flush buffer; the remote client aborted the connection
Our git repositories are managed by Atlassian's bitbucket server v5.5.1.
We see this with the Linux git client SW v1.9.1 and v2.19.2 (doesn't seem to matter the client SW version).
The Linux git server is SW v2.9.5.
Per discussions about this we've tried the following:
1. We increased the GIT_HTTP_MAX_REQUEST_BUFFER setting on the server to 100MBs.
2. We set the http.postBuffer client value to 100MBs.
Neither of these helped.
Any thoughts about this please?
Note:
For reasons I will not enter into, we cannot use SSH for this.
Thank you.
end
Regards,
Owen Ofiesh, SCM, Software Test and Development Manager
MaxLinear, Inc. | www.maxlinear.com
5966 La Place Court Suite 100 Carlsbad, CA 92008
Phone: 760-517-1109
Cell: 858-335-1690
oofiesh@maxlinear.com
^ permalink raw reply
* Re: A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others
From: Stefan Beller @ 2018-12-11 0:54 UTC (permalink / raw)
To: Phillip Wood; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <70f4fab1-9352-49ac-f911-da3e5a0ca172@talktalk.net>
On Mon, Dec 10, 2018 at 6:43 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
>
> On 06/12/2018 18:11, Stefan Beller wrote:
> > On Thu, Dec 6, 2018 at 6:58 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
> >
> >>> So is there some "must be at least two consecutive lines" condition for
> >>> not-plain, or is something else going on here?
> >>
> >> To be considered a block has to have 20 alphanumeric characters - see
> >> commit f0b8fb6e59 ("diff: define block by number of alphanumeric chars",
> >> 2017-08-15). This stops things like random '}' lines being marked as
> >> moved on their own.
> >
> > This is spot on.
> >
> > All but the "plain" mode use the concept of "blocks" of code
> > (there is even one mode called "blocks", which adds to the confusion).
> >
> >> It might be better to use some kind of frequency
> >> information (a bit like python's difflib junk parameter) instead so that
> >> (fairly) unique short lines also get marked properly.
> >
> > Yes that is what I was initially thinking about. However to have good
> > information, you'd need to index a whole lot (the whole repository,
> > i.e. all text blobs in existence?) to get an accurate picture of frequency
> > information, which I'd prefer to call entropy as I come from a background
> > familiar with https://en.wikipedia.org/wiki/Information_theory, I am not
> > sure where 'frequency information' comes from -- it sounds like the
> > same concept.
> >
> > Of course it is too expensive to run an operation O(repository size)
> > just for this diff, so maybe we could get away with some smaller
> > corpus to build up this information on what is sufficient for coloring.
> >
> > When only looking at the given diff, I would imagine that each line
> > would not carry a whole lot of information as its characters occur
> > rather frequently compared to the rest of the diff.
>
> I was thinking of using lines rather than characters as the unit of
> information (if that's the right phrase). I was hoping that seeing how
> often a given line occurs within the set of files being diffed would be
> good enough to tell is if it is an "interesting" move or not.
That sounds reasonable. We should try that.
> In the
> mean time I wonder if decreasing the block limit to 10 alphanumeric
> characters would be enough to prevent too much noise in the output
> without suppressing matches that it would be useful to highlight.
Jonathan elegantly deferred the need to come up with data on why 20
is a good choice, but rather claimed previous art in git-blame, see
f0b8fb6e59 (diff: define block by number of alphanumeric chars,
2017-08-15), which seems to say we'd want to follow the
model of having a blame_entry_score (that counts the number
of alnum() characters per line) and the
BLAME_DEFAULT_MOVE_SCORE, which came into existence in
4a0fc95f18 (git-pickaxe: introduce heuristics to avoid "trivial" chunks,
2006-10-20), simply stating
The current heuristics are quite simple and may need to be
tweaked later, but we need to start somewhere.
so I guess replacing 20 by 10 is totally doable, but the proof on
why 10 is better than 20 is on you. ;-(
Probably it doesn't need to be as fancy as in 433860f3d0
(diff: improve positioning of add/delete blocks in diffs, 2016-09-05)
but we'd need to gather *some* data to convince
(s/convince/fool/) ourselves that it is better.
It could also be the case that we need to fine tune differently
for blame as for move detection, but we could still reuse
some code to process it.
^ permalink raw reply
* RE: Questions about ubifs,ubi and mtd?
From: 武井 克明 @ 2018-12-11 0:42 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git@vger.kernel.org
In-Reply-To: <87o99txwvp.fsf@evledraar.gmail.com>
Dear Ævar Arnfjörð Bjarmason,
Thank you for your advice.
I will ask my question to ML who told me.
Best regards,
Katsuaki Takei/Oki Electric Industry Co., Ltd./JP
> -----Original Message-----
> From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Sent: Monday, December 10, 2018 11:47 PM
> To: 武井 克明 <takei744@oki.com>
> Cc: git@vger.kernel.org
> Subject: Re: Questions about ubifs,ubi and mtd?
>
>
> On Mon, Dec 10 2018, 武井 克明 wrote:
>
> > Hi all,
> >
> > We are developing the product using file system using ubi, ubifs on hardware
> with NAND flash memory.
> >
> > Although the development of the product was completed, we are seeking
> your help as the customer who is using it is having trouble with it.
> >
> > The product we have developed has 6 MTD partitions for NAND flash
> memory.
> > These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b',
> 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for
> write access.
> > Nevertheless, when loading our program from 'rootfs-a', trying to read
> > the inode with the ubifs_read_node() function will result in "bad node
> > type" (ex: 193 but expected 9) and the LEB can not be read with the
> > expected value. (Even though you do not have write access to rootfs)
> >
> > Is there anyone who encountered such a problem? Is there patch?
> >
> > Please let me know, if you have any questions.
> >
> > Best regards,
> > Katsuaki Takei/Oki Electric Industry Co., Ltd./JP
>
> Hi. I think you're on the wrong mailing list (git@). You probably want to contact
> one of the linux lists, perhaps
> http://lists.infradead.org/mailman/listinfo/linux-mtd ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox