Re: Git in Outreachy December-March?

On Fri, Sep 2, 2016 at 11:02 AM, Jeff King wrote: > > I'm happy to act as admin. We will need a few things: > > - to arrange funding for the stipend. GitHub offered to cover this > last time, and if we are interested, I can see if this is still the > case. We can also

git add -p—splitting hunks, limit is too large

Hi git developers and community, I'd like to inquire as to why `git add -p` can only split hunks so much. The limit is too large; why can't you split until each hunk is only a line? I often have to run `edit` and split them manually myself. I'd like to contribute a patch to change it, although

Re: [PATCH 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands

Hi Dennis, On Fri, 2 Sep 2016, Dennis Kaarsemaker wrote: > On vr, 2016-09-02 at 09:13 +0200, Johannes Schindelin wrote: > > > As Git for Windows does not ship with translations (for multiple > > reasons), it would not be a regression. > > I'm confused, how does "git for windows does not ship

Re: [GIT PULL] l10n updates for 2.10.0 round 2

Hi Junio, Another update comes, please pull. The following changes since commit 5b18e70009487bb156cac18546d6f91105338f4c: A few more fixes before the final 2.10 (2016-08-31 10:21:05 -0700) are available in the git repository at: git://github.com/git-l10n/git-po tags/l10n-2.10.0-rnd2.2

Re: [PATCH 00/22] Prepare the sequencer for the upcoming rebase -i patches

Hi Kuba, On Fri, 2 Sep 2016, Jakub Narębski wrote: > W dniu 29.08.2016 o 10:03, Johannes Schindelin pisze: > > > This patch series marks the '4' in the countdown to speed up rebase -i > > by implementing large parts in C. It is based on the `libify-sequencer` > > patch series that I submitted

Re: [PATCH v2] t/Makefile: add a rule to re-run previously-failed tests

Johannes Schindelin writes: > Hi Ævar, > > On Fri, 2 Sep 2016, Ævar Arnfjörð Bjarmason wrote: > >> On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin >> wrote: >> >> > The biggest problem with Strawberry Perl is that it is virtually >> >

[PATCH 3/9] rebase -i: do not invent onelines when expanding/collapsing SHA-1s

To avoid problems with short SHA-1s that become non-unique during the rebase, we rewrite the todo script with short/long SHA-1s before and after letting the user edit the script. Since SHA-1s are not intuitive for humans, rebase -i also provides the onelines (commit message subjects) in the

[PATCH 0/9] The final building block for a faster rebase -i

This patch series reimplements the expensive pre- and post-processing of the todo script in C. And it concludes the work I did to accelerate rebase -i. Johannes Schindelin (9): rebase -i: generate the script via rebase--helper rebase -i: remove useless indentation rebase -i: do not invent

Re: [PATCH 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands

On vr, 2016-09-02 at 16:22 +0200, Johannes Schindelin wrote: > I hope this clarifies why I am not so concerned about some issues > such as translation, or commit messages, or grammar, and more so > about others, such as incorrect code. It does, thanks! D.

[PATCH 5/9] t3404: relax rebase.missingCommitsCheck tests

These tests were a bit anal about the *exact* warning/error message printed by git rebase. But those messages are intended for the *end user*, therefore it does not make sense to test so rigidly for the *exact* wording. In the following, we will reimplement the missing commits check in the

[PATCH 6/9] rebase -i: check for missing commits in the rebase--helper

In particular on Windows, where shell scripts are even more expensive than on MacOSX or Linux, it makes sense to move a loop that forks Git at least once for every line in the todo list into a builtin. Signed-off-by: Johannes Schindelin --- builtin/rebase--helper.c

[PATCH 7/9] rebase -i: skip unnecessary picks using the rebase--helper

In particular on Windows, where shell scripts are even more expensive than on MacOSX or Linux, it makes sense to move a loop that forks Git at least once for every line in the todo list into a builtin. Note: The original code did not try to skip unnecessary picks of root commits but punts instead

[PATCH 2/9] rebase -i: remove useless indentation

The commands used to be indented, and it is nice to look at, but when we transform the SHA-1s, the indentation is removed. So let's do away with it. For the moment, at least: when we will use the upcoming rebase--helper to transform the SHA-1s, we *will* keep the indentation and can reintroduce

[PATCH 9/9] rebase -i: rearrange fixup/squash lines using the rebase--helper

This operation has quadratic complexity, which is especially painful on Windows, where shell scripts are *already* slow (mainly due to the overhead of the POSIX emulation layer). Let's reimplement this with linear complexity (using a hash map to match the commits' subject lines) for the common

[PATCH 8/9] t3415: test fixup with wrapped oneline

The `git commit --fixup` command unwraps wrapped onelines when constructing the commit message, without wrapping the result. We need to make sure that `git rebase --autosquash` keeps handling such cases correctly, in particular since we are about to move the autosquash handling into the

[PATCH 4/9] rebase -i: also expand/collapse the SHA-1s via the rebase--helper

This is crucial to improve performance on Windows, as the speed is now mostly dominated by the SHA-1 transformation (because it spawns a new rev-parse process for *every* line, and spawning processes is pretty slow from Git for Windows' MSYS2 Bash). Signed-off-by: Johannes Schindelin

[PATCH 2/2] connect: know that zero-ID is not a ref

connect.c, when processing packfiles, treats a zero ID (with `capabilities^{}` in place of the refname) as an actual ref instead of a placeholder for a capability declaration, contrary to the specification in Reference Discovery in Documentation/technical/pack-protocol.txt. This is an issue when

[PATCH 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh

This enables JGIT to be used as a prereq in invocations of test_expect_success (and other functions) in other test scripts. Signed-off-by: Jonathan Tan --- t/t5310-pack-bitmaps.sh | 4 t/test-lib.sh | 4 2 files changed, 4 insertions(+), 4

[PATCH 0/2] handle empty spec-compliant remote repos correctly

This issue was noticed when trying to clone an empty repository served by a server that uses the JGit library. Reference Discovery in Documentation/technical/pack-protocol.txt dictates that servers should send a zero ID when there are no refs in the queried repository, and implementations like

Re: [PATCH 01/34] sequencer: support a new action: 'interactive rebase'

On Wed, Aug 31, 2016 at 10:54:02AM +0200, Johannes Schindelin wrote: > @@ -43,16 +51,20 @@ static GIT_PATH_FUNC(rebase_path_gpg_sign_opt, > "rebase-merge/gpg_sign_opt") > /* We will introduce the 'interactive rebase' mode later */ > static inline int is_rebase_i(const struct replay_opts *opts)

Re: git add -p—splitting hunks, limit is too large

On Fri, Sep 02, 2016 at 03:36:58PM +0100, Beau Martinez wrote: > I'd like to inquire as to why `git add -p` can only split hunks so > much. The limit is too large; why can't you split until each hunk is > only a line? I often have to run `edit` and split them manually > myself. There's some

[PATCH] sequencer: support folding in rfc2822 footer

When running `git cherry-pick -x`, a blank line would be inserted if a line in the footer was broken into multiple lines (which is inconsistent with its behavior if no lines were broken). For example, this command would produce: --- Sample-field: no blank line below (cherry picked from commit

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 2, 2016 at 12:39 PM, Shawn Pearce wrote: > On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan > wrote: >> >> + if (is_null_oid(_oid)) { >> + if (strcmp(name, "capabilities^{}")) > > Its not the zero ID

Re: [PATCH 6/9] rebase -i: check for missing commits in the rebase--helper

On vr, 2016-09-02 at 18:23 +0200, Johannes Schindelin wrote: > In particular on Windows, where shell scripts are even more expensive > than on MacOSX or Linux, it makes sense to move a loop that forks > Git at least once for every line in the todo list into a builtin. Heh, this was the one thing

If a branch moves a submodule, "merge --ff[-only]" succeeds while "merge --no-ff" fails with conflicts

Below is a simple reproduction of the issue. The _real_ problem is that this is how our pull request merges work, they're not allowed to do fast-forward merges. To work around this we are having to split this up into two pull requests/merges: One that copies the submodules to the new location and

Re: git add -p—splitting hunks, limit is too large

Jeff King writes: > Splitting to single lines means you need to remember to add the matched > pairs, which might be arbitrarily far apart. That's not really any > different than dumping the hunk in your editor, but I find there that > it's easy to rearrange and group things as

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 2, 2016 at 12:56 PM, Stefan Beller wrote: > On Fri, Sep 2, 2016 at 12:39 PM, Shawn Pearce wrote: >> On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan >> wrote: >>> >>> + if (is_null_oid(_oid)) { >>> +

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote: > connect.c, when processing packfiles, treats a zero ID (with > `capabilities^{}` in place of the refname) as an actual ref instead of a > placeholder for a capability declaration, contrary to the specification > in Reference

Fixup of a fixup not working right

Suppose I have a branch with 4 commits, in the following order (as you might see during interactive rebase): pick 123 Original Change pick 789 fixup! Original Change pick 456 Some Other Thing pick abc fixup! fixup! Original Change However, let's say the first commit is already pushed upstream on

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

Hi, Jonathan Tan wrote: > connect.c, when processing packfiles, treats a zero ID (with > `capabilities^{}` in place of the refname) as an actual ref instead of a > placeholder for a capability declaration, contrary to the specification > in Reference Discovery in

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan wrote: > > + if (is_null_oid(_oid)) { > + if (strcmp(name, "capabilities^{}")) Its not the zero ID that is special, its the "capabilities^{}" name that is special when its the first entry

Re: [PATCH 4/9] rebase -i: also expand/collapse the SHA-1s via the rebase--helper

On vr, 2016-09-02 at 18:23 +0200, Johannes Schindelin wrote: > This is crucial to improve performance on Windows, as the speed is now > mostly dominated by the SHA-1 transformation (because it spawns a new > rev-parse process for *every* line, and spawning processes is pretty > slow from Git for

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jonathan Tan wrote: > Signed-off-by: Jonathan Tan > --- > connect.c| 3 +++ > t/t5512-ls-remote.sh | 39 +++ > 2 files changed, 42 insertions(+) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote: > I'd be more interested in the pain of this transition if there was a > concrete use case for "hide literally all refs, but still allow > fetches". Is that a thing that people do? > Not yet, I would think. Not to derail the

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On 09/02/2016 01:13 PM, Jeff King wrote: On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote: (git-daemon should probably also be changed to serve zero IDs, but such a change can be considered independently from this change; even if both the client and server changes were made in one

Bug Report: Too many untracked files (gitignore)

The relevant repo is here: https://github.com/blevinstein/dotfiles My gitignore file looks like this: https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore It basically ignores all files, except for specifically whitelisted files. However, when I run

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote: > The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities > with no refs in upload service., 2013-08-08), JGit's ref advertisement > includes > a ref named capabilities^{} to advertise its capabilities on, while

Re: Bug Report: Too many untracked files (gitignore)

On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein wrote: > The relevant repo is here: > https://github.com/blevinstein/dotfiles > > My gitignore file looks like this: > https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore > It

[PATCH v2 2/2] connect: advertized capability is not a ref

When cloning an empty repository served by standard git, "git clone" produces the following reassuring message: $ git clone git://localhost/tmp/empty Cloning into 'empty'... warning: You appear to have cloned an empty repository. Checking connectivity... done.

[PATCH v2 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh

This enables JGIT to be used as a prereq in invocations of test_expect_success (and other functions) in other test scripts. Signed-off-by: Jonathan Tan --- t/t5310-pack-bitmaps.sh | 4 t/test-lib.sh | 4 2 files changed, 4 insertions(+), 4

[PATCH v2 0/2] handle empty spec-compliant remote repos correctly

Thanks - I've updated the following: o better patch description as suggested by Jonathan Nieder o checking for capabilities^{} - all such lines are ignored without any further checks, similar to the behavior for .have o minor fix to test_lazy_prereq GIT_DAEMON o test waits for output of `jgit

Re: Fixup of a fixup not working right

From: "Robert Dailey" Suppose I have a branch with 4 commits, in the following order (as you might see during interactive rebase): pick 123 Original Change pick 789 fixup! Original Change pick 456 Some Other Thing pick abc fixup! fixup! Original Change However, let's

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jeff King wrote: > On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote: > But combining hideRefs with > allowTipSHA1InWant could trigger this case. Yes. [...] > I'd be more interested in the pain of this transition if there was a > concrete use case for

[PATCH 1/9] rebase -i: generate the script via rebase--helper

The first step of an interactive rebase is to generate the so-called "todo script", to be stored in the state directory as "git-rebase-todo" and to be edited by the user. Originally, we adjusted the output of `git log ` using a simple sed script. Over the course of the years, the code became more

Re: Bug Report: Too many untracked files (gitignore)

The patterns in question do contain a slash, although they don't start with a slash. I tried changing it to "!/.vim/colors/*" as you recommended, with no change in behavior. I even tried adding a leading slash to every pattern in gitignore, with no effect. Removing the line with

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

On Fri, Sep 02, 2016 at 04:51:45PM -0700, Jonathan Nieder wrote: > > I'd be more interested in the pain of this transition if there was a > > concrete use case for "hide literally all refs, but still allow > > fetches". Is that a thing that people do? > > Sure, it is a thing that people do. For

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 2, 2016 at 1:13 PM, Jeff King wrote: > > Hmm. So since this is backwards-compatible, I'm not overly concerned > with changing the client. But I wonder if you considered that the > documentation is wrong, and that JGit should stop sending the extra > capabilities line?

[PATCH] xdiff: remove unneeded declarations

Signed-off-by: Stefan Beller --- xdiff/xemit.c | 9 - 1 file changed, 9 deletions(-) diff --git a/xdiff/xemit.c b/xdiff/xemit.c index 49aa16f..b52b4b9 100644 --- a/xdiff/xemit.c +++ b/xdiff/xemit.c @@ -22,15 +22,6 @@ #include "xinclude.h" - - - -static long

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Stefan Beller wrote: > On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote: >> I'd be more interested in the pain of this transition if there was a >> concrete use case for "hide literally all refs, but still allow >> fetches". Is that a thing that people do? [...] > Not to derail the

What's cooking in git.git (Sep 2016, #01; Fri, 2)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Git 2.10 has been tagged. In a

A note from the maintainer

Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports

[ANNOUNCE] Git v2.10.0

The latest feature release Git v2.10.0 is now available at the usual places. It is comprised of 639 non-merge commits since v2.9.0, contributed by 76 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

On Fri, Sep 02, 2016 at 07:03:30PM -0700, Shawn Pearce wrote: > > Is it useful for upload-pack? If we have no refs, there's traditionally > > been nothing to fetch. Perhaps that's something that could change, > > though. For example, there could be a capability to allow fetching > > arbitrary

[RFC/PATCH 2/2] WIP xdiff: markup duplicates differently

When moving code (e.g. a function is moved to another part of the file or to a different file), the review process is different than reviewing new code. When reviewing moved code we are only interested in the diff as where there are differences in the moved code, e.g. namespace changes. However

[RFC/PATCH 0/2] Color moved code differently

When moving code (e.g. a function is moved to another part of the file or to a different file), the review process is different than reviewing new code. When reviewing moved code we are only interested in the diff as where there are differences in the moved code, e.g. namespace changes. However

[PATCH 1/2] diff.c: emit duplicate lines with a different color

Color is WIP, I just make space for a different case. Signed-off-by: Stefan Beller --- diff.c | 26 ++ diff.h | 4 +++- 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/diff.c b/diff.c index 534c12e..57d435c 100644 --- a/diff.c +++

Re: Fixup of a fixup not working right

"Philip Oakley" writes: > As I understand this it's implied by design. The issue is that the > rebase is looking for that named commit within its current rebase > range, and can't find it, so ignores it. > > There is a separate issue that all the fixup! fixup! messages are

Re: [PATCH] sequencer: support folding in rfc2822 footer

Jonathan Tan writes: > Sample-field: multiple-line field body > that causes a blank line below I am not sure this is unconditionally good, or may cause problems to those with workflows you did not consider when you wrote this patch. Not being too lenient here

Re: bug: 'core.logallrefupdates' is not set by default in non-bare repository

On Fri, Sep 02, 2016 at 04:04:16AM -0400, Jeff King wrote: > So here's the minimal fix that seems to work for me: > > diff --git a/builtin/init-db.c b/builtin/init-db.c > index 3a45f0b..56e7b9a 100644 > --- a/builtin/init-db.c > +++ b/builtin/init-db.c I also wonder if "clone" should be doing

Re: bug: 'core.logallrefupdates' is not set by default in non-bare repository

On vr, 2016-09-02 at 04:04 -0400, Jeff King wrote: > On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote: > > > > > > > > > We may need to do something like turn off the > > > need_shared_repository_from_config in init-db, since I think it would > > > not want to ever read from

Re: bug: 'core.logallrefupdates' is not set by default in non-bare repository

On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote: > > We may need to do something like turn off the > > need_shared_repository_from_config in init-db, since I think it would > > not want to ever read from the default config sources in most of its > > code-paths (OTOH, it should

[PATCH 0/2] Let the sequencer handle the grunt work of rebase -i

After all of these patch series y'all had to review, this is finally the one that switches things over. Please note that it does not (yet) handle the `git rebase -i --root` invocation; I tried to focus on the common case, and I rarely use --root myself. Please note also that --preserve-merges is

[PATCH 1/2] Add a builtin helper for interactive rebases

Git's interactive rebase is still implemented as a shell script, despite its complexity. This implies that it suffers from the portability point of view, from lack of expressibility, and of course also from performance. The latter issue is particularly serious on Windows, where we pay a hefty

[PATCH 2/2] rebase -i: use the rebase--helper builtin

Now that the sequencer learned to process a "normal" interactive rebase, we use it. The original shell script is still used for "non-normal" interactive rebases, i.e. when --root or --preserve-merges was passed. Please note that the --root option (via the $squash_onto variable) needs special

Git in Outreachy December-March?

As some of you may recall, we signed up to participate in Outreachy for the May-August session, but did not end up selecting an intern. The original thread with details is here: http://public-inbox.org/git/20160308224625.ga29...@sigill.intra.peff.net/ There's another session that runs from

Re: bug: 'core.logallrefupdates' is not set by default in non-bare repository

On Fri, Sep 02, 2016 at 11:01:54AM +0200, Dennis Kaarsemaker wrote: > Well, 'git init' is a valid operation to run inside an existing repo to > reinitialize some bits, so we definitely need to not ignore the config > once we're sure we're not creating a new repo. Good point, I hadn't considered

Re: Git in Outreachy December-March?

Probably off-topic. On Fri, Sep 2, 2016 at 2:32 PM, Jeff King wrote: > As some of you may recall, we signed up to participate in Outreachy for > the May-August session, but did not end up selecting an intern. The > original thread with details is here: > >

Re: bitmap creation failed

On Fri, Sep 02, 2016 at 12:04:54PM +0530, Arumuga wrote: > So I understand now, the following. > > 1. reducing the pack file size will increase the clone time > 2. Single pack file is expected to better use bitmap feature. > > Am i correct ? Yes, on both. -Peff

Re: [PATCH 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands

Hi Dennis, On Thu, 1 Sep 2016, Dennis Kaarsemaker wrote: > On do, 2016-09-01 at 17:17 +0200, Johannes Schindelin wrote: > > > And I see that the beautiful ordinal computation was given up in favor > > of a lousy "#1", "#2", "#3", etc (it used to be "1st", "2nd", "3rd" > > etc). > > > > In any

Re: [PATCH v2] t/Makefile: add a rule to re-run previously-failed tests

Hi Junio, On Thu, 1 Sep 2016, Junio C Hamano wrote: > Hopefully that [patch removing the - suffix] would help making > Dscho's "what are the failed tests?" logic simpler. Of course. It also makes sure that those 2 hours I spent on writing and perfecting the sed magic were spent in vain... ;-)

Re: [PATCH 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands

Hi Junio, On Thu, 1 Sep 2016, Junio C Hamano wrote: > For those who were not paying attention on the 'master' front during > this pre-release period [*1*], I have to point out that the scripted > Porcelain has been updated to lose the Anglo-centric st/nd/rd/th and > this series would want to get

Re: [PATCH 27/34] sequencer (rebase -i): differentiate between comments and 'noop'

Hi Dennis, On Thu, 1 Sep 2016, Dennis Kaarsemaker wrote: > /* >  * Note that ordering matters in this enum. Not only must it match the >  * mapping below, it is also divided into several sections that matter. >  * When adding new commands, make sure you add it in the right section. >  */ > enum

Re: [PATCH v2] t/Makefile: add a rule to re-run previously-failed tests

On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin wrote: > Hi Ævar, > > On Wed, 31 Aug 2016, Ævar Arnfjörð Bjarmason wrote: > >> I haven't used it myself (or any Windows thing) but people say good >> things about http://strawberryperl.com > > Ah yes. This comes up

Re: [PATCH 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands

On vr, 2016-09-02 at 09:13 +0200, Johannes Schindelin wrote: > As Git for Windows does not ship with translations (for multiple > reasons), it would not be a regression. I'm confused, how does "git for windows does not ship with translations" translate to "this is not a regression"? Is this

Re: [PATCH v2] t/Makefile: add a rule to re-run previously-failed tests

Hi Ævar, On Fri, 2 Sep 2016, Ævar Arnfjörð Bjarmason wrote: > On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin > wrote: > > > The biggest problem with Strawberry Perl is that it is virtually > > impossible to build the Subversion-Perl bindings using the Git for >

Re: [PATCH 00/22] Prepare the sequencer for the upcoming rebase -i patches

W dniu 29.08.2016 o 10:03, Johannes Schindelin pisze: > This patch series marks the '4' in the countdown to speed up rebase -i > by implementing large parts in C. It is based on the `libify-sequencer` > patch series that I submitted last week. Which of those got reviewed (and perhaps accepted),