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

On Fri, Sep 09, 2016 at 10:36:28AM -0700, Jonathan Tan wrote: [] > diff --git a/t/test-lib.sh b/t/test-lib.sh > index d731d66..c9c1037 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -1072,6 +1072,10 @@ test_lazy_prereq NOT_ROOT ' > test "$uid" != 0 > ' > > +test_lazy_prereq JGIT

Re: git clone http:// fails some times with "Request for d53.. aborted"

(Not sure how much time I'll have to continue in the next few weeks, just jotting down my debugging progress so far...) Yaroslav Halchenko wrote: > even when (v 2.7.0) ran on the box where the server is, so > unlikely to be network issue > > or from my laptop (v 2.9.3)

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

> As you know currently the checkout doesn't touch submodules, i.e. > you have to run "git submodule update" whenever the submodule > changes. So when you checkout a different part of history, that moved > a submodule, this will fail as the submodule still resides at the old > place (and may have

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

On Fri, Sep 9, 2016 at 4:37 PM, Dakota Hawkins wrote: > Any ideas on this anywhere? > > In my opinion if a merge can fast-forward without conflict it should > trivially be able to non-fast-forward without conflict. Yes, I agree. Though the submodules still have a lot of

Re: [RFC/PATCH] ls-files: adding support for submodules

On Fri, Sep 9, 2016 at 4:01 PM, Junio C Hamano wrote: > Brandon Williams writes: > >> Allow ls-files to recognize submodules in order to retrieve a list of >> files from a repository's submodules. This is done by forking off a >> process to recursively call

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

Any ideas on this anywhere? In my opinion if a merge can fast-forward without conflict it should trivially be able to non-fast-forward without conflict. Also, I'm not too familiar/comfortable with mailing list etiquette, and I don't want to be a bother by continuing to ping this thread. Thanks,

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

You guys are the best, I'm really impressed with all of the responses to this issue! Thank you all for all of your hard work! Dakota On Fri, Sep 9, 2016 at 3:00 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Johannes Schindelin

Re: How to simulate a real checkout to test a new smudge filter?

john smith writes: > ... get it. The problem is that in the scenario presented in my last > e-mail clean filter is run in the situation which doesn't like a > checkin to me. Is `git checkout ' doing a *checkin*" under the > hood so that the clean filter is called? What does

Re: How to simulate a real checkout to test a new smudge filter?

On 9/10/16, Junio C Hamano wrote: > The clean and smudge operations should look _only_ at the contents > they are filtering, and nothing else, and the clean/smudge filtering > mechanism is designed to support that use case. It is not designed > to do things like embedding the

Re: [RFC/PATCH] ls-files: adding support for submodules

Brandon Williams writes: > Allow ls-files to recognize submodules in order to retrieve a list of > files from a repository's submodules. This is done by forking off a > process to recursively call ls-files on all submodules. While I see why "ls-files --recurse-submodules"

git clone http:// fails some times with "Request for d53.. aborted"

even when (v 2.7.0) ran on the box where the server is, so unlikely to be network issue or from my laptop (v 2.9.3) with ok but wifi with a weakish signal to the access point: $> ( set -e; for s in {1..100}; do rm -rf fbirn_phaseIII ; git clone

What's cooking in git.git (Sep 2016, #03; Fri, 9)

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. I've started merging topics that

Re: [RFC/PATCH] ls-files: adding support for submodules

Jeff King writes: > So I suppose another option would be to teach ls-files a "prefix" option > to add to each filename, and just pass in the submodule path. Then you > can let the sub-processes write directly to the common stdout, and I > think it would be safe to blindly pass the

Re: [RFC/PATCH] ls-files: adding support for submodules

On Fri, Sep 09, 2016 at 02:53:24PM -0700, Brandon Williams wrote: > Allow ls-files to recognize submodules in order to retrieve a list of > files from a repository's submodules. This is done by forking off a > process to recursively call ls-files on all submodules. > > Signed-off-by: Brandon

Re: How to simulate a real checkout to test a new smudge filter?

john smith writes: > So it seems that clean filter is only run when checking out paths but > not when checking out branches. Is my thinking correct? If the new branch you are going to and your current branch record different contents for a path, that path will have to be

Re: How to simulate a real checkout to test a new smudge filter?

On 9/8/16, Jakub Narębski wrote: > W dniu 06.09.2016 o 23:01, john smith pisze: > >> I'd prefer smudge/clean filters instead of `make' scripts etc. to >> convert template dotfiles into something usable and back because >> filters: >> >> 1. could be run automatically >> >> 2. do

Re: [PATCH v2] checkout: eliminate unnecessary merge for trivial checkout

Ben Peart writes: > @@ -802,6 +806,87 @@ static void orphaned_commit_warning(struct commit *old, > struct commit *new) > free(refs.objects); > } > > +static int needs_working_tree_merge(const struct checkout_opts *opts, > + const struct branch_info *old, > +

[RFC/PATCH] ls-files: adding support for submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Signed-off-by: Brandon Williams --- Hey git developers! I'm new to the community

Git Ignore Exception bug

it ignore doesn't seem to be working properly when adding exceptions. Environment: Mac, running latest El Capitan (10.11.6) % git --version git version 2.9.0 ---cut here- #!/bin/sh TEMP=mktemp # Create a temporary repo mkdir repo cd repo git init echo "foo/*" >>

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

Josh Triplett writes: > It doesn't seem like a functional issue, but aesthetically it > doesn't look good. > > Do you plan to make that change to print an additional blank line > (likely inside print_bases), or should I? I do not mind doing it myself, but I am already in

Re: [PATCH v3 2/2] patch-ids: define patch-id of merge commits as "null"

Jeff King writes: > This patch defines the patch-id of a merge commit as > essentially "null"; it has no patch-id. As a result, > merges cannot match patch-ids via "--cherry-pick", and > "format-patch --base" will not list merges in its list of > prerequisite patch ids. At first

Re: [PATCH v5 0/3] handle empty spec-compliant remote repos correctly

Jonathan Tan wrote: > connect.c | 32 ++-- > t/t5310-pack-bitmaps.sh | 4 > t/t5512-ls-remote.sh| 40 > t/test-lib.sh | 4 > 4 files changed, 70 insertions(+), 10 deletions(-)

Re: [PATCH v3 0/2] patch-id for merges

Jeff King writes: > And here is v3. Besides commit-message fixups, it drops patch 2, and > instead the third patch teaches commit_patch_id() to distinguish between > errors and "no patch id". > > Frankly, I still like v2 better, but I do not feel like arguing with > Johannes about

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

On Fri, Sep 09, 2016 at 01:51:04PM -0700, Junio C Hamano wrote: > Josh Triplett writes: > > > On Fri, Sep 09, 2016 at 12:41:56PM -0700, Junio C Hamano wrote: > >> So here is a suggested replacement. I notice that in the MIME case, > >> we do not leave any blank line

Re: git commit -p with file arguments

Jakub Narębski writes: > Which means that with "git add -p && git commit ", > the "git add -p " would carefully craft the state > in the index... and "git commit " would take worktree version > of for commit, ignoring what was in the index :-( > > Currently there is no way

Re: [PATCH v4 3/3] connect: advertized capability is not a ref

Jonathan Nieder writes: > Jonathan Tan wrote: > >> --- a/connect.c >> +++ b/connect.c >> @@ -172,8 +173,24 @@ struct ref **get_remote_heads(int in, char *src_buf, >> size_t src_len, >> continue; >> } >> >> +if (!strcmp(name,

Re: git commit -p with file arguments

W dniu 09.09.2016 o 20:03, Junio C Hamano pisze: > Jacob Keller writes: > >> It wants to commit bar too because you already added bar before. It works >> like: >> >> "git add bar && git add -p foo && git commit" does it not? >> >> I fail to see why "git commit -p " would

Re: [PATCH v3 2/2] patch-ids: define patch-id of merge commits as "null"

On Fri, Sep 09, 2016 at 04:34:47PM -0400, Jeff King wrote: > This patch defines the patch-id of a merge commit as > essentially "null"; it has no patch-id. As a result, > merges cannot match patch-ids via "--cherry-pick", and > "format-patch --base" will not list merges in its list of >

[PATCH v3 2/2] patch-ids: define patch-id of merge commits as "null"

The patch-id code which powers "log --cherry-pick" doesn't look at whether each commit is a merge or not. It just feeds the commit's first parent to the diff, and ignores any additional parents. In theory, this might be useful if you wanted to find equivalence between, say, a merge commit and a

[PATCH v3 1/2] patch-ids: turn off rename detection

The patch-id code may be running inside another porcelain like "git log" or "git format-patch", and therefore may have set diff_detect_rename_default, either via the diff-ui config, or by default since 5404c11 (diff: activate diff.renames by default, 2016-02-25). This is the case even if a command

[PATCH v3 0/2] patch-id for merges

On Wed, Sep 07, 2016 at 06:01:01PM -0400, Jeff King wrote: > Here's a re-roll of the series I posted at: > > > http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsu...@sigill.intra.peff.net/ > > Basically, it drops the time for "format-patch --cherry-pick" on a > particular case from 3

Re: [RFCv3] Proposed questions for "Git User's Survey 2016", take three

Hello David, On 7 September 2016 at 20:49, David Bainbridge wrote: > Hi Jakub, > > I guess we could keep polishing this forever! > > Anyway, a couple of last comments from me: > 1. Could you use the new Git logo instead of the +++/ ? It would show > some clear

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

Updates from PATCH v4: o use fatal errors ("die") instead of warnings for protocol errors o reworded commit message - removed last sentence and wrote "(following the specification in pack-protocol.txt)" in one of the earlier paragraphs Jonathan Nieder (1): connect: tighten check for

[PATCH v5 3/3] 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 v5 1/3] 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 v5 2/3] connect: tighten check for unexpected early hang up

From: Jonathan Nieder A server hanging up immediately to mark access being denied does not send any .have refs, shallow lines, or anything else before hanging up. If the server has sent anything, then the hangup is unexpected. That is, if the server hangs up after a shallow

Re: [PATCH v4 3/3] connect: advertized capability is not a ref

Jonathan Tan writes: > Git advertises the same capabilities^{} ref in its ref advertisement for push > but since it never did so for fetch, the client didn't need to handle this > case. Handle it. > > In this aspect, JGit is compliant with the specification in

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

On Fri, Sep 09, 2016 at 12:41:56PM -0700, Junio C Hamano wrote: > So here is a suggested replacement. I notice that in the MIME case, > we do not leave any blank line between the last line of the patch > and the baseinfo, which makes it look a bit strange, e.g. output of > "format-patch

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

Junio C Hamano writes: > Jeff King writes: > >> On Thu, Sep 08, 2016 at 11:54:08AM -0700, Josh Triplett wrote: >> >>> > your problem description >>> > looks perfect. I am still not sure if the code does a reasonable >>> > thing in MIME case, though. >>> >>>

Re: [PATCH v4 3/3] connect: advertized capability is not a ref

Jonathan Tan wrote: > --- a/connect.c > +++ b/connect.c > @@ -172,8 +173,24 @@ struct ref **get_remote_heads(int in, char *src_buf, > size_t src_len, > continue; > } > > + if (!strcmp(name, "capabilities^{}")) { > + if

Re: [PATCH 2/3] diff_flush_patch_id: stop returning error result

On Fri, Sep 09, 2016 at 02:58:25PM +0200, Johannes Schindelin wrote: > > Yes, I agree that this is the opposite direction of libification. And I > > agree that the current message is not very helpful. > > > > But I am not sure that returning the error up the stack will actually > > help somebody

Re: [PATCH 2/3] checkout.txt: document a common case that ignores ambiguation rules

I'll queue the following as "fixup!" for now. It reminds me that the title also needs rewording; we do not have rules to make things ambiguous ;-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 46b04b1..8e2c066 100644 --- a/Documentation/git-checkout.txt +++

[PATCH v2] checkout: eliminate unnecessary merge for trivial checkout

Teach git to avoid unnecessary merge during trivial checkout. When running 'git checkout -b foo' git follows a common code path through the expensive merge_working_tree even when it is unnecessary. As a result, 95% of the time is spent in merge_working_tree doing the 2-way merge between the new

Re: [PATCH 07/13] i18n: merge-recursive: mark error messages for translation

Vasco Almeida writes: > Lowercase first word of such error messages following the usual style. "Change X to lowercase" is fine, but "Lowercase" is not a verb. I'd reword it to "Downcase the first word...". Other than that all 04-13/13 looked fine to me. Thanks.

Re: [PATCH 22/22] sequencer: refactor write_message()

Hello Johannes, W dniu 09.09.2016 o 16:40, Johannes Schindelin napisał: > On Fri, 2 Sep 2016, Jakub Narębski wrote: >> W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze: >>> On Thu, 1 Sep 2016, Jakub Narębski wrote: W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze: >> > if

Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

Hello Johannes, W dniu 09.09.2016 o 17:12, Johannes Schindelin napisał: > On Thu, 1 Sep 2016, Junio C Hamano wrote: >> Johannes Schindelin writes: >> I was sort of expecting that, when you do the preserve-merges mode >> of "rebase -i", you would need to jump around,

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Junio C Hamano writes: > Johannes Schindelin writes: > >> On Thu, 11 Aug 2016, Junio C Hamano wrote: >>> >>> Do you have a preference either way to help us decide if we want to >>> take this change or not? >> >> I have no strong preference. I

Re: Announcing Git User's Survey 2016 [was: Working with public-inbox.org]

Hello Johannes, W dniu 09.09.2016 o 15:06, Johannes Schindelin napisał: > On Sun, 28 Aug 2016, Jakub Narębski wrote: >> W dniu 28.08.2016 o 10:38, Johannes Schindelin pisze: >> >>> I would like to strongly caution against putting too much stock into >>> this users' survey. It is the best we have,

Re: [PATCH] git-gui: respect commit.gpgsign again

Johannes Schindelin writes: > As of v2.9.0, `git commit-tree` no longer heeds the `commit.gpgsign` > config setting. This broke committing in Git GUI. Thanks. Will shift it up to apply to my copy of git-gui project and then pull in the result. >

Re: [PATCH v3 17/17] sequencer: ensure to release the lock when we could not read the index

Johannes Schindelin writes: > A future caller of read_and_refresh_cache() may want to do more than just > print some helpful advice in case of failure. I recall commenting on unreleased locks on other parts of the series but didn't see this. Looks good. Thanks for

Re: [PATCH v3 16/17] lib'ify checkout_fast_forward_to()

Johannes Schindelin writes: > Instead of dying there, let the caller high up in the callchain > notice the error and handle it (by dying, still). > > The only callers of checkout_fast_forward_to(), cmd_merge(), > pull_into_void(), cmd_pull() and sequencer's

Re: [PATCH v3 3/4] cat-file --textconv/--filters: allow specifying the path separately

Johannes Schindelin writes: > +test_expect_success 'path= complains without --textconv/--filters' > ' I wonder where this "path" came from; it wasn't in v2 I queued, but somehow came back mysteriously. Will locally amend. > + sha1=$(git rev-parse -q

Re: git commit -p with file arguments

Jacob Keller writes: > It wants to commit bar too because you already added bar before. It works > like: > > "git add bar && git add -p foo && git commit" does it not? > > I fail to see why "git commit -p " would unstage the bar you > already added? Or am I missing some

Re: [PATCH v3 3/3] Use the newly-introduced regexec_buf() function

Johannes Schindelin writes: >> Also I agree with Peff that a test with an embedded NUL would be a >> good thing. > > This is something I will leave to somebody else, as it was not my > intention to fix this and I *really* have more pressing things to do right > now...

Re: [PATCH 2/3] t0001: work around the bug that reads config file before repo setup

On Fri, Sep 9, 2016 at 4:22 AM, Jeff King wrote: > If you're curious what the fix looks like, it's in: > > https://github.com/peff/git jk/config-repo-setup > > The actual fix is in the final patch, but it needed a lot of preparatory > work to avoid breaking various programs that

Re: [PATCH 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

Johannes Schindelin writes: >> Besides avoiding a segfault, one of the benefits of regcomp_buf() is >> that we will now find pickaxe-regex strings inside mixed binary/text >> files. But it's not clear to me that NetBSD's implementation does this. >> >> I guess we can

[PATCH v4 3/3] 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 v4 2/3] connect: tighten check for unexpected early hang up

From: Jonathan Nieder A server hanging up immediately to mark access being denied does not send any .have refs, shallow lines, or anything else before hanging up. If the server has sent anything, then the hangup is unexpected. That is, if the server hangs up after a shallow

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

Updates: o Included tighten-check patch from Jonathan Nieder and Junio C Hamano in this patch set o Updated commit message following Jonathan Nieder's suggestion o Updated warning messages to mention capabilities^{} As for warning vs die, I would prefer the "liberal" approach of continuing on

[PATCH v4 1/3] 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

Re: [PATCH v3 2/4] cat-file: introduce the --filters option

Junio C Hamano writes: > So I would not mind if we define the semantics of "--filters" as > such (as long as it is clearly documented, of course). AFAICS, the > batch interface does not call filter_object() for non-blobs, and by > returning successfully without doing anything

Re: [PATCH v3 2/4] cat-file: introduce the --filters option

Junio C Hamano writes: > Johannes Schindelin writes: > >>> > + if (type != OBJ_BLOB) { >>> > + free(*buf); >>> > + return error(_("blob expected for %s '%s'"), >>> > + sha1_to_hex(sha1), path); >>> > + } >>> > + if

Re: git commit -p with file arguments

Jacob Keller writes: > It wants to commit bar too because you already added bar before. It works > like: > > "git add bar && git add -p foo && git commit" does it not? > > I fail to see why "git commit -p " would unstage the bar you > already added? Or am I missing some

Re: git commit -p with file arguments

On Mon, Sep 5, 2016 at 2:08 PM, Christian Neukirchen wrote: > Hi, > > I noticed the following suprising behavior: > > % git --version > git version 2.10.0 > > % git add bar > % git status -s > A bar > M foo > > % git commit -p foo > [stage a hunk] > ... > # Explicit

Re: Missing RPM spec file in tarball

On Fri, Sep 9, 2016 at 9:19 AM, Sergio Martín Turiel wrote: > Hello, > > > I am trying to build RPM packages from tarball (release 2.9.3 and 2.10.0), > and i do not find git.spec file, in previous releases i can found it (e.g. > 2.8.3). > > O.S.: CentOS 7.2 > Command:

Re: Missing RPM spec file in tarball

Sergio Martín Turiel writes: > I am trying to build RPM packages from tarball (release 2.9.3 and > 2.10.0), and i do not find git.spec file, in previous releases i can > found it (e.g. 2.8.3). > > O.S.: CentOS 7.2 > Command: rpmbuild -ta git-2.9.3.tar.gz > Response:

Missing RPM spec file in tarball

Hello, I am trying to build RPM packages from tarball (release 2.9.3 and 2.10.0), and i do not find git.spec file, in previous releases i can found it (e.g. 2.8.3). O.S.: CentOS 7.2 Command: rpmbuild -ta git-2.9.3.tar.gz Response: error: Failed to read spec file from git-2.9.3.tar.gz Can

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Johannes Schindelin writes: > On Thu, 11 Aug 2016, Junio C Hamano wrote: >> >> Do you have a preference either way to help us decide if we want to >> take this change or not? > > I have no strong preference. I guess that it does not hurt to go with the > patch, and

Re: [PATCH v3 2/4] cat-file: introduce the --filters option

Johannes Schindelin writes: >> > + if (type != OBJ_BLOB) { >> > + free(*buf); >> > + return error(_("blob expected for %s '%s'"), >> > + sha1_to_hex(sha1), path); >> > + } >> > + if (S_ISREG(mode)) { >> > + struct strbuf

Re: [PATCH v3 2/4] cat-file: introduce the --filters option

Hi Junio, On Fri, 9 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > +static int filter_object(const char *path, unsigned mode, > > +const unsigned char *sha1, > > +char **buf, unsigned long *size) > > +{ >

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Hi Junio, On Thu, 11 Aug 2016, Junio C Hamano wrote: > Earlier, Peff sent this patch (slightly buried in a discussion) on > "rebase -i" in <20160729223134.ga22...@sigill.intra.peff.net>. > > > Subject: rebase-interactive: drop early check for valid ident > > > > Since the very inception of

Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

Hi Junio, On Thu, 1 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> though). The "one sequencer to rule them all" may even have to say > >> "now give name ':1' to the result of the previous operation" in one > >> step and in another later step

Re: [PATCH v3 2/4] cat-file: introduce the --filters option

Johannes Schindelin writes: > +static int filter_object(const char *path, unsigned mode, > + const unsigned char *sha1, > + char **buf, unsigned long *size) > +{ > + enum object_type type; > + > + *buf =

Re: [PATCH 21/22] sequencer: left-trim the lines read from the script

Hi Junio, On Thu, 1 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> > Interactive rebase's scripts may be indented; We need to handle this > >> > case, too, now that we prepare the sequencer to process interactive > >> > rebases. > >> > >> s/;

Re: [PATCH 22/22] sequencer: refactor write_message()

Hi Kuba, On Fri, 2 Sep 2016, Jakub Narębski wrote: > W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze: > > On Thu, 1 Sep 2016, Jakub Narębski wrote: > >> W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze: > > >>> if (commit_lock_file(_file) < 0) > >>> return error(_("Error

[PATCH v3 14/17] sequencer: lib'ify save_opts()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of save_opts(), sequencer_pick_revisions() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make it

[PATCH v3 07/17] sequencer: lib'ify prepare_revs()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of prepare_revs(), walk_revs_populate_todo() was just taught to return errors, after verifying that its callers are prepared to handle error returns, and with this

[PATCH v3 15/17] sequencer: lib'ify fast_forward_to()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of fast_forward_to(), do_pick_commit() already checks the return value and passes it on to its callers, so its caller must be already prepared to handle error returns,

[PATCH v3 05/17] sequencer: lib'ify do_pick_commit()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only two callers of do_pick_commit(), pick_commits() and single_pick() already check the return value and pass it on to their callers, so their callers must be already prepared to

[PATCH v3 17/17] sequencer: ensure to release the lock when we could not read the index

A future caller of read_and_refresh_cache() may want to do more than just print some helpful advice in case of failure. Suggested by Junio Hamano. Signed-off-by: Johannes Schindelin --- sequencer.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

[PATCH v3 13/17] sequencer: lib'ify save_todo()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of save_todo(), pick_commits() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make it notice an

[PATCH v3 16/17] lib'ify checkout_fast_forward_to()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only callers of checkout_fast_forward_to(), cmd_merge(), pull_into_void(), cmd_pull() and sequencer's fast_forward_to(), already check the return value and handle it

[PATCH v3 08/17] sequencer: lib'ify read_and_refresh_cache()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). There are two call sites of read_and_refresh_cache(), one of which is pick_commits(), whose callers were already prepared to do the right thing given an "error" return from it by an

[PATCH v3 12/17] sequencer: lib'ify save_head()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of save_head(), sequencer_pick_revisions() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make it

[PATCH v3 03/17] sequencer: lib'ify write_message()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of write_message(), do_pick_commit() already checks the return value and passes it on to its callers, so its caller must be already prepared to handle error returns,

[PATCH v3 06/17] sequencer: lib'ify walk_revs_populate_todo()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The function sequencer_pick_revisions() is the only caller of walk_revs_populate_todo(), and it already returns errors appropriately, so its caller must be already prepared to handle

[PATCH v3 11/17] sequencer: lib'ify create_seq_dir()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of create_seq_dir(), sequencer_pick_revisions() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make

[PATCH v3 10/17] sequencer: lib'ify read_populate_opts()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of read_populate_opts(), sequencer_continue() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make it

[PATCH v3 09/17] sequencer: lib'ify read_populate_todo()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of read_populate_todo(), sequencer_continue() can already return errors, so its caller must be already prepared to handle error returns, and with this step, we make it

[PATCH v3 04/17] sequencer: lib'ify do_recursive_merge()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The only caller of do_recursive_merge(), do_pick_commit() already checks the return value and passes it on to its callers, so its caller must be already prepared to handle error

[PATCH v3 02/17] sequencer: do not die() in do_pick_commit()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The eventual caller of do_pick_commit() is sequencer_pick_revisions(), which already relays a reported error from its helper functions (including this one), and both of its two

[PATCH v3 01/17] sequencer: lib'ify sequencer_pick_revisions()

Instead of dying there, let the caller high up in the callchain notice the error and handle it (by dying, still). The function sequencer_pick_revisions() has only two callers, cmd_revert() and cmd_cherry_pick(), both of which check the return value and react appropriately upon errors. So this is

[PATCH v3 00/17] Lib'ify quite a few functions in sequencer.c

This patch series is one of the half dozen patch series left to move the bulk of rebase -i into a builtin. The purpose of this patch series is to switch the functions in sequencer.c from die()ing to returning errors instead, as proper library functions should do, to give callers a chance to clean

Re: [PATCH 21/22] sequencer: left-trim the lines read from the script

Hi Kuba, On Fri, 2 Sep 2016, Jakub Narębski wrote: > Hello Johannes, > > W dniu 01.09.2016 o 16:13, Johannes Schindelin pisze: > > On Thu, 1 Sep 2016, Jakub Narębski wrote: > > >> 'bol' is beginning-of-line, isn't it (a complement to eol)? > > > > Yep. How did you guess? :-) > > Wouldn't

Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

Hi Junio, On Thu, 1 Sep 2016, Junio C Hamano wrote: > Jakub Narębski writes: > > > I wonder how probable is situation where we save instruction sheet > > for interactive rebase, with shortened SHA-1, and during rebase > > shortened SHA-1 stops being unambiguous... > > It is

Re: [PATCH 10/22] sequencer: avoid completely different messages for different actions

Hi Kuba, On Fri, 2 Sep 2016, Jakub Narębski wrote: > W dniu 01.09.2016 o 09:52, Johannes Schindelin pisze: > > On Wed, 31 Aug 2016, Jakub Narębski wrote: > >> CC-ed to Jiang Xin, L10N coordinator. > >> W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze: > > [...] > >>> - /* Different

Re: [PATCH 09/22] sequencer: completely revamp the "todo" script parsing

Hi Kuba, On Fri, 2 Sep 2016, Jakub Narębski wrote: > W dniu 01.09.2016 o 09:49, Johannes Schindelin pisze: > > On Wed, 31 Aug 2016, Jakub Narębski wrote: > > >> Here todo_list uses growable array implementation of list. Which is > >> I guess better on current CPU architecture, with slow

RE: [PATCH] checkout: eliminate unnecessary merge for trivial checkout

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Thursday, September 8, 2016 5:38 PM > To: Junio C Hamano > Cc: Ben Peart ; git@vger.kernel.org; > pclo...@gmail.com; =peart...@gmail.com; Ben Peart > >

Re: Announcing Git User's Survey 2016 [was: Working with public-inbox.org]

Hi Kuba, On Sun, 28 Aug 2016, Jakub Narębski wrote: > W dniu 28.08.2016 o 10:38, Johannes Schindelin pisze: > > > I would like to strongly caution against putting too much stock into > > this users' survey. It is the best we have, granted. Yet I have not > > heard from anybody that they

Re: [PATCH 2/3] diff_flush_patch_id: stop returning error result

Hi Peff, On Fri, 9 Sep 2016, Jeff King wrote: > On Fri, Sep 09, 2016 at 12:28:38PM +0200, Johannes Schindelin wrote: > > > I like the simplification, but I *hate* the fact that the calling code has > > *no way* to inform the user about the proper next steps. > > > > You are touching code that

  1   2   >