Re: [PATCH 0/8] consistent "-h" handling in builtins

The series was pretty straight-forward. Thanks for working on this.

Re: [PATCH 1/8] am: handle "-h" argument earlier

Jeff King writes: > We can't easily move that setup to after the parse_options() > call; the point is to set up defaults that are overwritten > by the option parsing. Instead, we'll detect the "-h" case > early and show the usage then. This matches the behavior of > other builtins

Re: [PATCHv2 0/8] A reroll of sb/submodule-blanket-recursive

Stefan Beller writes: > v2: > * A reroll of sb/submodule-blanket-recursive. > * This requires ab/grep-preparatory-cleanup 2/8 seems to be more stale than sb/checkout-recurse-submodules that was merged at f1101cef to 'master'. I'll try to merge Ævar's series to 'master'

[PATCH 8/8] t0012: test "-h" with builtins

Since commit 99caeed05 (Let 'git -h' show usage without a git dir, 2009-11-09), the git wrapper handles "-h" specially, skipping any repository setup but still calling the builtin's cmd_foo() function. This means that every cmd_foo() must be ready to handle this case, but we don't have any

[PATCH 7/8] git: add hidden --list-builtins option

It can be useful in the test suite to be able to iterate over the list of builtins. We could do this with some Makefile magic. But since the authoritative list is in the commands array inside git.c, and since this could also be handy for debugging, let's add a hidden command-line option to dump

[PATCH 6/8] version: convert to parse-options

The "git version" command didn't traditionally accept any options, and in fact ignores any you give it. When we added simple option parsing for "--build-options" in 6b9c38e14, we didn't improve this; we just loop over the arguments and pick out the one we recognize. Instead, let's move to a real

[PATCH 5/8] submodule--helper: show usage for "-h"

Normal users shouldn't ever call submodule--helper, but it doesn't hurt to give them a normal usage message if they try "-h". Signed-off-by: Jeff King --- The usage message isn't that helpful _either_, and I admit my ulterior motive is just to make the test at the end of this

[PATCH 4/8] remote-{ext,fd}: print usage message on invalid arguments

We just say "Expected two arguments" when we get a different number of arguments, but we can be slightly friendlier. People shouldn't generally be running remote helpers themselves, but curious users might say "git remote-ext -h". Signed-off-by: Jeff King --- According to

[PATCH 3/8] upload-archive: handle "-h" option early

Normally upload-archive forks off upload-archive--writer to do the real work, and relays any errors back over the sideband channel. This is a good thing when the command is properly invoked remotely via ssh or git-daemon. But it's confusing to curious users who try "git upload-archive -h". Let's

[PATCH 2/8] credential: handle invalid arguments earlier

The git-credential command only takes one argument: the operation to perform. If we don't have one, we complain immediately. But if we have one that we don't recognize, we don't notice until after we've read the credential from stdin. This is likely to confuse a user invoking "git credential -h",

[PATCH 1/8] am: handle "-h" argument earlier

If the user provides "-h" on the command line, then our parse_options() invocation will show a usage message and quit. But if "-h" is the only argument, the git wrapper behaves specially: it ignores our RUN_SETUP flag and calls cmd_am() without having done repository setup at all. This is due to

[PATCH 0/8] consistent "-h" handling in builtins

On Mon, May 29, 2017 at 11:32:50AM -0400, Jeff King wrote: > I'll try to put together patches in the next day or so. Comments welcome > in the meantime. So here they are. For those just joining us, the immediate problem is that "git am -h" is broken (whether you're in a repo or not). That's

Re: [PATCH v4 02/10] rebase -i: generate the script via rebase--helper

Johannes Schindelin writes: > Hi Junio, > > On Mon, 29 May 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > diff --git a/sequencer.c b/sequencer.c >> > index 130cc868e51..88819a1a2a9 100644 >> > --- a/sequencer.c >> >

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Johannes Sixt writes: >> Doesn't this need test_i18ngrep?: > > Good catch! It would be this one in warn_on_inaccessible: > >> wrapper.c:581: warning_errno(_("unable to access '%s'"), path); > > But actually, I'm more worried about the unholy mix of >

Re: [PATCH] completion: Add completions for git config commit

Will queue; thanks.

Re: [PATCH] doc: Improve description for rev-parse --short

Andreas Heiduk writes: > First: `git rev-parse --short` without a number does use a fixed default but > `core.abbrev` which in turn uses `find_unique_abbrev` internally. ... hence the value gives mere minumum. I like your updated text that clarifies this point. > Second:

Re: [PATCHv3 1/4] clone: respect additional configured fetch refspecs during initial fetch

On Tue, May 30, 2017 at 12:53:47PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > On Fri, May 26, 2017 at 12:04:03PM +0200, SZEDER Gábor wrote: > > > >> Unfortunately, putting the default refspec into this temporary > >> configuration environment breaks a few submodule

Re: [PATCHv3 1/4] clone: respect additional configured fetch refspecs during initial fetch

Jeff King writes: > On Fri, May 26, 2017 at 12:04:03PM +0200, SZEDER Gábor wrote: > >> Unfortunately, putting the default refspec into this temporary >> configuration environment breaks a few submodule tests >> (t5614-clone-submodules or t5614-clone-submodules-shallow (it's got >>

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

Junio C Hamano writes: > If you are depending on a single topic in 'next', it is better to > build on the tip of that topic, not on 'next', if you can figure out > where the tip is. In practice, while we are exchanging patches via > e-mail, there should be no noticeable

Re: FORMAT_PATCH_NAME_MAX increase

Laszlo Ersek writes: > would it be possible to > > - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128? > > - Or else to introduce a new git-config knob for it? It's open source, so both are "possible", but you are interested in learning if these are acceptable

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: >> That's right. There might be some code sharing opportunity with Ben's >> code that is already in "next": >> https://github.com/git/git/blob/next/convert.c#L660-L677 >> >> Would it be useful for you if I send v5 with the changes rebased >>

Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

Duy Nguyen writes: >> * Add a new config variable `core.version`. E.g. `core.version = >>2.14.0` With this the user can specify that they'd like >>new/experimental features introduced in that version (and below), >>as well as immediately getting new deprecations

Re: mergetool: what to do about deleting precious files?

"Philip Oakley" writes: > If I now understand correctly, the merge process flow is: > > * canonicalise content (eol, smudge-clean, $id, renormalise, etc) > * diff the content (internal, or GIT_EXTERNAL_DIFF) > * apply the diff > * if conflicts, only then use

Re: What's cooking in git.git (May 2017, #08; Mon, 29)

Samuel Lijin writes: > "git status --ignored" previously did not list ignored files in > untracked directories without -uall, contrary to the documented > behavior of the --ignored flag (that all ignored files would be > listed). This has also been corrected. It's a

[PATCH 2/2] treewide: use is_missing_file_error() where ENOENT and ENOTDIR are checked

Using the is_missing_file_error() helper introduced in the previous step, update all hits from $ git grep -e ENOENT --and -e ENOTDIR There are codepaths that only check ENOENT, and it is possible that some of them should be checking both. Updating them is kept out of this step deliberately,

[PATCH 1/2] compat-util: is_missing_file_error()

Our code often opens a path to an optional file, to work on its contents when we can successfully open it. We can ignore a failure to open if such an optional file does not exist, but we do want to report a failure in opening for other reasons (e.g. we got an I/O error, or the file is there, but

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Johannes Sixt writes: > I would prefer to catch the case in the compatibility layer. Here is > a two patch series that would replace your 12/13 and 13/13. Thanks. It is good that I can drop that last one. Will replace (with a SQUASH??? for 1/2).

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Ramsay Jones writes: > See commit c7018be509 ("test: allow skipping the remainder", 18-05-2017) > which is currently merged to the 'next' branch (merge 03b8a61e47 of the > 'jc/skip-test-in-the-middle' branch). > > (see also http://testanything.org) > > If you look at

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Johannes Sixt writes: > Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason: >> On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote: >>> diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh >>> index b195f71ea9..fd719a209e 100755 >>> ---

Re: [PATCH/RFC] branch: add tests for new copy branch feature

On Mon, May 29, 2017 at 10:50 PM, Ævar Arnfjörð Bjarmason wrote: > On Mon, May 29, 2017 at 10:41 PM, Sahil Dua wrote: >> On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason >> wrote: >>> On Mon, May 29, 2017 at 12:56 AM, Sahil Dua

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

On 29/05/17 22:02, Johannes Sixt wrote: > Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason: >> On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote: >>> diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh >>> index b195f71ea9..fd719a209e 100755 >>> ---

Re: Error with Templates: Could not find templates on cloning but on creating

Am 29.05.2017 um 13:20 schrieb Mathias Artus: Hi, Today i've tried to set up a template directory. I added in the system wide gitconfig the following lines: [init] templatedir = "//OurServer/SomeDirectory/GitTemplate" Where //Ourserver is a Network Path. With

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason: On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote: diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh index b195f71ea9..fd719a209e 100755 --- a/t/t5580-clone-push-unc.sh +++ b/t/t5580-clone-push-unc.sh

Re: [PATCH/RFC] branch: add tests for new copy branch feature

On Mon, May 29, 2017 at 10:41 PM, Sahil Dua wrote: > On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason > wrote: >> On Mon, May 29, 2017 at 12:56 AM, Sahil Dua wrote: >>> New feature - copying a branch along with its config

Re: [PATCH/RFC] branch: add tests for new copy branch feature

On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason wrote: > On Mon, May 29, 2017 at 12:56 AM, Sahil Dua wrote: >> New feature - copying a branch along with its config section. >> >> Aim is to have an option -c for copying a branch just like -m

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote: > Am 26.05.2017 um 05:35 schrieb Junio C Hamano: >> When asked to open/fopen a path, e.g. "a/b:/c", which does not exist >> on the filesystem, Windows (correctly) fails to open it but sets >> EINVAL to errno because the

[GSoC] Update: Week 2

SUMMARY OF MY PROJECT: Git submodule subcommands are currently implemented by using shell script 'git-submodule.sh'. There are several reasons why we'll prefer not to use the shell script. My project intends to convert the subcommands into C code, thus making them builtins. This will increase

[PATCH 2/2] mingw_fopen: report ENOENT for invalid file names

On Windows, certain characters are prohibited in file names, most prominently the colon. When fopen() is called with such an invalid file name, the underlying Windows API actually reports a particular error, but since there is no suitable errno value, this error is translated to EINVAL. Detect

[PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Am 26.05.2017 um 05:35 schrieb Junio C Hamano: > When asked to open/fopen a path, e.g. "a/b:/c", which does not exist > on the filesystem, Windows (correctly) fails to open it but sets > EINVAL to errno because the pathname has characters that cannot be > stored in its filesystem. > > As this is

Re: [PATCH/RFC] branch: add tests for new copy branch feature

Thanks, Junio for raising all these important questions. Indeed, showing tests in order to explain my thinking about the feature was a bad idea. I realise that I should have explained the feature first instead of getting the tests reviewed without any elaboration of the intentions. I will explain

Re: [PATCH v3 4/4] stash: implement builtin stash

On Mon, May 29, 2017 at 8:18 PM, Joel Teichroeb wrote: > Once I have all those leaks fixed, is there a way to make sure I'm not > missing any? I tried using valgrind with leak-check enabled, but there > are too many leaks from other git commands. I just used: valgrind

Re: [PATCH v3 4/4] stash: implement builtin stash

Once I have all those leaks fixed, is there a way to make sure I'm not missing any? I tried using valgrind with leak-check enabled, but there are too many leaks from other git commands. Joel

Re: [Bug] setup_git_env called without repository

On Mon, May 29, 2017 at 03:01:11PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Mon, May 29, 2017 at 1:45 PM, Zero King wrote: > > After upgrading to Git 2.13.0, I'm seeing the following error message > > when running `git am -h`. > > > >$ git am -h > >fatal: BUG:

Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

On Mon, May 29, 2017 at 01:20:02PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> * Add a new config variable `core.version`. E.g. `core.version = > >>2.14.0` With this the user can specify that they'd like > >>new/experimental features introduced in that version (and below), > >>as well

Re: [Bug] setup_git_env called without repository

On Mon, May 29, 2017 at 1:45 PM, Zero King wrote: > After upgrading to Git 2.13.0, I'm seeing the following error message > when running `git am -h`. > >$ git am -h >fatal: BUG: setup_git_env called without repository > > And with Git built from the next branch: > >

Re: mergetool: what to do about deleting precious files?

From: "Junio C Hamano" "Philip Oakley" writes: So I do not think this is not limited to "new file". Anything that a tree-level three-way merge would resolve cleanly without having to consult the content-level three-way merge will complete without

Re: [PATCH v4 00/10] The final building block for a faster rebase -i

On Mon, May 29, 2017 at 12:51 PM, Johannes Schindelin wrote: > Hi René, > > On Sat, 27 May 2017, René Scharfe wrote: > >> Am 26.05.2017 um 05:15 schrieb Liam Beguin: >> > I tried to time the execution on an interactive rebase (on Linux) but >> > I did not notice a

[Bug] setup_git_env called without repository

Hi, After upgrading to Git 2.13.0, I'm seeing the following error message when running `git am -h`. $ git am -h fatal: BUG: setup_git_env called without repository And with Git built from the next branch: $ git am -h BUG: environment.c:172: setup_git_env called without repository

Re: [WIP/RFC 00/23] repository object

On Mon, May 29, 2017 at 6:23 PM, Ævar Arnfjörð Bjarmason wrote: >>> That said, even if we never reached the point where we could handle all >>> submodule requests in-process, I think sticking the repo-related global >>> state in a struct certainly could not hurt general

Error with Templates: Could not find templates on cloning but on creating

Hi, Today i've tried to set up a template directory. I added in the system wide gitconfig the following lines: [init] templatedir = "//OurServer/SomeDirectory/GitTemplate" Where //Ourserver is a Network Path. With this line i can create a new Repository and the

Re: [PATCH v4 10/10] rebase -i: rearrange fixup/squash lines using the rebase--helper

Hi Liam, On Thu, 25 May 2017, Liam Beguin wrote: > Johannes Schindelin writes: > [...] > > + if (rearranged) { > > + struct strbuf buf = STRBUF_INIT; > > + > > + for (i = 0; i < todo_list.nr; i++) { > > + enum todo_command

Re: [WIP/RFC 00/23] repository object

On Mon, May 29, 2017 at 12:36 PM, Duy Nguyen wrote: > On Tue, May 23, 2017 at 2:35 AM, Jeff King wrote: >> On Thu, May 18, 2017 at 04:21:11PM -0700, Brandon Williams wrote: >> >>> When I first started working on the git project I found it very difficult to >>>

Re: [PATCH v4 05/10] rebase -i: also expand/collapse the SHA-1s via the rebase--helper

Hi Liam, On Thu, 25 May 2017, Liam Beguin wrote: > Johannes Schindelin writes: > > > diff --git a/builtin/rebase--helper.c b/builtin/rebase--helper.c > > index 821058d452d..9444c8d6c60 100644 > > --- a/builtin/rebase--helper.c > > +++ b/builtin/rebase--helper.c > >

Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

On Mon, May 29, 2017 at 12:23 PM, Duy Nguyen wrote: > On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason > wrote: >> This is the WIP start of a deprecation & experimental interface to >> git. The goal is to formalize the workflow around deprecating >>

Re: git worktrees must exist even if locked

On Thu, May 11, 2017 at 3:24 AM, taylor, david wrote: > The Git documentation in describing worktrees says that one reason > why you might want to lock a worktree is to prevent it from being pruned > if it is on a removable media that isn't currently mounted. > > So, my

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

> On 23 May 2017, at 10:43, Lars Schneider wrote: > > >> On 23 May 2017, at 07:22, Junio C Hamano wrote: >> >> Lars Schneider writes: >> > + sigchain_pop(SIGPIPE); > + > + if (err || errno == EPIPE) {

Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

On Mon, May 29, 2017 at 3:09 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN >> index 4f94fc7574..c76bbedf86 100755 >> --- a/GIT-VERSION-GEN >> +++ b/GIT-VERSION-GEN >> @@ -37,4 +37,5 @@ fi >>

Re: [PATCH v4 02/10] rebase -i: generate the script via rebase--helper

Hi Liam, On Thu, 25 May 2017, Liam Beguin wrote: > Johannes Schindelin writes: > > > diff --git a/sequencer.c b/sequencer.c > > index 130cc868e51..88819a1a2a9 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -2388,3 +2388,52 @@ void append_signoff(struct

Re: [PATCH v4 00/10] The final building block for a faster rebase -i

Hi Liam, On Thu, 25 May 2017, Liam Beguin wrote: > Johannes Schindelin writes: > > This patch series reimplements the expensive pre- and post-processing of > > the todo script in C. > > > > [...] I see that you used git-send-email to send this. It did look a bit

Re: [PATCH v4 02/10] rebase -i: generate the script via rebase--helper

Hi Junio, On Mon, 29 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/sequencer.c b/sequencer.c > > index 130cc868e51..88819a1a2a9 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -2388,3 +2388,52 @@ void

Re: [PATCH v4 00/10] The final building block for a faster rebase -i

Hi René, On Sat, 27 May 2017, René Scharfe wrote: > Am 26.05.2017 um 05:15 schrieb Liam Beguin: > > I tried to time the execution on an interactive rebase (on Linux) but > > I did not notice a significant change in speed. > > Do we have a way to measure performance / speed changes between

Re: [WIP/RFC 00/23] repository object

On Tue, May 23, 2017 at 2:35 AM, Jeff King wrote: > On Thu, May 18, 2017 at 04:21:11PM -0700, Brandon Williams wrote: > >> When I first started working on the git project I found it very difficult to >> understand parts of the code base because of the inherently global nature of >>

Re: [RFC/PATCH] WIP: add deprecation & experimental process/interface

On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason wrote: > This is the WIP start of a deprecation & experimental interface to > git. The goal is to formalize the workflow around deprecating > features, or around introducing new experimental features. > > This is much more

Re: git worktrees must exist even if locked

On Tue, May 16, 2017 at 5:43 AM, Junio C Hamano wrote: > "taylor, david" writes: > >> The original report was against Git v2.12.2. I have since tried v2.12.3, >> v2.13.0, >> and the next branch. All exhibit the same symptoms. >> >> Even if you ignore

_3gрaвcтвуйтe! Bac интeрecуют kлиeнтckиe бaзы gaнных?

_3qpавсmвyйme! Bас инmepeсyюm kлиeнmсkиe 6азы qанныx?

Re: ~Setting Up Charity Foundation !.

`._.. Glad to write to you this message, I seek for your kind help in setting up a charitable organization to help the less privileged people and also the elderly people under your care, I was diagnosed of breast cancer and the doctors told me that i may not live long due to the bad stage of

FORMAT_PATCH_NAME_MAX increase

Hi, would it be possible to - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128? - Or else to introduce a new git-config knob for it? I have a small review-helper / interdiff script that matches patches from adjacent versions of a series against each other, based on subject line.

Re: [PATCH v4 00/10] The final building block for a faster rebase -i

Johannes Schindelin writes: > 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. > I took another look at the series (as "What's cooking" report was listing

Odp: Re: Dzial Kredytowy

Witam, Czy potrzebujesz zatwierdzony biznes i prywatnego kredytu / Finansowanie w maksymalnej wysokosci 3% w skali roku? Skontaktuj sie z nami po wiecej szczególów w razie zainteresowania. Dziekuje. BSN Capital Partners Ltd (London) Zarzadzanie. -- Angielska wersja

Re: What's cooking in git.git (May 2017, #08; Mon, 29)

On Mon, May 29, 2017 at 2:23 AM, Junio C Hamano wrote: > * sl/clean-d-ignored-fix (2017-05-24) 6 commits > (merged to 'next' on 2017-05-29 at 837c255ae8) > + clean: teach clean -d to preserve ignored paths > + dir: expose cmp_name() and check_contains() > + dir: hide

Re: [PATCH] wildmatch test: remove redundant duplicate test

On Mon, May 29, 2017 at 2:54 AM, Junio C Hamano wrote: > Thanks. Did you run "sort | uniq -c" on it or something ;-)? I've been writing a new backend for wildmatch(). Was wondering what the difference in these two failing tests was, turns out there was none. > Will apply.

Re: [PATCH v3 4/4] stash: implement builtin stash

Joel Teichroeb writes: > +int untracked_files(struct strbuf *out, int include_untracked, > + const char **argv) Does this need to be public? For a caller that wants to learn if there is _any_ untracked file, having a strbuf that holds all output is overkill.

Re: [PATCH v3 3/4] close the index lock when not writing the new index

Joel Teichroeb writes: > Signed-off-by: Joel Teichroeb > --- The title says what the patch does; it does not explain why it is a good change. Lockfiles will be closed automatically when we exit anyway, so one can argue that the current code is good. If

Re: [PATCH v3 2/4] stash: add test for stashing in a detached state

Joel Teichroeb writes: > Signed-off-by: Joel Teichroeb > --- > t/t3903-stash.sh | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh > index aaae221304..b86851ef46 100755 > --- a/t/t3903-stash.sh > +++

Re: [PATCH v3 1/4] stash: add test for stash create with no files

Ævar Arnfjörð Bjarmason writes: >> + git stash create > actual && >> + test $(cat actual | wc -l) -eq 0 > ... > Although I wonder in this case whether you don't actually mean: > > [...]>actual && > ! test -s actual > > I.e. isn't the test that there should

What's cooking in git.git (May 2017, #08; Mon, 29)

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. A bit more topics are now in

Re: [PATCH v4 02/10] rebase -i: generate the script via rebase--helper

Johannes Schindelin writes: > diff --git a/sequencer.c b/sequencer.c > index 130cc868e51..88819a1a2a9 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -2388,3 +2388,52 @@ void append_signoff(struct strbuf *msgbuf, int > ignore_footer, unsigned flag) > >