Re: make git diff output easier to read - use better diff heuristics

the git diff one. See the following issue on github where I > initially reported the issue: > > https://github.com/git-for-windows/git/issues/1494 > > I have Included a picture to better illustrate the problem. What do > you think? Is it possible to make git diff output s

make git diff output easier to read - use better diff heuristics

the issue: https://github.com/git-for-windows/git/issues/1494 I have Included a picture to better illustrate the problem. What do you think? Is it possible to make git diff output similar to svn diff regarding this issue?

Re: "git bisect run make" adequate to locate first unbuildable commit?

y" <rpj...@crashcourse.ca> > >> > > >> > writing a short tutorial on "git bisect" and, all the details > >> > of special exit code 125 aside, if one wanted to locate the > >> > first unbuildable commit, would it be sufficient to just

Re: "git bisect run make" adequate to locate first unbuildable commit?

> > 1. there may be feature branches that bypass the known good starting > >commit, which can cause understanding issues as those side > >branches that predate the start point are also considered > >potential bu commits. > > ok, but let's make

Re: "git bisect run make" adequate to locate first unbuildable commit?

y" <rpj...@crashcourse.ca> > >> > > >> > writing a short tutorial on "git bisect" and, all the details > >> > of special exit code 125 aside, if one wanted to locate the > >> > first unbuildable commit, would it be sufficient to just

[PATCH v3 17/23] ref-filter: make valid_atom general again

Stop using valid_cat_file_atom, making the code more general. Further commits will contain some tests, docs and support of new features. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King ---

[PATCH v3 04/23] ref-filter: make valid_atom as function parameter

Make valid_atom as a function parameter, there could be another variable further. Need that for further reusing of formatting logic in cat-file.c. We do not need to allow users to pass their own valid_atom variable in global functions like verify_ref_format() because in the end we want to have

[PATCH v3 10/23] ref-filter: make populate_value() global

Make function global for further using in cat-file. In the end of patch series this function becomes internal again, so this is a part of middle step. cat-file would use more general functions further. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian

[PATCH v3 16/23] ref-filter: make cat_file_info independent

Remove connection between expand_data variable in cat-file and in ref-filter. It will help further to get rid of using expand_data in cat-file. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King

[PATCH v3 19/23] ref-filter: make populate_value() internal again

Remove populate_value() from header file. We needed that for interim step, now it could be returned back. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King --- ref-filter.c | 2 +-

[PATCH v3 09/12] sequencer: make refs generated by the `label` command worktree-local

This allows for rebases to be run in parallel in separate worktrees (think: interrupted in the middle of one rebase, being asked to perform a different rebase, adding a separate worktree just for that job). Signed-off-by: Johannes Schindelin --- refs.c

[PATCH v3 07/12] rebase-helper --make-script: introduce a flag to recreate merges

and which can therefore not be labeled, we use a unique +* abbreviation of the commit name. This is slightly more complicated +* than calling find_unique_abbrev() because we also need to make +* sure that the abbreviation does not conflict with any other +* lab

[PATCH v3 02/12] sequencer: make rearrange_squash() a bit more obvious

There are some commands that have to be skipped from rearranging by virtue of not handling any commits. However, the logic was not quite obvious: it skipped commands based on their position in the enum todo_command. Instead, let's make it explicit that we skip all commands that do not handle any

[RFC PATCH 0/3] Make fsck check other worktree HEADs

This patchset adds checking of other worktree HEADs to fsck. The reason I've marked this RFC is that I'm worried my incidental reliance on "worktrees/$WORKTREE/HEAD" resolving as a ref (in patch 3) might raise some flags for others. In particular, in [1] Peff said that this refname resolves

Re: "git bisect run make" adequate to locate first unbuildable commit?

t bisect" and, all the details of > special exit code 125 aside, if one wanted to locate the first > unbuildable commit, would it be sufficient to just run? > > $ git bisect run make > > as i read it, make returns either 0, 1 or 2 so there doesn't appear > to be an

Re: "git bisect run make" adequate to locate first unbuildable commit?

From: "Robert P. J. Day" <rpj...@crashcourse.ca> writing a short tutorial on "git bisect" and, all the details of special exit code 125 aside, if one wanted to locate the first unbuildable commit, would it be sufficient to just run? $ git bisect run make as i read

Re: "git bisect run make" adequate to locate first unbuildable commit?

t; unbuildable commit, would it be sufficient to just run? > > > > $ git bisect run make > > > > as i read it, make returns either 0, 1 or 2 so there doesn't appear > > to be any possibility of weirdness with clashing with a 125 exit code. > > am i overloo

[PATCH v5 17/17] fetch: make the --prune-tags work with

Make the new --prune-tags option work properly when git-fetch is invoked with a parameter instead of a parameter. This change is split off from the introduction of --prune-tags due to the relative complexity of munging the incoming argv, which is easier to review as a separate change. Signed

Re: "git bisect run make" adequate to locate first unbuildable commit?

run? > > $ git bisect run make > > as i read it, make returns either 0, 1 or 2 so there doesn't appear > to be any possibility of weirdness with clashing with a 125 exit code. > am i overlooking some subtle detail here i should be aware of? thanks. I think you are not overlooking anything.

"git bisect run make" adequate to locate first unbuildable commit?

writing a short tutorial on "git bisect" and, all the details of special exit code 125 aside, if one wanted to locate the first unbuildable commit, would it be sufficient to just run? $ git bisect run make as i read it, make returns either 0, 1 or 2 so there doesn't appear

Re: [PATCH v2 17/17] fetch: make the --fetch-prune work with

On Fri, Feb 09 2018, Eric Sunshine jotted: > On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason > <ava...@gmail.com> wrote: >> fetch: make the --fetch-prune work with > > Do you mean s/--fetch-prune/--prune-tags/ ? Yes, sorry. Will fix. >> Make the new --p

Re: [PATCH v2 17/17] fetch: make the --fetch-prune work with

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > fetch: make the --fetch-prune work with Do you mean s/--fetch-prune/--prune-tags/ ? > Make the new --prune-tags option work properly when git-fetch is > invoked with a parameter instead of

[PATCH v2 17/17] fetch: make the --fetch-prune work with

Make the new --prune-tags option work properly when git-fetch is invoked with a parameter instead of a parameter. This change is split off from the introduction of --prune-tags due to the relative complexity of munging the incoming argv, which is easier to review as a separate change. Signed

[PATCH v2 9/9] t: make 'test_i18ngrep' more informative on failure

. Make 'test_i18ngrep' more informative on failure by printing an error message including the invoked 'grep' command and the contents of the file it had to scan through. Note that this "dump the scanned file" part is not quite perfect, as it dumps only the file specified as the funct

[PATCH RFC v2 17/25] ref-filter: make cat_file_info independent

Remove connection between expand_data variable in cat-file and in ref-filter. It will help further to get rid of using expand_data in cat-file. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King

[PATCH RFC v2 20/25] ref-filter: make populate_value() internal again

Remove populate_value() from header file. We needed that for interim step, now it could be returned back. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King --- ref-filter.c | 2 +-

[PATCH RFC v2 04/25] ref-filter: make valid_atom as function parameter

Make valid_atom as a function parameter, there could be another variable further. Need that for further reusing of formatting logic in cat-file.c. We do not need to allow users to pass their own valid_atom variable in global functions like verify_ref_format() because in the end we want to have

[PATCH RFC v2 18/25] ref-filter: make valid_atom general again

Stop using valid_cat_file_atom, making the code more general. Further commits will contain some tests, docs and support of new features. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King ---

[PATCH RFC v2 10/25] ref-filter: make populate_value() global

Make function global for further using in cat-file. In the end of patch series this function becomes internal again, so this is a part of middle step. cat-file would use more general functions further. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian

Re: [PATCH v7 18/31] merge-recursive: make a helper function for cleanup for handle_renames

On Tue, Jan 30, 2018 at 3:25 PM, Elijah Newren <new...@gmail.com> wrote: > In anticipation of more involved cleanup to come, make a helper function > for doing the cleanup at the end of handle_renames. Rename the already > existing cleanup_rename[s]() to final_cleanup_rename[s](

Re: [PATCH v7 15/31] merge-recursive: make !o->detect_rename codepath more obvious

On Tue, Jan 30, 2018 at 3:25 PM, Elijah Newren wrote: > Previously, if !o->detect_rename then get_renames() would return an > empty string_list, and then process_renames() would have nothing to > iterate over. It seems more straightforward to simply avoid calling > either

Re: [RFC/PATCH] reset --hard: make use of the pretty machinery

Thomas Gummerer writes: > In addition to the easier to follow code, this makes the output more > consistent with other commands that print the title of the commit, such > as 'git commit --oneline' or 'git checkout', which both use > 'pp_commit_easy()' with the

Re: [RFC/PATCH] reset --hard: make use of the pretty machinery

t 00 foo", while after > this change we print "HEAD is now at 00 foo bar", same as 'git log > --oneline' shows "00 foo bar". > > So this does make the output more consistent with other commands, and > 'reset' is a porcelain command, so nobody should

[RFC/PATCH] reset --hard: make use of the pretty machinery

previously we would print "HEAD is now at 00 foo", while after this change we print "HEAD is now at 00 foo bar", same as 'git log --oneline' shows "00 foo bar". So this does make the output more consistent with other commands, and 'reset' is a porce

[PATCH v7 18/31] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCH v7 15/31] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCH v2 07/10] sequencer: make refs generated by the `label` command worktree-local

This allows for rebases to be run in parallel in separate worktrees (think: interrupted in the middle of one rebase, being asked to perform a different rebase, adding a separate worktree just for that job). Signed-off-by: Johannes Schindelin --- refs.c

[PATCH v2 05/10] rebase-helper --make-script: introduce a flag to recreate merges

and which can therefore not be labeled, we use a unique +* abbreviation of the commit name. This is slightly more complicated +* than calling find_unique_abbrev() because we also need to make +* sure that the abbreviation does not conflict with any other +* lab

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

s hash using strihash() as the hash > function, but the final comparison between the entries in the same > hash buckets are done with case sensitivity. It is unclear to me if > that is what was intended, and why. Heh... you were almost there with your analysis. strihash() is needed for c

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

Hi Junio, On Tue, 23 Jan 2018, Junio C Hamano wrote: > Eric Sunshine writes: > > >> + is_octopus = to_merge && to_merge->next; > >> + > >> + if (is_octopus) > >> + BUG("Octopus merges not yet supported"); > > > > Is

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

; + hashmap_get_from_hash(>labels, > > +strihash(label), label)) { > > + /* > > + * If the label already exists, or if the label is a valid > > full > > +* OID,

Re: [PATCH 09/10] t: make sure that 'test_i18ngrep' got enough parameters

On Fri, Jan 26, 2018 at 7:37 AM, SZEDER Gábor wrote: > Two of the previous patches in this series fixed two bogus > 'test_i18ngrep' invocations that had neither a filename parameter not s/not/nor/ > anything piped into their standard input, yet both managed to remain >

Re: [PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

On Fri, Jan 26, 2018 at 09:26:38PM +0100, SZEDER Gábor wrote: > Yeah, I knew about TEST_SHELL_PATH, but still: > > $ make -j4 TEST_SHELL_PATH=/bin/bash > <...> > $ cd t/ > $ for t in t[0-9][0-9][0-9][0-9]-*.sh ; do "./$t" -x ; done >/dev/null 2>&a

Re: [PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

err output of shell functions. But with the BASH_XTRACEFD stuff, if > you run suite under bash it should al Just Work (and I recently added > TEST_SHELL_PATH to use bash just for the test suite without building all > of the scripts with it). Yeah, I knew about TEST_SHELL_PATH, but still: $

[PATCH RFC 05/24] ref-filter: make valid_atom as function parameter

Make valid_atom as a function parameter, there could be another variable further. Need that for further reusing of formatting logic in cat-file.c. We do not need to allow users to pass their own valid_atom variable in global functions like verify_ref_format because in the end we want to have same

[PATCH RFC 19/24] ref-filter: make populate_value internal again

Remove populate_value from header file. We needed that for interim step, now it could be returned back. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King --- ref-filter.c | 2 +-

[PATCH RFC 16/24] ref-filter: make cat_file_info independent

Remove connection between expand_data variable in cat-file and in ref-filter. It will help further to get rid of using expand_data in cat-file. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King

[PATCH RFC 10/24] ref-filter: make populate_value global

Make function global for further using in cat-file. In the end of patch series this function becomes internal again, so this is a part of middle step. cat-file would use more general functions further. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian

[PATCH RFC 18/24] ref-filter: make valid_atom general again

Stop using valid_cat_file_atom, making the code more general. Further commits will contain some tests, docs and support of new features. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King ---

Re: [PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

exits > >> completely silently; when its negated form does find the pattern that > >> shouldn't be there, it prints the matching line(s) but otherwise exits > >> without any error message. This leaves the developer puzzled about > >> what could have gone wrong. >

Re: [PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

attern that >> shouldn't be there, it prints the matching line(s) but otherwise exits >> without any error message. This leaves the developer puzzled about >> what could have gone wrong. >> >> Make 'test_i18ngrep' more informative on failure by printing an error >> m

Re: [PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

ut any error message. This leaves the developer puzzled about > what could have gone wrong. > > Make 'test_i18ngrep' more informative on failure by printing an error > message including the invoked 'grep' command and the contents of the > file it had to scan through. I think this is a

Re: [PATCH 09/10] t: make sure that 'test_i18ngrep' got enough parameters

On Fri, Jan 26, 2018 at 01:37:07PM +0100, SZEDER Gábor wrote: > Two of the previous patches in this series fixed two bogus > 'test_i18ngrep' invocations that had neither a filename parameter not > anything piped into their standard input, yet both managed to remain > unnoticed for years. A third

[PATCH 09/10] t: make sure that 'test_i18ngrep' got enough parameters

Two of the previous patches in this series fixed two bogus 'test_i18ngrep' invocations that had neither a filename parameter not anything piped into their standard input, yet both managed to remain unnoticed for years. A third similarly bogus invocation is currently lurking in 'pu' for a couple

[PATCH 10/10] t: make 'test_i18ngrep' more informative on failure

. Make 'test_i18ngrep' more informative on failure by printing an error message including the invoked 'grep' command and the contents of the file it had to scan through. Note that this "dump the scanned file" part is not quite perfect, as it dumps only the file specified as the funct

Re: [PATCH 3/6] find_reference_location(): make function safe for empty snapshots

On Wed, Jan 24, 2018 at 01:11:00PM -0800, Junio C Hamano wrote: > > This tightens the binary search termination condition. If we ever did > > see "hi > lo", we'd want to terminate the loop. Is that ever possible? > > I think you meant "lo > hi", but I shared the same "Huh?" moment. Er, yeah.

Re: [PATCH 3/6] find_reference_location(): make function safe for empty snapshots

Jeff King writes: > On Wed, Jan 24, 2018 at 12:14:13PM +0100, Michael Haggerty wrote: > >> diff --git a/refs/packed-backend.c b/refs/packed-backend.c >> index 08698de6ea..361affd7ad 100644 >> --- a/refs/packed-backend.c >> +++ b/refs/packed-backend.c >> [...] >> @@ -551,7 +553,7

Re: [PATCH 4/6] packed_ref_iterator_begin(): make optimization more general

On Wed, Jan 24, 2018 at 12:14:14PM +0100, Michael Haggerty wrote: > We can return an empty iterator not only if the `packed-refs` file is > missing, but also if it is empty or if there are no references whose > names succeed `prefix`. Optimize away those cases as well by moving > the call to

Re: [PATCH 3/6] find_reference_location(): make function safe for empty snapshots

On Wed, Jan 24, 2018 at 12:14:13PM +0100, Michael Haggerty wrote: > diff --git a/refs/packed-backend.c b/refs/packed-backend.c > index 08698de6ea..361affd7ad 100644 > --- a/refs/packed-backend.c > +++ b/refs/packed-backend.c > [...] > @@ -551,7 +553,7 @@ static const char

[PATCH 4/6] packed_ref_iterator_begin(): make optimization more general

We can return an empty iterator not only if the `packed-refs` file is missing, but also if it is empty or if there are no references whose names succeed `prefix`. Optimize away those cases as well by moving the call to `find_reference_location()` higher in the function and checking whether the

[PATCH 3/6] find_reference_location(): make function safe for empty snapshots

This function had two problems if called for an empty snapshot (i.e., `snapshot->start == snapshot->eof == NULL`): * It checked `NULL < NULL`, which is undefined by C (albeit highly unlikely to fail in the real world). * (Assuming the above comparison behaved as expected), it returned NULL

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

Eric Sunshine writes: >> + is_octopus = to_merge && to_merge->next; >> + >> + if (is_octopus) >> + BUG("Octopus merges not yet supported"); > > Is this a situation which the end-user can trigger by specifying a > merge

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

or "uninteresting" commits, i.e. commits that are not to be > + * rebased, and which can therefore not be labeled, we use a unique > + * abbreviation of the commit name. This is slightly more complicated > + * than calling find_unique_abbrev() because we also need

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

On Fri, Jan 19, 2018 at 10:47:57AM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > I also think %(deltabase) does make sense for anything that points to an > > object. I suspect it's not all that _useful_ for for-each-ref, but that > >

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

Jeff King <p...@peff.net> writes: > I also think %(deltabase) does make sense for anything that points to an > object. I suspect it's not all that _useful_ for for-each-ref, but that > doesn't mean we can't return the sensible thing if somebody asks for it. This may not be a ne

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

her thoughts here - we were thinking about creating format.h >>> but decided not to move forward with it, and now we are suffering >>> because of it. Can I create it right now or the history of commits >>> would be too dirty because of it? >> >> It wou

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

it, and about ref-filter atoms for cat-file). >> >> For now and I think until the migration process is finished, you could >> just die() in case of any atom not already supported by the command. > > I'm OK with dying in the interim if it's easier, though I suspect it is >

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

xtra work to just expand to the empty string in such cases. If that's where we want to end up eventually, it may be worth going straight there. I also think %(deltabase) does make sense for anything that points to an object. I suspect it's not all that _useful_ for for-each-ref, but that doesn't me

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b >>> >>> (Nit: it looks like the above link does not work any more, but it >>> seems that you are talking about the last patch on the catfile >>> branch.) >>> >>>>> But I decided not to add th

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

; seems that you are talking about the last patch on the catfile >> branch.) >> >>>> But I decided not to add that to patch because I expand the >>>> functionality of several commands (not only cat-file and >>>> for-each-ref), and I need to support all

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

gt; 2018-01-18 9:20 GMT+03:00 Оля Тележная <olyatelezhn...@gmail.com>: >>>> >>>> I think it's important to finish migrating process at first. I mean, >>>> now we are preparing and collecting everything in ref-filter, but we >>>> make resulting string and p

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

s important to finish migrating process at first. I mean, >>> now we are preparing and collecting everything in ref-filter, but we >>> make resulting string and print still in cat-file. And I am not sure, >>> but maybe it will not be possible to start using new atoms in

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

bels, > +strihash(label), label)) { > + /* > +* If the label already exists, or if the label is a valid > full > +* OID, we append a dash and a number to make it unique. > +*/ > +

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

e. commits that are not to be + * rebased, and which can therefore not be labeled, we use a unique + * abbreviation of the commit name. This is slightly more complicated + * than calling find_unique_abbrev() because we also need to make + * sure that the abbreviation does not conflict with an

[PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

nteresting" commits, i.e. commits that are not to be +* rebased, and which can therefore not be labeled, we use a unique +* abbreviation of the commit name. This is slightly more complicated +* than calling find_unique_abbrev() because we also need to make +* sure

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

everything in ref-filter, but we >> make resulting string and print still in cat-file. And I am not sure, >> but maybe it will not be possible to start using new atoms in cat-file >> while some part of logic still differs. > > I tried to make t

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

hat you are talking about the last patch on the catfile >> branch.) >> >>>> But I decided not to add that to patch because I expand the >>>> functionality of several commands (not only cat-file and >>>> for-each-ref), and I need to support all new fun

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

e I expand the >>> functionality of several commands (not only cat-file and >>> for-each-ref), and I need to support all new functionality in a proper >>> way, make these error messages, test everything and - the hardest one >>> - support many new commands for cat-file.

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

s not work any more, but it seems that you are talking about the last patch on the catfile branch.) >> But I decided not to add that to patch because I expand the >> functionality of several commands (not only cat-file and >> for-each-ref), and I need to support all new functionality in a prop

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

; I agree, I even made this and it's working fine: > https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b > But I decided not to add that to patch because I expand the > functionality of several commands (not only cat-file and > for-each-ref), and I need to suppo

Re: [PATCH v3 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

On Sun, Jan 14, 2018 at 9:37 AM, Kaartic Sivaraam wrote: > * Only mention porcelain commands in examples > > * Split a sentence for better readability > > * Add missing apostrophes > > * Clearly specify the advantages of using submodules > > * Avoid abbreviations > > *

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

2018-01-16 0:42 GMT+03:00 Jeff King <p...@peff.net>: > On Wed, Jan 10, 2018 at 09:36:41AM +, Olga Telezhnaya wrote: > >> Make valid_atom as a function parameter, >> there could be another variable further. >> Need that for further reusing of formatting logic in ca

Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter

On Wed, Jan 10, 2018 at 09:36:41AM +, Olga Telezhnaya wrote: > Make valid_atom as a function parameter, > there could be another variable further. > Need that for further reusing of formatting logic in cat-file.c. > > We do not need to allow users to pass their own vali

[PATCH v3 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

* Only mention porcelain commands in examples * Split a sentence for better readability * Add missing apostrophes * Clearly specify the advantages of using submodules * Avoid abbreviations * Use "Git" consistently * Improve readability of certain lines * Clarify when a submodule is

Re: [PATCH v2 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

On Tue, Jan 9, 2018 at 10:49 PM, Kaartic Sivaraam wrote: > * Only mention porcelain commands in examples > > * Split a sentence for better readability > > * Add missing apostrophes > > * Clearly specify the advantages of using submodules > > * Avoid abbreviations > > *

[PATCH v2 03/18] ref-filter: make valid_atom as function parameter

Make valid_atom as a function parameter, there could be another variable further. Need that for further reusing of formatting logic in cat-file.c. We do not need to allow users to pass their own valid_atom variable in global functions like verify_ref_format because in the end we want to have same

[PATCH v2 12/18] ref-filter: make populate_value global

Make function global for further using in cat-file. Also added return value for handling errors. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian Couder <christian.cou...@gmail.com> Mentored by: Jeff King <p...@peff.net> --- ref-filter.c | 4 ++--

[PATCH v2 18/18] ref-filter: make cat_file_info independent

Remove connection between expand_data variable in cat-file and in ref-filter. It will help further to get rid of using expand_data in cat-file. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King

[PATCH v2 1/2] Doc/gitsubmodules: make some changes to improve readability and syntax

* Only mention porcelain commands in examples * Split a sentence for better readability * Add missing apostrophes * Clearly specify the advantages of using submodules * Avoid abbreviations * Use "Git" consistently * Improve readability of certain lines * Clarify when a submodule is

Re: [PATCH 04/20] cat-file: make valid_atoms as a function parameter

Olga Telezhnaya <olyatelezhn...@gmail.com> writes: > Make valid_atoms as a function parameter, > there could be another variable further. > Need that for further reusing of formatting logic in cat-file.c. > > Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com&g

[PATCH 20/20] cat-file: make cat_file_info variable independent

Remove connection between expand_data variable in cat-file and in ref-filter. It will help further to get rid of using expand_data in cat-file. Signed-off-by: Olga Telezhnaia Mentored-by: Christian Couder Mentored by: Jeff King

[PATCH 04/20] cat-file: make valid_atoms as a function parameter

Make valid_atoms as a function parameter, there could be another variable further. Need that for further reusing of formatting logic in cat-file.c. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian Couder <christian.cou...@gmail.com> Mentored by:

[PATCH 14/20] cat-file: make populate_value global

Make function global for further using in cat-file. Also added return value for handling errors. Signed-off-by: Olga Telezhnaia <olyatelezhn...@gmail.com> Mentored-by: Christian Couder <christian.cou...@gmail.com> Mentored by: Jeff King <p...@peff.net> --- ref-filter.c | 4 ++--

Re: [PATCH 4/6] fsmonitor: Make output of test-dump-fsmonitor more concise

On 1/4/2018 5:33 PM, Johannes Schindelin wrote: Hi Alex, On Tue, 2 Jan 2018, Alex Vandiver wrote: Rather than display one very long line, summarize the contents of that line. The tests do not currently rely on any content except the first line ("no fsmonitor" / "fsmonitor last update").

[PATCHv6 18/31] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCHv6 15/31] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCHv2 1/6] diff.h: Make pickaxe_opts an unsigned bit field

This variable is used as a bit field[1], and as we are about to add more fields, indicate its usage as a bit field by making it unsigned. [1] containing the bits #define DIFF_PICKAXE_ALL1 #define DIFF_PICKAXE_REGEX 2 #define DIFF_PICKAXE_KIND_S 4 #define DIFF_PICKAXE_KIND_G

Re: [PATCH 4/6] fsmonitor: Make output of test-dump-fsmonitor more concise

Hi Alex, On Tue, 2 Jan 2018, Alex Vandiver wrote: > Rather than display one very long line, summarize the contents of that > line. The tests do not currently rely on any content except the first > line ("no fsmonitor" / "fsmonitor last update"). The more interesting part would be the entries

Re: [PATCH 1/5] diff.h: Make pickaxe_opts an unsigned bit field

Stefan Beller writes: > This variable is used as a bit field[1], and as we are about to add more > fields, indicate its usage as a bit field by making it unsigned. > > [1] containing the bits > > #define DIFF_PICKAXE_ALL 1 > #define DIFF_PICKAXE_REGEX2 >

[PATCH 1/5] diff.h: Make pickaxe_opts an unsigned bit field

This variable is used as a bit field[1], and as we are about to add more fields, indicate its usage as a bit field by making it unsigned. [1] containing the bits #define DIFF_PICKAXE_ALL1 #define DIFF_PICKAXE_REGEX 2 #define DIFF_PICKAXE_KIND_S 4 #define DIFF_PICKAXE_KIND_G

<    3   4   5   6   7   8   9   10   11   12   >