Lieber,
mitteile ich Ihnen dass, ich das Geschaeft mit Erfolg zu Ende
geschaft. Und ich bin im Momentan in Venezuela. Aber ich moechte Sie
mit der Summe USD350,000.00 beloehnen fuer Ihre Unterstuetzung und
Beistand waehrend unserer Zussammenarbeit. Auf diesen Grund habe ich
einen Pfarrer
This is the second attempt to fix the racy split index problem, which
causes occasional failures in several random test scripts when run
with 'GIT_TEST_SPLIT_INDEX=yes'. The important details are in patches
1 and 5 (corresponding to v1's 3 and 5).
Changes since v1:
- Most importanly, patch 5
Ever since the split index feature was introduced [1], refreshing a
split index is prone to a variant of the classic racy git problem.
There are a couple of unrelated tests in the test suite that
occasionally fail when run with 'GIT_TEST_SPLIT_INDEX=yes', but
't1700-split-index.sh', the only test
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the
When unpack_trees() constructs a new index, it copies cache entries
from the original index [1]. prepare_to_write_split_index() has to
deal with this, and it has a dedicated code path for copied entries
that are present in the shared index, where it compares the cached
data in the corresponding
Ever since the split index feature was introduced [1], refreshing a
split index is prone to a variant of the classic racy git problem.
Consider the following sequence of commands updating the split index
when the shared index contains a racily clean cache entry, i.e. an
entry whose cached stat
'struct split_index' contains the field 'nr_deletions', whose name
with the 'nr_' prefix suggests that it contains the number of deleted
cache entries. However, barring its initialization to 0, this field
is only ever set to 1, indicating that there is at least one deleted
entry, but not the
On Thu, Sep 27, 2018 at 02:44:33PM +0200, SZEDER Gábor wrote:
> split-index.c | 79 ---
> 1 file changed, 62 insertions(+), 17 deletions(-)
I generated this patch with more context lines than usual, so the two
conditions that I didn't add any
On Thu, Sep 27 2018, SZEDER Gábor wrote:
> This is the second attempt to fix the racy split index problem, which
> causes occasional failures in several random test scripts when run
> with 'GIT_TEST_SPLIT_INDEX=yes'. The important details are in patches
> 1 and 5 (corresponding to v1's 3 and
On Thu, Sep 27, 2018 at 03:53:24PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Sep 27 2018, SZEDER Gábor wrote:
>
> > This is the second attempt to fix the racy split index problem, which
> > causes occasional failures in several random test scripts when run
> > with
Hi Stefan,
On Mon, 24 Sep 2018 14:00:50 -0700
Stefan Beller wrote:
> On Mon, Sep 24, 2018 at 3:20 AM Antonio Ospite wrote:
>
[...]
> > This is a limitation of the object store in git, there is no equivalent
> > of get_oid() to get the oid from a specific repository and this affects
> >
On Fri, 21 Sep 2018 09:19:45 -0700
Junio C Hamano wrote:
> Antonio Ospite writes:
>
> > Protecting the problematic submodules function could work for now, but
> > I'd like to have more comments, my proposal is:
> >
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index
In order to more clearly display which branches are active, the output
of git branch is modified to colorize branches checked out in any linked
worktrees with the same color as the current branch.
This is meant to simplify workflows related to worktree, particularly
due to the limitations of not
On 9/26/2018 2:44 PM, Derrick Stolee wrote:
On 9/26/2018 1:59 PM, Junio C Hamano wrote:
Derrick Stolee writes:
In an effort to ensure new code is reasonably covered by the test
suite, we now have contrib/coverage-diff.sh to combine the gcov output
from 'make coverage-test ; make
On 9/27/2018 11:14 AM, Ben Peart wrote:
On 9/26/2018 2:44 PM, Derrick Stolee wrote:
On 9/26/2018 1:59 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Perhaps removing the middle columns of data and just " )
" would be easier? We could also remove tabs to save space. For
example:
On 9/26/2018 2:54 PM, Derrick Stolee wrote:
On 9/26/2018 2:43 PM, Thomas Gummerer wrote:
On 09/26, Derrick Stolee wrote:
This is a bit tricky to do, but I will investigate. For some things, the
values can conflict with each other (GIT_TEST_SPLIT_INDEX doesn't play
nicely with other index
On Thu, Sep 27 2018, SZEDER Gábor wrote:
> On Thu, Sep 27, 2018 at 03:53:24PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Thu, Sep 27 2018, SZEDER Gábor wrote:
>>
>> > This is the second attempt to fix the racy split index problem, which
>> > causes occasional failures in several random test
On 9/27/2018 11:21 AM, Ben Peart wrote:
On 9/26/2018 2:54 PM, Derrick Stolee wrote:
GIT_TEST_INDEX_THREADS=1
Because the test repos are so small (ie smaller than 10K files), the
test suite already executes as if GIT_TEST_INDEX_THREADS=1 is set (ie
single threaded). I added the test
On 2018-09-26 11:48 AM, Duy Nguyen wrote:
I believe the main selling point of multiple worktrees is sharing
refs. You could easily avoid expensive clones with --local, but
synchronizing between different clones is not very convenient. Other
than that, different worktrees tend to behave like
On Thu, Sep 27 2018, Nickolai Belakovski wrote:
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
>
> This is meant to simplify workflows
On Thu, Sep 27 2018, Derrick Stolee wrote:
> On 9/27/2018 11:21 AM, Ben Peart wrote:
>>
>>
>> On 9/26/2018 2:54 PM, Derrick Stolee wrote:
>>>
>>> GIT_TEST_INDEX_THREADS=1
>>>
>>
>> Because the test repos are so small (ie smaller than 10K files), the
>> test suite already executes as if
I had an IRC conversation with Johannes saying I didn't know Git For
Windows builds perfectly well for Linux, this just isn't advertised in
the ANNOUNCE E-Mails, so I hadn't tried.
Johannes doesn't build his own tarballs, but these are provided at:
https://github.com/git-for-windows/git/tags
Ævar Arnfjörð Bjarmason wrote:
> GFW is a "friendly fork", but a permanent one it seems. The diff between
> it and 2.19.0 proper is ~10k lines, and e.g. this last release had
> experimental stash/rebase in C that 2.19.0 didn't.
>
> So it would be great if this were packaged up by linux distro as
On 9/27/2018 12:01 PM, Ævar Arnfjörð Bjarmason wrote:
I had an IRC conversation with Johannes saying I didn't know Git For
Windows builds perfectly well for Linux, this just isn't advertised in
the ANNOUNCE E-Mails, so I hadn't tried.
We run CI to ensure it builds and tests on Mac OSX, too.
On Thu, Sep 27 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> GFW is a "friendly fork", but a permanent one it seems. The diff between
>> it and 2.19.0 proper is ~10k lines, and e.g. this last release had
>> experimental stash/rebase in C that 2.19.0 didn't.
>>
>> So it
Hi,
Ævar Arnfjörð Bjarmason wrote:
> So it's similar to various packages that have "alternates" and are semi
> or permanently forked, like emacs & xemacs, JDK etc., although I can't
> recall one offhand that's quite similar to GFW v.s. git.git.
>
> My only stake in this is I thought it would be
On Thu, Sep 27, 2018 at 6:24 PM Ævar Arnfjörð Bjarmason
wrote:
> My only stake in this is I thought it would be neat to be able to "apt
> install git-for-windows",
That's what private builds are for (or "PPA" if debian has an
equivalent). I already largely ignore any Windows reports because I
On Thu, Sep 27, 2018 at 5:24 PM Marc Branchaud wrote:
>
> On 2018-09-26 11:48 AM, Duy Nguyen wrote:
> >
> > I believe the main selling point of multiple worktrees is sharing
> > refs. You could easily avoid expensive clones with --local, but
> > synchronizing between different clones is not very
On Thu, Sep 27, 2018 at 9:20 AM Elijah Newren wrote:
> Subject: [PATCH] commit: fix erroneous BUG, 'multiple renames on the same
> target? how?'
>
> builtin/commit.c:prepare_to_commit() can call run_status() twice if
> using the editor, including status, and the user attempts to record a
>
On Thu, Sep 27, 2018 at 10:24 AM Ruud van Asseldonk wrote:
> Please let me know if there is anything I can do to help diagnose the
> problem.
Nothing yet but please keep the core dump. We might be able to dig
some more out of it to confirm if we find something suspicious.
--
Duy
On Wed, Sep 26, 2018 at 9:54 PM Ben Peart wrote:
> The high cost of parsing the index extensions is driven by the cache tree
> and the untracked cache extensions. As this is currently the longest pole,
> any reduction in this time will reduce the overall index load times so is
> worth further
On Wed, Sep 26, 2018 at 8:25 PM Ævar Arnfjörð Bjarmason
wrote:
> On Sun, Sep 23 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > +extensions.worktreeConfig::
> > + If set, by default "git config" reads from both "config" and
> > + "config.worktree" file in that order.
>
> How does this interact
Jeff King writes:
> If you're interested in pulling documentation out of the header files
> and generating asciidoc from it, I'm happy to at least try keeping it up
> to date. When we started putting this information into header files, we
> used "/**" to start the comment, as a special marker to
builtin/commit.c:prepare_to_commit() can call run_status() twice if
using the editor, including status, and the user attempts to record a
non-merge empty commit without explicit --allow-empty. If there is also
a rename involved as well (due to using 'git add -N'), then a BUG in
wt-status.c is
Will do re: screenshot when I get home, although it's pretty easy to
imagine, the git branch output will have one other branch colored in
green, bit without the asterisk (for one linked worktree) :)
Also will do re: changing comments to /**/ (didn't know // was from
C++, TIL) and I'll clean up
On 9/21/2018 1:39 PM, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
When running a command like 'git rev-list --topo-order HEAD',
Git performed the following steps:
1. Run limit_list(), which parses all reachable commits,
adds them to a linked list, and distributes
On Thu, Sep 27, 2018 at 5:15 PM Nickolai Belakovski
wrote:
>
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
My first thought was "how do I
On Thu, Sep 27 2018, Nickolai Belakovski wrote:
> Will do re: screenshot when I get home, although it's pretty easy to
> imagine, the git branch output will have one other branch colored in green,
> bit without the asterisk (for one linked worktree) :)
>
> Also will do re: changing comments to
On Thu, Sep 27, 2018 at 7:44 AM Antonio Ospite wrote:
>
> If you end up touching get_oid() please CC me.
noted. I am not sure I'll touch it anytime soon, though.
>
> Are you suggesting to look into super-prefix for any reason in
> particular?
No, I misread the intent of that part of your
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 superproject's working tree.
The problem is due to the fact that when a
On Thu, Sep 27, 2018 at 08:13:13AM -0700, Nickolai Belakovski wrote:
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
I think the goal makes
On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>
> This is the second version of my series to add a new protocol v2 command
> for archiving, with support for HTTP(S).
>
> NEEDSWORK: a server built with this series is not backwards-compatible
> with clients that set GIT_PROTOCOL=version=2 or
On Thu, Sep 27, 2018 at 10:36:11AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If you're interested in pulling documentation out of the header files
> > and generating asciidoc from it, I'm happy to at least try keeping it up
> > to date. When we started putting this information into
On 2018.09.27 11:20, Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
> >
> > This is the second version of my series to add a new protocol v2 command
> > for archiving, with support for HTTP(S).
> >
> > NEEDSWORK: a server built with this series is not
Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>> I've been discussing workarounds for this with Jonathan Nieder, but
>> please let me know if you have any suggestions for v3 of this series.
>
> Care to open the discussion to the list? What are the different
>
On Thu, Sep 27 2018, Duy Nguyen wrote:
> On Wed, Sep 26, 2018 at 8:25 PM Ævar Arnfjörð Bjarmason
> wrote:
>> On Sun, Sep 23 2018, Nguyễn Thái Ngọc Duy wrote:
>>
>> > +extensions.worktreeConfig::
>> > + If set, by default "git config" reads from both "config" and
>> > +
> It is very clear how you are churning the code, but it is utterly
> unclear from the description what you perceived as a problem and why
> this change is a good (if not the best) solution for that problem,
> at least to me.
Firstly, thanks for your comments and questions - it's sometimes hard
On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>
> Move assertions outside of the check_tar function so that all top-level
> code is wrapped in a test_expect_* assertion.
Cool, I'll file this under modernizing the test infrastructure ;-)
> diff --git a/t/t5000-tar-tree.sh
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 feedback I'd get overall (like would people even want this?).
This is a much
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".
>
>
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 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
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
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
---
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 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.
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
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
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
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
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,
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
> > 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 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).
>
>
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, 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.,
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 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
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 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 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
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 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:
>
>
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
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
---
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
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 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
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
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 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
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
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 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 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 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 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.
1 - 100 of 159 matches
Mail list logo
