On Thu, Sep 08, 2016 at 08:21:32PM +0200, larsxschnei...@gmail.com wrote:
[]
> +packet: git> git-filter-client
> +packet: git> version=2
> +packet: git> version=42
> +packet: git>
> +packet: git< git-filter-server
> +packet: git< version=2
On Sat, Sep 10, 2016 at 05:51:19AM +, Torsten Bögershausen wrote:
> > +test_lazy_prereq JGIT '
> > + type jgit
> > +'
> > +
>
> Minor note:
> Typically the stdout of `which` is suppressed like this:
>
> if ! type cvs >/dev/null 2>&1
But we don't want to suppress the output here; the test
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 '
(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) with ok but wifi with a w
> 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 p
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 sharp edges
that you can i
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 ls-files on all submodules.
>
> While
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,
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 writes:
>>
>>> On Thu, 11 Aug 2016, Junio C Hamano wrote:
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 actually `checkin'
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 name of the branch t
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" sounds nice ("hey, I
c
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
http://datasets.datalad.org/nidm/fbirn_phaseIII/.gi
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 h
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 parent argv int
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 Wil
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 checked out
to the work
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 not modify files as
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,
> + const struct branch_
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 and this is the firs
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/*" >> .gitignor
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 today's
integration cycl
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 I wondered if su
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(-)
Reviewed-by
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 it anymore.
FW
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 between the last line of the
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 to create commit out
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 between the last line of the patch
>> and the baseinfo, which makes it look a bit strange, e.g. output
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, "capabilities^{}")) {
>
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 unstage the bar you
>> a
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
> prerequisi
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 sq
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
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 min
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 relationship with the Git commun
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 unexpected
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.
Mean
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 deletions(-)
diff --git a/t/t5310-p
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 line but before send
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 pack-protocol.txt.
The last sentenc
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 --attach=m
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.
>>>
>>> It *looks* correct to me.
>>
>> Hmm
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 (saw_res
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
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
+++ b/
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 a
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.
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 (comm
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, doing "we have
>> reconstruc
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 guess that it does not hurt to go with the
>> patch,
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,
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.
> git-gui/lib/commit.tcl | 3 +++
> 1 file change
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 being thorough.
> diff --git
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 fast_forward_to(),
> already check the
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 --verify HEAD:world.txt) &&
> +
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 assumption here?
Yes.
"
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... Sorry!
As I said a few minu
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 made bad assumpt
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 assume it is fine (it is cer
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.
Mean
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 line but before send
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
wh
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 deletions(-)
diff --git a/t/t5310-p
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 special for a symbo
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 (S_ISREG(mode)) {
>>> > + struct strbuf s
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 assumption here?
Yet the
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 paths specified without -i or
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: rpmbuild -ta git-2.9.3.tar.g
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: error: Failed to read spec fi
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 y
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 it would probably help in a fe
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 strbuf = STRBUF_INIT;
>> > +
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)
> > +{
> > + enum object_type type;
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 inter
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 have an instruction "merge ':
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 = read_sha1_file(sha1, &type, size);
> +
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/; We need/; we need/
> >
> > Hr
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(&msg_file) < 0)
> >>> return error(_("Erro
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 step
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,
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
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 not
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 --git a/sequencer.c b/sequenc
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 error
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 appropriately.
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 e
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 i
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
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
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 ea
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 not
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, an
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 return
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 callers
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
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
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 'b
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 my understanding th
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 translati
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 memory
1 - 100 of 127 matches
Mail list logo
