Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

Martin Ågren writes: >> - allow callers to align 1st prefix (e.g. "error: ") with the >>leading indent for the second and subsequent lines by passing the >>second prefix with appropriate display width. > > I suspect this second prefix would always consist of > strlen(first_prefix)

[PATCH v5 0/2] blame and log: prevent error if range ends past end of file

Okay, I think that sounds reasonable. I've amended the patch so that the line number is clipped to 1 when reading in a line range. And -L,-n is now treated the same as -L1,-n i.e. it will blame (or log) the first line of the file only.

[PATCH] blame: prevent error if range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behavior - instead we display the blame for existing lines within the specified range. Tests

[PATCH] log: prevent error if line range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git log, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behaviour - instead we perform the log for existing lines within the specified range. This

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

On 28 May 2018 at 23:45, Junio C Hamano wrote: > Duy Nguyen writes: > +error: sub/added +error: sub/addedtoo +error: Please move or remove them before you switch branches. Aborting EOF >>> >>> This shows the typical effect of this series, which (I

Re: [PATCH v3 00/20] Integrate commit-graph into 'fsck' and 'gc'

Derrick Stolee writes: > Thanks for all the feedback on v2. I've tried to make this round's > review a bit easier by splitting up the commits into smaller pieces. > Also, the test script now has less boilerplate and uses variables and > clear arithmetic to explain which bytes are being modified.

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

Duy Nguyen writes: >>> +error: sub/added >>> +error: sub/addedtoo >>> +error: Please move or remove them before you switch branches. >>> Aborting >>> EOF >> >> This shows the typical effect of this series, which (I subjectively >> think) gives us a more pleasant end-user

Re: [RFC PATCH v4] Implement --first-parent for git rev-list --bisect

Tiago Botelho writes: >> Running this test number of times gives me spurious errors. Is the >> order of these output lines unstable? How do we "sort" these >> bisect-all results? If we are not sorting and the output depends on >> happenstance, then probably we would need to compare the

Proposal

-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turke

Re: Weird revision walk behaviour

> On 24/05/2018 23:26, Kevin Bracey wrote: > > > >>> On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: > >>> >    $ git log --oneline master..ba95710a3b -- ci/ >    ea44c0a594 Merge branch 'bw/protocol-v2' into > jt/partial-clone-proto-v2 > > > In this case,

RFC: Merge-related plans

Hi everyone, I have some merge-related plans (and work in progress) that I'd like to get some feedback on in order to find what order would be best to address things in, if there are special steps I should take while approaching some of the bigger items, and even if folks disagree with any of the

Proposal

-- Hello I have been trying to contact you. Did you get my business proposal? Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turke

Re: does a new repo actually *need* default template content?

On Mon, May 28 2018, Robert P. J. Day wrote: > (apologies for more pedantic nitpickery, just little things i'm > running across in my travels. aside: i actually teach git courses, so > it's a bit embarrassing that i don't know some of this stuff. *sigh*.) Aside from maybe the empty branches/

Re: [PATCH 1/2] make show-index a builtin

On Tue, May 29, 2018 at 12:31:53AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > diff --git a/show-index.c b/builtin/show-index.c > > similarity index 96% > > rename from show-index.c > > rename to builtin/show-index.c > > index 1ead41e211..65fa86dd08 100644 > > --- a/show-index.c > >

Re: [PATCH] upload-pack: reject shallow requests that would return nothing

On Mon, May 28, 2018 at 7:55 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> To avoid this, if rev-list returns nothing, we abort the clone/fetch. >> The user could adjust their request (e.g. --shallow-since further back >> in the past) and retry. > > Yeah, that makes sense. > >>

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

On Fri, May 25, 2018 at 11:00 PM, Martin Ågren wrote: > advice.c contains a useful code snippet which takes a multi-line string > and prints the lines, prefixing and suffixing each line with two > constant strings. This was originally added in 23cb5bf3b3 (i18n of > multi-line advice messages,

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

On Mon, May 28, 2018 at 11:25 AM, Junio C Hamano wrote: > Martin Ågren writes: > >> diff --git a/t/t1011-read-tree-sparse-checkout.sh >> b/t/t1011-read-tree-sparse-checkout.sh >> index 0c6f48f302..31b0702e6c 100755 >> --- a/t/t1011-read-tree-sparse-checkout.sh >> +++

Re: [PATCH v3 08/20] commit-graph: verify required chunks are present

Derrick Stolee writes: > The commit-graph file requires the following three chunks: > > * OID Fanout > * OID Lookup > * Commit Data > > If any of these are missing, then the 'verify' subcommand should > report a failure. This includes the chunk IDs malformed or the > chunk count is truncated.

Re: [RFC PATCH v4] Implement --first-parent for git rev-list --bisect

On 28 May 2018 at 15:25, Junio C Hamano wrote: > Tiago Botelho writes: > > This will enable users to implement bisecting on first parents > > which can be useful for when the commits from a feature branch > > that we want to merge are not always tested. > > > > Signed-off-by: Tiago Botelho >

Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> @@ -1554,23 +1554,42 @@ filter..smudge:: >>> +Depending on the circumstances it might be better to use >>> +`fsck.skipList` instead to explicitly whitelist those

Re: [PATCH 1/2] make show-index a builtin

Jeff King writes: > diff --git a/show-index.c b/builtin/show-index.c > similarity index 96% > rename from show-index.c > rename to builtin/show-index.c > index 1ead41e211..65fa86dd08 100644 > --- a/show-index.c > +++ b/builtin/show-index.c > @@ -4,7 +4,7 @@ I squashed #include

Re: [RFC PATCH v4] Implement --first-parent for git rev-list --bisect

Tiago Botelho writes: > This will enable users to implement bisecting on first parents > which can be useful for when the commits from a feature branch > that we want to merge are not always tested. > > Signed-off-by: Tiago Botelho > --- > >

Re: why does builtin/init-db.c mention "/etc/core-git/templates/hooks/update"?

On Mon, 28 May 2018, Sitaram Chamarty wrote: > On Mon, May 28, 2018 at 09:27:18AM -0400, Robert P. J. Day wrote: > > [snipped the rest because I really don't know] > > > more to the point, is that actually what the "update" hook does? i > > just looked at the shipped sample, "update.sample",

Re: [PATCH v3 07/20] commit-graph: verify catches corrupt signature

Derrick Stolee writes: > This is the first of several commits that add a test to check that > 'git commit-graph verify' catches corruption in the commit-graph > file. The first test checks that the command catches an error in > the file signature. This is a check that

Re: why does builtin/init-db.c mention "/etc/core-git/templates/hooks/update"?

On Mon, May 28, 2018 at 09:27:18AM -0400, Robert P. J. Day wrote: [snipped the rest because I really don't know] > more to the point, is that actually what the "update" hook does? i > just looked at the shipped sample, "update.sample", and it seems to be > related to tags: > > #!/bin/sh >

Re: protocol for updating .po gettext files?

"Robert P. J. Day" writes: >i was going to submit a minor patch to fix grammar here: > > builtin/init-db.c: warning(_("templates not found %s"), template_dir); > > as it should display "templates not found in %s" to be consistent with > other messages, but i know from

why does builtin/init-db.c mention "/etc/core-git/templates/hooks/update"?

just noticed this in builtin/init-db.c: ... snip ... #ifndef DEFAULT_GIT_TEMPLATE_DIR #define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates" #endif ... snip ... static void copy_templates_1(struct strbuf *path, struct strbuf *template_path, DIR *dir) {

Re: [RFC PATCH v4] Implement --first-parent for git rev-list --bisect

Tiago Botelho writes: > diff --git a/bisect.c b/bisect.c > index 4eafc8262..e58cb8d62 100644 > --- a/bisect.c > +++ b/bisect.c > @@ -33,6 +33,8 @@ static const char *term_good; > * > * We care just barely enough to avoid recursing for > * non-merge entries. > + * >

Re: [PATCH] git-rebase--interactive: fix copy-paste mistake

On Mon, May 28, 2018 at 3:56 PM Johannes Schindelin < johannes.schinde...@gmx.de> wrote: > Hi Orgad, > On Sun, 27 May 2018, Orgad Shaneh wrote: > > exec argument is a command, not a commit. > > > > Signed-off-by: Orgad Shaneh > > --- > > git-rebase--interactive.sh | 2 +- >

does a new repo actually *need* default template content?

(apologies for more pedantic nitpickery, just little things i'm running across in my travels. aside: i actually teach git courses, so it's a bit embarrassing that i don't know some of this stuff. *sigh*.) running on fully-updated fedora 28 system: $ git --version git version 2.17.0 $

Re: [PATCH] git-rebase--interactive: fix copy-paste mistake

Hi Orgad, On Sun, 27 May 2018, Orgad Shaneh wrote: > exec argument is a command, not a commit. > > Signed-off-by: Orgad Shaneh > --- > git-rebase--interactive.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/git-rebase--interactive.sh

[GSoC][PATCH v4 1/4] rebase: introduce a dedicated backend for --preserve-merges

This duplicates git-rebase--interactive.sh to git-rebase--preserve-merges.sh. This is done to split -p from -i. No modifications are made to this file here, but any code that is not used by -p will be stripped in the next commit. Signed-off-by: Alban Gruin --- .gitignore

[GSoC][PATCH v4 2/4] rebase: strip unused code in git-rebase--preserve-merges.sh

This removes the code coming from git-rebase--interactive.sh that is not needed by preserve-merges, and changes the header comment accordingly. In a following commit, the -p code from git-rebase--interactive.sh will be stripped out. As preserve-merges’ successor is already in the works, this will

[GSoC][PATCH v4 3/4] rebase: use the new git-rebase--preserve-merges.sh

Create a new type of rebase, "preserve-merges", used when rebase is called with -p. Before that, the type for preserve-merges was "interactive", and some places of this script compared $type to "interactive". Instead, the code now checks if $interactive_rebase is empty or not, as it is set to

[GSoC][PATCH v4 4/4] rebase: remove -p code from git-rebase--interactive.sh

All the code specific to preserve-merges was moved to git-rebase--preserve-merges.sh, and so it’s useless to keep it here. The intent of this commit is to clean this script as much as possible to prepare a peaceful conversion as a builtin written in C. Signed-off-by: Alban Gruin

[GSoC][PATCH v4 0/4] rebase: split rebase -p from rebase -i

This splits the `rebase --preserve-merges` functionnality from git-rebase--interactive.sh. All the dead code left by the duplication of git-rebase--interactive.sh is also removed. This will make it easier to rewrite this script in C. This patch series is based of js/sequencer-and-root-commits.

protocol for updating .po gettext files?

i was going to submit a minor patch to fix grammar here: builtin/init-db.c: warning(_("templates not found %s"), template_dir); as it should display "templates not found in %s" to be consistent with other messages, but i know from nothing about .po files, so does one also have to update

Re: js/empty-config-section-fix, was Re: What's cooking in git.git (May 2018, #03; Wed, 23)

Hi Junio, On Mon, 28 May 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Thu, 24 May 2018, Junio C Hamano wrote: > > > >> * js/empty-config-section-fix (2018-05-18) 1 commit > >> - config: a user-provided invalid section is not a BUG > >> > >>

URGENT BSINESS ASSISTANT NEEDED

Dear Friend You may be surprise to receive this mail since you don’t know me personally, but with due respect, trust and humility, I write to you this proposal. I am Mr. us man Hassan the son of Mr. Ahmed Hassan of Darfur Sohut Sudan. It is indeed my pleasure to contact you for assistance of a

Re: [PATCH 0/4] fsck: doc fixes & fetch.fsck.* implementation

Ævar Arnfjörð Bjarmason writes: > On Thu, May 24, 2018 at 9:02 PM, Jeff King wrote: >> On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >>> That doesn't work, because that's for the server-side, but I need the >>> fetch.fsck.* that

Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

Eric Sunshine writes: >> @@ -1554,23 +1554,42 @@ filter..smudge:: >> +Depending on the circumstances it might be better to use >> +`fsck.skipList` instead to explicitly whitelist those objects that >> +have issues, otherwise new occurrences of the same issue will be I

[PATCH 2/2] show-index: update documentation for index v2

Commit 32637cdf4a (show-index.c: learn about index v2, 2007-04-09) changed the output format of show-index to include the object CRC32 but didn't update the documentation. Let's fix that and generally describe the output in more detail. There are a few other fixes here while we're rewording: -

[PATCH 1/2] make show-index a builtin

The git-show-index command is built as its own separate program. There's really no good reason for this, and it means we waste extra space on disk (and CPU time running the linker). Let's fold it in to the main binary as a builtin. The history here is actually a bit amusing. The program itself is

[PATCH 0/2] minor show-index modernizations

While recommending show-index to somebody today, I noticed that it has a few ancient warts. This series turns it into a builtin and fixes the documentation. I suspect it could do with some more modernization and friendliness, like: - re-using the existing packfile.c code instead of

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

Martin Ågren writes: > diff --git a/t/t1011-read-tree-sparse-checkout.sh > b/t/t1011-read-tree-sparse-checkout.sh > index 0c6f48f302..31b0702e6c 100755 > --- a/t/t1011-read-tree-sparse-checkout.sh > +++ b/t/t1011-read-tree-sparse-checkout.sh > @@ -243,9 +243,9 @@

[RFC PATCH v4] Implement --first-parent for git rev-list --bisect

This will enable users to implement bisecting on first parents which can be useful for when the commits from a feature branch that we want to merge are not always tested. Signed-off-by: Tiago Botelho --- This patch adds all Junio's suggestions, namely

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

Martin Ågren writes: > I'm open for suggestions on the naming of `prefix_suffix_lines()`... Is there a verb that means "have/place the thing in between two other things" or "Bring two things and place them on each side of the third thing" in a more concise way? Wrap?