On Thu, Sep 27, 2018 at 09:25:45PM -0700, Taylor Blau wrote:
> The recently-introduced "core.alternateRefsCommand" allows callers to
> specify with high flexibility the tips that they wish to advertise from
> alternates. This flexibility comes at the cost of some inconvenience
> when the caller
On Thu, Sep 27, 2018 at 09:25:42PM -0700, Taylor Blau wrote:
> Let the repository that has alternates configure this command to avoid
> trusting the alternate to provide us a safe command to run in the shell.
> To behave differently on each alternate (e.g., only list tags from
> alternate A, only
On Thu, Sep 27, 2018 at 09:25:39PM -0700, Taylor Blau wrote:
> To list alternate references, 'read_alternate_refs' creates a child
> process running 'git for-each-ref' in the alternate's Git directory.
>
> Prepare to run other commands besides 'git for-each-ref' by introducing
> and moving the
> From: Jeff King
Pretty sure that isn't right. :)
The preferred way to send a patch with a different author is to have
actual email be "From:" you, but then include a:
From: Jeff King
as the first line of the body (which git-am will then pick up).
git-send-email will do this for you
When updating the collect and print functions, it was found that
status variables were initialized in the collect phase and some
variables were later freed in the print functions.
Move the status state structure variables into the status state
structure and populate them in the collect functions.
Junio suggested a cleanup patch, jc/wt-status-state-cleanup, which is
the basis for this patch.
This patch uses ss/wt-status-committable.
The main update from the patch suggestion was cleanup of the free
calls for three strings in the status structure.
Stephen P. Smith (1):
roll
The recently-introduced "core.alternateRefsCommand" allows callers to
specify with high flexibility the tips that they wish to advertise from
alternates. This flexibility comes at the cost of some inconvenience
when the caller only wishes to limit the advertisement to one or more
prefixes.
For
None of the current callers use the refname parameter we pass to their
callbacks. In theory somebody _could_ do so, but it's actually quite
weird if you think about it: it's a ref in somebody else's repository.
So the name has no meaning locally, and in fact there may be duplicates
if there are
Hi,
Attached is the third re-roll of mine and Peff's series to introduce
'core.alternateRefsCommand', and 'core.alternateRefsPrefixes' to filter
the initial ".have" advertisement when an alternate has a pathologically
large number of references.
A range-diff against v2 is included below, but the
When in a repository containing one or more alternates, Git would
sometimes like to list references from those alternates. For example,
'git receive-pack' lists the "tips" pointed to by references in those
alternates as special ".have" references.
Listing ".have" references is designed to make
To list alternate references, 'read_alternate_refs' creates a child
process running 'git for-each-ref' in the alternate's Git directory.
Prepare to run other commands besides 'git for-each-ref' by introducing
and moving the relevant code from 'read_alternate_refs' to
> On Sep 27, 2018, at 6:43 PM, Junio C Hamano wrote:
>
> Sam McKelvie writes:
>
Subject: Re: [PATCH] submodule: Alllow staged changes for
get_superproject_working_tree
>>>
>>> s/Alllow/allow/;
>>>
>>
>> Ok, no caps on first letter of subject.
>
> Ah, that, too. I meant to
On Fri, Sep 28, 2018 at 02:48:43AM +0200, SZEDER Gábor wrote:
> Junio,
>
> On Thu, Sep 27, 2018 at 02:44:30PM +0200, SZEDER Gábor wrote:
> > diff --git a/t/t1701-racy-split-index.sh b/t/t1701-racy-split-index.sh
> > new file mode 100755
> > index 00..ebde418d7e
> > --- /dev/null
> > +++
On Wed, Sep 26, 2018 at 02:38:53PM -0400, Jeff King wrote:
> On Wed, Sep 26, 2018 at 06:39:56AM -0700, Taylor Blau wrote:
>
> > > A perl tangent if you're interested:
> > [...]
> >
> > To be clear, we ought to leave this function as:
> >
> > extract_haves () {
> > depacketize | perl -lne
On Wed, Sep 26, 2018 at 10:28:31AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Here's the patch that adds that external commands and aliases
> > sections. I feel that external commands section is definitely good to
> > have even if we don't replace "help -a". Aliases are more
> >
Sam McKelvie writes:
>>> Subject: Re: [PATCH] submodule: Alllow staged changes for
>>> get_superproject_working_tree
>>
>> s/Alllow/allow/;
>>
>
> Ok, no caps on first letter of subject.
Ah, that, too. I meant to correct triple ell, though ;-)
When one reviewer says Reviewed-by: but you
Jeff King writes:
> Alternatively, %(HEAD) could return "*" or "+" depending on whether it's
> the current worktree head. That would mildly break an existing format
> like:
>
> %(if)%(HEAD)%(then) *%(color:green)%(end)%(refname)
>
> since it would start coloring worktree HEADs the same way. It
Josh Steadmon writes:
> Yes, the version on my desktop sends version=2 when archiving:
>
> ∫ which git
> /usr/bin/git
> ∫ git --version
> git version 2.19.0.605.g01d371f741-goog
> ∫ GIT_TRACE_PACKET=${HOME}/server_trace git daemon \
> --enable=upload-archive \
>
On 9/27/2018 6:24 PM, Ramsay Jones wrote:
commit 225df8a468 ("ieot: add Index Entry Offset Table (IEOT)
extension", 2018-09-26) added a 'DIV_ROUND_UP(entries, ieot_blocks)
expression, where ieot_blocks was set to zero for a single cpu
platform. This caused an SIGFPE and a core dump in
On Thu, Sep 27, 2018 at 04:27:32PM -0700, Jonathan Nieder wrote:
> > There are different opinions on how to document an API properly.
> > Discussion turns out nobody disagrees with documenting new APIs on the
> > function level in the header file and high level concepts in
> >
On Thu, Sep 27, 2018 at 10:35:11PM +0100, Rafael Ascensão wrote:
> git branch has --format, but there's no way (at least to my knowledge)
> to define a value in gitconfig to be used by $git branch.
Oh, you're right. I was thinking of the branch.sort we just added in
v2.19.
I agree that having
On Thu, Sep 27, 2018 at 02:22:49PM -0700, Junio C Hamano wrote:
> The only comment I have is that I strongly suspect we will regret if
> we used an overly bland "worktree" to a rather narrrow "is this ref
> checked out in any worktree?" when we notice we want to learn other
> things that are
Junio,
On Thu, Sep 27, 2018 at 02:44:30PM +0200, SZEDER Gábor wrote:
> diff --git a/t/t1701-racy-split-index.sh b/t/t1701-racy-split-index.sh
> new file mode 100755
> index 00..ebde418d7e
> --- /dev/null
> +++ b/t/t1701-racy-split-index.sh
> @@ -0,0 +1,218 @@
> +#!/bin/sh
> +
> +# This
All of your comments seem reasonable; however, since the patch was signed off
by Stefan it
Is unclear to me whether I should submit another patch or what. I apologize for
not being
facile with the patching workflow.
> On Sep 27, 2018, at 3:02 PM, Junio C Hamano wrote:
>
> Sam McKelvie
On Wed, Sep 26, 2018 at 03:54:39PM -0400, Ben Peart wrote:
> Add support for a new index.threads config setting which will be used to
> control the threading code in do_read_index(). A value of 0 will tell the
> index code to automatically determine the correct number of threads to use.
> A value
On Wed, Sep 26, 2018 at 03:54:38PM -0400, Ben Peart wrote:
> The End of Index Entry (EOIE) is used to locate the end of the variable
Nit: perhaps start with:
The End of Index Entry (EOIE) optional extension can be used to ...
to make it clearer for those who don't immediately realize the
On Thu, Sep 27 2018, Jonathan Tan wrote:
> The skipping negotiator pushes entries onto the priority queue without
> ensuring that the commit is parsed, resulting in the entry ending up in
> the wrong position due to a lack of commit time. Fix this by parsing the
> commit whenever we push an
Hi,
Stefan Beller wrote:
> There are different opinions on how to document an API properly.
> Discussion turns out nobody disagrees with documenting new APIs on the
> function level in the header file and high level concepts in
> Documentation/technical, so let's state that in the guidelines.
I
The skipping negotiator pushes entries onto the priority queue without
ensuring that the commit is parsed, resulting in the entry ending up in
the wrong position due to a lack of commit time. Fix this by parsing the
commit whenever we push an entry onto the priority queue.
Signed-off-by: Jonathan
On Thu, Sep 27, 2018 at 12:42:48AM +, Tacitus Aedifex wrote:
> On Wed, Sep 26, 2018 at 02:48:49PM -0700, Junio C Hamano wrote:
> > We do not want your choice of gpg.program or what kind of
> > trust you have personally recorded in your ~/.gnupg/ affect how gpg
> > invoked inside our tests
On Fri, Sep 07, 2018 at 05:20:02AM +0200, SZEDER Gábor wrote:
> Homebrew recently enabled the quarantine feature, which breaks a lot
> of things [1], including installing Perforce in our macOS build jobs
> on Travis CI [2], breaking all those builds in the last couple of
> days.
> Note that one
> I get:
>
> warning: Ignoring --negotiation-tip because the protocol does not support
> it.
When I implemented --negotiation-tip, I only implemented it for
protocols that support connect or stateless-connect, because
implementing it fully would have required expanding the protocol helper
On Mon, Sep 24, 2018 at 01:05:23PM -0700, Junio C Hamano wrote:
> > Would it be helpful if I sent a script that ran during CI to ensure they
> > stayed in sync for the couple places where they overlap? I'm happy to
> > do so if you think it would be useful.
>
> It may even be an overkill.
>
> A
On 2018.09.27 15:20, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > 1. Clients sending version=2 when they do not, in fact, speak protocol
> > v2 for a service is a (serious) bug. (Separately from this
> > series) we should fix it.
> >
> > 2. That bug is already in the wild,
The comand `update-index --skip-worktree` seems to be an ideal way to
tell git to locally ignore some modified files. However, this seems
not to play well with very common commands like `checkout` and
`stash`.
$ git checkout other-branch
error: Your local changes to the following files would be
(dropping cc-s to my internal address that I don't use on this list
and to git-c...@google.com which bounces)
Hi,
Stefan Beller wrote:
> Internally we have rolled out this as an experiment for
> "submodules replacing the repo tool[1]". The repo tool is described as:
>
> Repo unifies Git
commit 225df8a468 ("ieot: add Index Entry Offset Table (IEOT)
extension", 2018-09-26) added a 'DIV_ROUND_UP(entries, ieot_blocks)
expression, where ieot_blocks was set to zero for a single cpu
platform. This caused an SIGFPE and a core dump in practically
every test in the test-suite, until test
On Thu, Sep 27 2018, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> There are different opinions on how to document an API properly.
>> Discussion turns out nobody disagrees with documenting new APIs on the
>> function level in the header file and high level concepts in
>
> Looks
Jonathan Nieder writes:
> 1. Clients sending version=2 when they do not, in fact, speak protocol
> v2 for a service is a (serious) bug. (Separately from this
> series) we should fix it.
>
> 2. That bug is already in the wild, alas. Fortunately the semantics of
> GIT_PROTOCOL as a
Internally we have rolled out this as an experiment for
"submodules replacing the repo tool[1]". The repo tool is described as:
Repo unifies Git repositories when necessary, performs uploads to the
Gerrit revision control system, and automates parts of the Android
development
commit 440fc7c0729 ("fetch: replace string-list used as a look-up
table with a hashmap", 2018-09-25) renamed a string-list variable
(while adding a hashmap of the same name) and forgot to rename the
string-list variable in a call to string_list_clear().
Signed-off-by: Ramsay Jones
---
Hi
Sam McKelvie writes:
> Subject: Re: [PATCH] submodule: Alllow staged changes for
> get_superproject_working_tree
s/Alllow/allow/;
> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>
> "fatal: BUG: returned path string doesn't match cwd?"
>
> when the superproject has
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 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 v7.
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
---
The changes are due to
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 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 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 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 v7.
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 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
---
The changes are due to the rebase, no real changes otherwise.
.gitignore
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 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 v7.
builtin/rebase--helper.c | 7 ++-
git-rebase--interactive.sh | 25
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
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 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 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
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
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.
The v7 was based on ffc6fa0e39 ("Fourth batch for 2.19 cycle",
2018-07-24), but this series is based on fe8321ec05 ("Second batch post
2.19", 2017-09-24) due to some conflicts.
Changes since v7:
- [17/20] The optionnal parameter
This makes rebase_path_todo(), get_missing_commit_check_level(),
write_message() 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
Stefan Beller writes:
> There are different opinions on how to document an API properly.
> Discussion turns out nobody disagrees with documenting new APIs on the
> function level in the header file and high level concepts in
Looks conditionally good ;-) Thanks for keeping the ball rolling.
I
On Thu, Sep 27, 2018 at 12:24 PM Jonathan Tan wrote:
>
> If only hash literals are given on a "git fetch" command-line, tag
> following is not requested, and the fetch is done using protocol v2, a
> list of refs is not required from the remote. Therefore, optimize by
> invoking
On Thu, Sep 27, 2018 at 12:24 PM Jonathan Tan wrote:
>
> +test_expect_success 'when dynamically fetching missing object, do not list
> refs' '
> + cat trace &&
leftover debug cat?
On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
> On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote:
> > But if we're open to change how branches are displayed maybe a config
> > option like branch.format (probably not the best name choice) that can
> > be set to the
There are different opinions on how to document an API properly.
Discussion turns out nobody disagrees with documenting new APIs on the
function level in the header file and high level concepts in
Documentation/technical, so let's state that in the guidelines.
Signed-off-by: Stefan Beller
---
Jeff King writes:
> On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
>
>> now, we could do:
>>
>> %(if)%(HEAD)%(then)* %(color:bold green)
>> %(else)%(if)%(worktree)%(then)+ %(color:green)
>> %(else) %(end)%(end)
>>
>> (respecting the user's color config, of course, rather
On Tue, Sep 25, 2018 at 02:58:08PM -0700, Matthew DeVore wrote:
> Here is the new commit with updated message (I will wait for a day or
> two before I send a reroll):
>
> Documentation: add shell guidelines
>
> Add the following guideline to Documentation/CodingGuidelines:
>
>
Jonathan Tan writes:
> To answer Junio's questions in [1], I think it's best to include the
> full patch set that I'm developing, so here it is. The original patch is
> now patch 3 of this set.
Yeah, taking it out of context did make its purpose fuzzy. Without
the other patches in the series
On Wed, Sep 26, 2018 at 12:16:16PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
> > I quote >"$file" (but not var=$var) because the CodingGuidelines
> > tells me to:
> >
> > - Redirection operators should be written with space before, but no
> >space after them. In other words,
On Thu, Sep 27 2018, Jonathan Tan wrote:
>> > If you wanted to do this, it seems better to me to just declare a "null"
>> > negotiation algorithm that does not perform any negotiation at all.
>>
>> I think such an algorithm is a good idea in general, especially for
>> testing, and yeah, maybe
On Thu, Sep 27, 2018 at 01:16:19PM -0700, Nickolai Belakovski wrote:
>
> Not to hijack my own thread, but FWIW git branch -r shows remote
> branches in red, but old/new status of a remote branch is ambiguous
> (could have new stuff, could be out of date). Also, git branch -vv
> shows remote
On 09/27, Ruud van Asseldonk wrote:
> Hi,
>
> I just ran into a segmentation fault during a rebase with rerere
> enabled. Inspecting the core dump with gdb shows:
Thanks for reporting this bug
> (gdb) bt
> #0 0x55d673375ce0 in do_rerere_one_path (update=0x7fff03c37f30,
>
On 2018.09.13 09:47, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > Signed-off-by: Josh Steadmon
> > ---
> > builtin/archive.c | 8 +++-
> > http-backend.c | 10 +-
> > transport-helper.c | 5 +++--
> > 3 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff
Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list` command:
--name-status --oneline --patch-with-stat
Signed-off-by: Steven Fernandez
---
This is my first patch to the project so please be excuse any process
Not to hijack my own thread, but FWIW git branch -r shows remote
branches in red, but old/new status of a remote branch is ambiguous
(could have new stuff, could be out of date). Also, git branch -vv
shows remote tracking branches in blue. One could argue it should be
red since git branch -r is in
Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list` command:
--name-status --oneline --patch-with-stat
Signed-off-by: Steven Fernandez
---
This is my first patch to the project so please be excuse any process
On Thu, Sep 27 2018, Rafael Ascensão wrote:
> On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
>> Do we want to limit this to git-branch, though? Ideally any output you
>> get from git-branch could be replicated with for-each-ref (or with
>> a custom "branch --format").
>>
>> I.e.,
On Thu, Sep 27, 2018 at 11:12 AM Sam McKelvie wrote:
>
> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>
> "fatal: BUG: returned path string doesn't match cwd?"
>
> when the superproject has an unmerged entry for the current submodule,
> instead of displaying the
On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
> now, we could do:
>
> %(if)%(HEAD)%(then)* %(color:bold green)
> %(else)%(if)%(worktree)%(then)+ %(color:green)
> %(else) %(end)%(end)
>
> (respecting the user's color config, of course, rather than hard-coded
> colors).
>
>
> > If you wanted to do this, it seems better to me to just declare a "null"
> > negotiation algorithm that does not perform any negotiation at all.
>
> I think such an algorithm is a good idea in general, especially for
> testing, and yeah, maybe that's the best way out of this, i.e. to do:
>
>
On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote:
> On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
> > Do we want to limit this to git-branch, though? Ideally any output you
> > get from git-branch could be replicated with for-each-ref (or with
> > a custom "branch
On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
> Do we want to limit this to git-branch, though? Ideally any output you
> get from git-branch could be replicated with for-each-ref (or with
> a custom "branch --format").
>
> I.e., could we have a format in ref-filter that matches HEAD,
If only hash literals are given on a "git fetch" command-line, tag
following is not requested, and the fetch is done using protocol v2, a
list of refs is not required from the remote. Therefore, optimize by
invoking transport_get_remote_refs() only if we need the refs.
Signed-off-by: Jonathan Tan
The built-in bundle transport and the transport helper interface do not
work when transport_fetch_refs() is called immediately after transport
creation. This will be needed in a subsequent patch, so fix this.
Evidence: fetch_refs_from_bundle() relies on data->header being
initialized in
When all refs to be fetched are exact OIDs, it is possible to perform a
fetch without requiring the remote to list refs if protocol v2 is used.
Teach Git to do this.
This currently has an effect only for lazy fetches done from partial
clones. The change necessary to likewise optimize "git fetch
The get_refs_via_connect() function both performs the handshake
(including determining the protocol version) and obtaining the list of
remote refs. However, the fetch protocol v2 supports fetching objects
without the listing of refs, so make it possible for the user to skip
the listing by creating
To answer Junio's questions in [1], I think it's best to include the
full patch set that I'm developing, so here it is. The original patch is
now patch 3 of this set.
[1] https://public-inbox.org/git/xmqq8t3pnphe@gitster-ct.c.googlers.com/
Rearranging Junio's questions:
> ... ah, do you
Hi Derrick
On Thu, 27 Sep 2018 at 21:16, Derrick Stolee wrote:
> Thanks! This version satisfies my concerns and looks good to me.
>
> Reviewed-by: Derrick Stolee
Thanks for the spectacularly snappy review. I don't expect commit graphs
to help my use cases a lot, but I still wanted to try them
On 9/27/2018 3:12 PM, Martin Ågren wrote:
This v2 starts with the same two patches as v1 did, then goes on to
change "[commit] graph file" to "commit-graph file" with a dash, to
match other instances as well as Derrick's feedback.
Thanks! This version satisfies my concerns and looks good to me.
We have a couple of bullet items which span multiple lines, and where we
have prefixed each line with a `*`. (This might be the result of a text
editor trying to help.) This results in each line being typeset as a
separate bullet item. Drop the extra `*`.
Signed-off-by: Martin Ågren
---
The file processed by `git commit-graph` is referred to as the
"commit-graph file", also with a dash. We have a few references to the
"commit graph file", though, without the dash. These occur in
git-commit-graph.txt as well as in Doc/technical/commit-graph.txt. Fix
them.
Do not change the
While we're here, fix an instance of "folder" to be "directory".
Signed-off-by: Martin Ågren
---
Documentation/git-commit-graph.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-commit-graph.txt
b/Documentation/git-commit-graph.txt
index
This v2 starts with the same two patches as v1 did, then goes on to
change "[commit] graph file" to "commit-graph file" with a dash, to
match other instances as well as Derrick's feedback.
Martin Ågren (4):
git-commit-graph.txt: fix bullet lists
git-commit-graph.txt: typeset more in monospace
This document sometimes refers to the "commit-graph file" as just "the
graph file". This saves a couple of words here and there at the risk of
confusion. In particular, the documentation for `git commit-graph read`
appears to suggest that there are indeed different types of graph files.
Let's
On Thu, Sep 27, 2018 at 11:39:26AM -0700, Nickolai Belakovski wrote:
> Thanks for the feedback Peff. I actually agree with all your points.
> I'd considered an approach like what you proposed, but rejected it for
> the first iteration in an effort to keep scope limited and see what
> kind of
On Thu, Sep 27, 2018 at 8:34 PM Ævar Arnfjörð Bjarmason
wrote:
> ...
>
> So there is some special casing of .git/config somewhere. I looked into
> this ages ago, and don't remember where that's done.
Thanks! At least know I have some clues to look into (and will do).
--
Duy
On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>
> Using packet_reader will simplify version detection and capability
> handling, which will make implementation of protocol v2 support in
> git-archive easier.
>
> This refactoring does not change the behavior of "git archive".
>
>
1 - 100 of 159 matches
Mail list logo
