W dniu 25.08.2016 o 14:58, Johannes Schindelin pisze:
> On Mon, 22 Aug 2016, Eric Wong wrote:
>> Johannes Schindelin wrote:
>>
>>> I just want developers who are already familiar with Git, and come up with
>>> an improvement to Git itself, to be able to contribute it without having
>>> to pull out
W dniu 22.08.2016 o 15:15, Duy Nguyen pisze:
> On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin
> wrote:
>>
>> My point stands. We are way more uninviting to contributors than
>> necessary. And a huge part of the problem is that we require contributors
>> to send their patches inlined into whi
Hello,
As I wrote previously here, I am thinking about returning to doing the
Git User's Survey this year.
Message-ID: <577e6f32.7020...@gmail.com>
https://marc.info/?l=git&m=146790381602547&w=2
https://public-inbox.org/git/577E6F32.7020007%40gmail.com/
In this email I'd like to propose t
Pranit Bauva writes:
>>> +struct bisect_terms {
>>> + struct strbuf term_good;
>>> + struct strbuf term_bad;
>>> +};
>>
>> I think "struct strbuf" is overrated. ...
>> I think you can just say "const char *" in this case.
>
> Using struct strbuf is not really overrated but in fact requir
Pranit Bauva writes:
>> I wonder the whole thing above is better restructured to avoid
>> repeated checks of the same thing.
>>
>> if (is it 40-hex, i.e. detached?) {
>> stuff it to start_head;
>> } else if (skip_prefix(head, "refs/heads/", &branchname)) {
>>
Hey Junio,
On Sat, Aug 27, 2016 at 4:37 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int bisect_log(void)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> +
>> + if (strbuf_read_file(&buf, git_path_bisect_log(), 256) < 0) {
>> + strbuf_release(&buf);
>> +
Hi,
On 08/27, Simon Ruderich wrote:
> Hello,
>
> I'm seeing the following crash with Git 2.9.3 on Debian sid
> (amd64):
>
> $ git init foo
> $ cd foo
> $ touch x
> $ git add x
> $ git commit -m test
> $ touch x.conf
> $ git blame x.conf
> segmentation fault
>
> I
Hey Junio,
On Fri, Aug 26, 2016 at 12:32 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int bisect_start(struct bisect_terms *terms, int no_checkout,
>> + const char **argv, int argc)
>> +{
>> + int i, has_double_dash = 0, must_write_terms = 0, bad_seen = 0
On Sat, Aug 27, 2016 at 8:45 PM, Christian Couder
wrote:
>
> I will send a diff between this version and v12 as a reply to this
> email.
Here is the diff:
diff --git a/apply.c b/apply.c
index 7e561a4..5cd037d 100644
--- a/apply.c
+++ b/apply.c
@@ -3993,12 +3993,21 @@ static int check_patch_list(
Parsing `git apply` options can be useful to other commands that
want to call the libified apply functionality, because this way
they can easily pass some options from their own command line to
the libified apply functionality.
This will be used by `git am` in a following patch.
To make this poss
Goal
This is a patch series about libifying `git apply` functionality, and
using this libified functionality in `git am`, so that no 'git apply'
process is spawn anymore. This makes `git am` significantly faster, so
`git rebase`, when it uses the am backend, is also significantly
faster.
Pre
This replaces run_apply() implementation with a new one that
uses the apply API that has been previously prepared in
apply.c and apply.h.
This shoud improve performance a lot in certain cases.
As the previous implementation was creating a new `git apply`
process to apply each patch, it could be s
Sometimes we want to apply in a different index file.
Before the apply functionality was libified it was possible to
use the GIT_INDEX_FILE environment variable, for this purpose.
But now, as the apply functionality has been libified, it should
be possible to do that in a libified way.
Signed-of
To libify git apply functionality, we will need to read from a
different index file in get_current_sha1(). This index file will be
stored in "struct apply_state", so let's pass the state to
build_fake_ancestor() which will later pass it to get_current_sha1().
Signed-off-by: Christian Couder
---
Let's make it possible to get the current error_routine and warn_routine,
so that we can store them before using set_error_routine() or
set_warn_routine() to use new ones.
This way we will be able put back the original routines, when we are done
with using new ones.
Signed-off-by: Christian Coude
As these functions are going to be part of the libified
apply API, let's give them a name that is more specific
to the apply API.
Signed-off-by: Christian Couder
---
builtin/apply.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/bui
To avoid possible mistakes and to uniformly show the errno
related messages, let's use error_errno() where possible.
Signed-off-by: Christian Couder
---
apply.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/apply.c b/apply.c
index c0cb3f5..41a33d3 100644
This changes 'int apply_verbosely' into 'enum apply_verbosity', and
changes the possible values of the variable from a bool to
a tristate.
The previous 'false' state is changed into 'verbosity_normal'.
The previous 'true' state is changed into 'verbosity_verbose'.
The new added state is 'verbosit
There are already set_die_routine() and set_error_routine(),
so let's add set_warn_routine() as this will be needed in a
following commit.
Signed-off-by: Christian Couder
---
git-compat-util.h | 1 +
usage.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/git-compat-util.h b/
To avoid printing anything when applying with
`state->apply_verbosity == verbosity_silent`, let's save the
existing warn and error routines before applying, and let's
replace them with a routine that does nothing.
Then after applying, let's restore the saved routines.
Helped-by: Stefan Beller
Si
When apply_verbosity is set to verbosity_silent nothing should be
printed on both stderr and stdout.
To avoid printing on stdout, we can just skip calling the following
functions:
- stat_patch_list(),
- numstat_patch_list(),
- summary_patch_list().
It is safe to do that b
Some parsing functions that were used in both "apply.c" and
"builtin/apply.c" are now only used in the former, so they
can be made static to "apply.c".
Signed-off-by: Christian Couder
---
apply.c | 6 +++---
apply.h | 5 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/apply.
The constants for the "inaccurate-eof" and the "recount" options will
be used in both "apply.c" and "builtin/apply.c", so they need to go
into "apply.h", and therefore they need a name that is more specific
to the API they belong to.
Signed-off-by: Christian Couder
---
apply.h | 3 +++
Hello,
I'm seeing the following crash with Git 2.9.3 on Debian sid
(amd64):
$ git init foo
$ cd foo
$ touch x
$ git add x
$ git commit -m test
$ touch x.conf
$ git blame x.conf
segmentation fault
I've tested it on Debian stable's 2.1.4 which works fine:
$ git
Hi,
Git v2.10.0-rc2 has been released, and let's start new round of git l10n.
This time there are 12 updated messages need lto be translated since last
update:
l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)
Generate po/git.pot from v2.10.0-rc2 for git v2.10.0 l10n round 2.
Sign
W dniu 27.08.2016 o 15:17, Brett Porter pisze:
> On 08/27/2016 03:55 AM, Jakub Narębski wrote:
>> W dniu 27.08.2016 o 04:29, Brett Porter pisze:
>>>
>>> In a small group, develop is the branch where all fixes/additions/... from
>>> topic
>>> branches are merged rather dynamically. Thorough testing
Thank you Jakub for your feedback.
On 08/27/2016 03:55 AM, Jakub Narębski wrote:
W dniu 27.08.2016 o 04:29, Brett Porter pisze:
In a small group, develop is the branch where all fixes/additions/... from topic
branches are merged rather dynamically. Thorough testing of commits
may lag behind, b
Hallo,
unter http://www.meinegeldanlage.com/ biete ich ein kostenloses E-Book zum
Thema Geldanlage mit umfassenden Informationen zum Download an. Bei den
Recherchen für das E-Book bin ich unter anderem auf Ihre Webseite gestoßen.
Wären Sie bereit, meine Webseite bzw. das E-Book von Ihrer Websei
From: "Junio C Hamano"
"Philip Oakley" writes:
The commit graph. We are looking for F based on knowing J.
. A - B - C - D -- E -- F -- G - H<-first parent, --merges (C,F,H)
. \ | /\//
. Z | //
. | | | /
. \ \ / /
.
Hey Junio,
On Fri, Aug 26, 2016 at 9:59 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>>> Also this version fails to catch "bisect reset a b c" as an error, I
>>> suspect.
>>
>> It didn't when I tried it right now. Could you please elaborate on why
>> you think it can fail? There might be a
b1de9de2 back in 2005 ensured that we could create a tarball with 'make
dist' even if git wasn't installed yet. These days however, chances are
higher that a git version is available. Add a config.mak knob to allow
people to choose to use the installed version of git to create the
tarball and avoid
Hey Junio,
On Thu, Aug 25, 2016 at 11:35 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int bisect_terms(struct bisect_terms *terms, const char **argv, int
>> argc)
>> +{
>> + int i;
>> +
>> + if (get_terms(terms)) {
>> + fprintf(stderr, _("no terms defined\n"
Hey Junio,
On Thu, Aug 25, 2016 at 4:10 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int mark_good(const char *refname, const struct object_id *oid,
>> + int flag, void *cb_data)
>> +{
>> + int *m_good = (int *)cb_data;
>> + *m_good = 0;
>> + return
Hey Junio,
On Thu, Aug 25, 2016 at 4:00 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +struct bisect_terms {
>> + struct strbuf term_good;
>> + struct strbuf term_bad;
>> +};
>
> I think "struct strbuf" is overrated. For things like this, where
> these fields will never change o
Hey Junio,
On Thu, Aug 25, 2016 at 3:43 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int is_expected_rev(const char *expected_hex)
>> +{
>> + struct strbuf actual_hex = STRBUF_INIT;
>> + int res = 0;
>> + if (strbuf_read_file(&actual_hex, git_path_bisect_expected_rev
W dniu 27.08.2016 o 00:42, Junio C Hamano pisze:
> Stefan Beller writes:
> -- >8 --
> From: Beat Bolli
???
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 27.08.2016 o 04:29, Brett Porter pisze:
>
> In a small group, develop is the branch where all fixes/additions/... from
> topic
> branches are merged rather dynamically. Thorough testing of commits
> may lag behind, but when we think one is a pretty good commit we want
> to identify it as (
Am 26.08.2016 um 20:24 schrieb Junio C Hamano:
Beat Bolli writes:
In 175d38c ("SubmittingPatches: document how to reference previous commits",
2016-07-28) the format for referring to older commits was specified.
is easier to read when pasted into a sentence than what the recent
update 175d38c
38 matches
Mail list logo
