Re: [PATCH] Documentation/SubmittingPatches: add quotes to advised commit reference

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

Re: [PATCH 1/2] gitk: align the commit summary format to the documentation

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

Re: stable as subset of develop

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

[L10N] Kickoff of translation for Git 2.10.0 round 2

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.

Re: stable as subset of develop

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

Re: Are --first-parent and --ancestry-path compatible rev-list options?

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 | // . |

Re: [PATCH v14 07/27] bisect--helper: `bisect_reset` shell function in C

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

Re: stable as subset of develop

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,

E-Book zum Thema Geldanlage

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

[PATCH] make dist: allow using an installed version of git

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

Re: [PATCH v14 09/27] bisect--helper: `bisect_write` shell function in C

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

Re: [PATCH v14 11/27] bisect--helper: `bisect_next_check` & bisect_voc shell function in C

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

Re: [PATCH v14 12/27] bisect--helper: `get_terms` & `bisect_terms` shell function in C

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)) { >> +

Re: [PATCH v14 08/27] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

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

Crash when using git blame on untracked file

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: $

Re: [PATCH v14 21/27] bisect--helper: `bisect_log` shell function in C

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(, git_path_bisect_log(), 256) < 0) { >> +

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

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

Re: [PATCH v13 00/14] libify apply and use lib in am, part 3

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 @@

Re: [PATCH v14 09/27] bisect--helper: `bisect_write` shell function in C

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

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

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

[PATCH v13 01/14] builtin/apply: rename option parsing functions

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

[PATCH v13 00/14] libify apply and use lib in am, part 3

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.

[PATCH v13 05/14] apply: use error_errno() where possible

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

[PATCH v13 06/14] apply: make it possible to silently apply

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

[PATCH v13 04/14] apply: make some parsing functions static again

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

[PATCH v13 02/14] apply: rename and move opt constants to apply.h

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 ---

[PATCH v13 14/14] builtin/am: use apply API in run_apply()

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

[PATCH v13 13/14] apply: learn to use a different index file

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.

[PATCH v13 12/14] apply: pass apply state to build_fake_ancestor()

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

[PATCH v13 09/14] usage: add get_error_routine() and get_warn_routine()

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

[PATCH v13 11/14] apply: refactor `git apply` option parsing

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

[PATCH v13 08/14] usage: add set_warn_routine()

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

[PATCH v13 10/14] apply: change error_routine when silent

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

[PATCH v13 07/14] apply: don't print on stdout in verbosity_silent mode

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

Re: [PATCH v14 13/27] bisect--helper: `bisect_start` shell function partially in C

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/",

Re: [PATCH v14 13/27] bisect--helper: `bisect_start` shell function partially in C

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,

Re: Crash when using git blame on untracked file

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 > >

[RFCv2] Proposed questions for "Git User's Survey 2016", take two

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=146790381602547=2 https://public-inbox.org/git/577E6F32.7020007%40gmail.com/ In this email I'd like to propose the