Re: [WIP RFC 4/5] upload-pack: refactor writing of "packfile" line

> Jonathan Tan writes: > > > @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct > > output_state *os) > > } > > os->used += readsz; > > > > + if (!os->packfile_started) { > > + os->packfile_started = 1; > > + if (use_protocol_v2) > > +

Re: [WIP RFC 2/5] Documentation: add Packfile URIs design doc

> > +This feature allows servers to serve part of their packfile response as > > URIs. > > +This allows server designs that improve scalability in bandwidth and CPU > > usage > > +(for example, by serving some data through a CDN), and (in the future) > > provides > > +some measure of

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05, 2018 at 04:56:21PM -0500, Jeff King wrote: > Could we just kill them all? > > I guess it's a little tricky, because $! is going to give us the pid of > each subshell. We actually want to kill the test sub-process. That takes > a few contortions, but the output is nice (every

Re: [BUG REPORT] Git does not correctly replay bisect log

On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote: > > I am talking about `git bisect replay`. The shell script, as far as I > can see, only updates the references (ref/bisect/*) and never checks if > the revisions marked as 'good' are ancestors of the 'bad' one. > Therefore,

Yo! Dear

This is a multi-part message in MIME format. Hey n8541112.pdf Description: Adobe PDF document

Re: git, monorepos, and access control

Johannes, Thanks for your feedback. I'm not looking closely at submodules, as it's my understanding that VFSForGit does not support them. A VFS would be a killer feature for us. If VFSForGit were to support submodules, we'd look at them. They would provide access control in a way that's

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05, 2018 at 04:36:26PM -0500, Jeff King wrote: > The signal interrupts the first wait. Ah, of course. I'm ashamed to say that this is not the first time I forget about that... > > Bash 4.3 or later are strange: I get back the shell prompt immediately > > after ctrl-C as well, so it

Re: [WIP RFC 1/5] Documentation: order protocol v2 sections

> > The git command line expects Git servers to follow a specific order of > > "Command line"? It sounds like you are talking about the order of > command line arguments and options, but apparently that is not what > you are doing. Is it "The git over-the-wire protocol"? I meant to say the

behaviour of git-blame -M -C (maybe a bug?)

hi everybody, I am the maintainer of cregit. We are trying to improve blame traceability at the token level (see https://github.com/dmgerman/papers/blob/master/editorials/cregit/cregit.org) We use git-blame heavilty in cregit. One of the features that I would like to add to cregit is the

How are you today?

Good Day Dear, I'm Ms Amelia and am new here looking for a serious relationship with someone i can spend the rest of my life with, someone who is loving, caring, honest and faithful to spend the rest of my life with, i came across your profile and its very interesting to me and i would like

Re: enhancement: support for author.email and author.name in "git config"

Hi William, On Thu, 6 Dec 2018, William Hubbs wrote: > On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote: > > Hi William, > > > > [...] > > > > This idea was floated a couple of months ago [1]. Junio seemed to find > > the request sensible and outlined a design. No patches

Re: git, monorepos, and access control

On Thu, Dec 6, 2018 at 12:09 PM Johannes Schindelin wrote: > > Hi, > > On Wed, 5 Dec 2018, Jeff King wrote: > > > The model that fits more naturally with how Git is implemented would be > > to use submodules. There you leak the hash of the commit from the > > private submodule, but that's

Re: [RFC] cherry-pick notes to find out cherry-picks from the origin

Hello, Jeff. So, this is what I currently have. It still does the same thing but a lot more generic in terms of both interface and implementation. * All core logics are implemented as core helpers / features. * Trailer parsing and reverse-mapping in trailer_rev_xrefs_*(). * Note refs

Re: [PATCHv2 0/9] Resending sb/submodule-recursive-fetch-gets-the-tip

On Tue, Dec 4, 2018 at 7:10 PM Junio C Hamano wrote: > > Stefan Beller writes: > > > This is a resend of sb/submodule-recursive-fetch-gets-the-tip, > > with all feedback addressed. As it took some time, I'll send it > > without range-diff, but would ask for full review. > > Is that a "resend" or

Re: [wishlist] git submodule update --reset-hard

On Thu, Dec 6, 2018 at 1:25 PM Yaroslav Halchenko wrote: > > > On Thu, 06 Dec 2018, Stefan Beller wrote: > > > On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko > > wrote: > > > > Dear Git Gurus, > > > > I wondered what would be your take on my wishlist request to add > > > --reset-hard

[PATCH] terminology tweak: prune -> path limiting

In the codebase, "prune" is a highly overloaded term, and it caused me a lot of trouble to figure out what it meant when it was used in the context of path limiting. Stop using the word "prune" when we really mean "path limiting." Signed-off-by: Matthew DeVore ---

[PATCH] fetch: ensure submodule objects fetched

Currently when git-fetch is asked to recurse into submodules, it dispatches a plain "git-fetch -C " (with some submodule related options such as prefix and recusing strategy, but) without any information of the remote or the tip that should be fetched. But this default fetch is not sufficient, as

Re: [wishlist] git submodule update --reset-hard

On Thu, 06 Dec 2018, Stefan Beller wrote: > On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko > wrote: > > Dear Git Gurus, > > I wondered what would be your take on my wishlist request to add > > --reset-hard option, which would be very similar to regular "update" which > > checks out

[PATCH v2 2/3] commit-graph: fix buffer read-overflow

fuzz-commit-graph identified a case where Git will read past the end of a buffer containing a commit graph if the graph's header has an incorrect chunk count. A simple bounds check in parse_commit_graph() prevents this. Signed-off-by: Josh Steadmon --- commit-graph.c | 14

[PATCH v2 3/3] Makefile: correct example fuzz build

Signed-off-by: Josh Steadmon --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 6b72f37c29..bbcfc2bc9f 100644 --- a/Makefile +++ b/Makefile @@ -3104,7 +3104,7 @@ cover_db_html: cover_db # An example command to build against libFuzzer from

[PATCH v2 1/3] commit-graph, fuzz: Add fuzzer for commit-graph

Breaks load_commit_graph_one() into a new function, parse_commit_graph(). The latter function operates on arbitrary buffers, which makes it suitable as a fuzzing target. Since parse_commit_graph() is only called by load_commit_graph_one() (and the fuzzer described below), we omit error messages

[PATCH v2 0/3] Add commit-graph fuzzer and fix buffer overflow

Add a new fuzz test for the commit graph and fix a buffer read-overflow that it discovered. Additionally, fix the Makefile instructions for building fuzzers. Changes since V1: * Moved the parse_commit_graph() declaration to the header file, since we don't mind if others use it. * Moved

Re: git, monorepos, and access control

Hi, On Wed, 5 Dec 2018, Jeff King wrote: > The model that fits more naturally with how Git is implemented would be > to use submodules. There you leak the hash of the commit from the > private submodule, but that's probably obscure enough (and if you're > really worried, you can add a random

Re: enhancement: support for author.email and author.name in "git config"

On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote: > Hi William, > > [...] > > This idea was floated a couple of months ago [1]. Junio seemed to find > the request sensible and outlined a design. No patches materialized, as > far as I know, but that could be because Eric suggested a

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 06.12.18 um 01:58 schrieb Junio C Hamano: > Frank Schäfer writes: > >> Just to be sure that I'm not missing anything here: >> What's your definition of "LF in repository, CRLF in working tree" in >> terms of config parameters ? > :::Documentation/config/core.txt::: > > core.autocrlf:: >

Re: [RFC PATCH] Introduce "precious" file concept

On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote: > Personally, I would rather err on the side which requires the least > interaction from users to avoid silently clobbering an ignored file. > > Either Duy's solution with a sort of "untracked" reflog, or the > garbage/trashable notion. The

Re: enhancement: support for author.email and author.name in "git config"

Hi William, On Thu, 6 Dec 2018 at 19:18, William Hubbs wrote: > We are in a situation where we would like to use author information that is > different from committer information when we commit to certain > repositories. [...] > [...] I would like to propose the addition of author.email and >

Re: [wishlist] git submodule update --reset-hard

On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko wrote: > > Dear Git Gurus, > > I wondered what would be your take on my wishlist request to add > --reset-hard option, which would be very similar to regular "update" which > checks out necessary commit, but I want it to remain in the branch.

enhancement: support for author.email and author.name in "git config"

Hi all, We are in a situation where we would like to use author information that is different from committer information when we commit to certain repositories. Currently, it looks like there are two ways to do this, and I'm not sure how to make either of them work well. There are the

Re: A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others

On Thu, Dec 6, 2018 at 6:58 AM Phillip Wood wrote: > > So is there some "must be at least two consecutive lines" condition for > > not-plain, or is something else going on here? > > To be considered a block has to have 20 alphanumeric characters - see > commit f0b8fb6e59 ("diff: define block by

[wishlist] git submodule update --reset-hard

Dear Git Gurus, I wondered what would be your take on my wishlist request to add --reset-hard option, which would be very similar to regular "update" which checks out necessary commit, but I want it to remain in the branch. Rationale: In DataLad we heavily rely on submodules, and we have

Re: [BUG REPORT] Git does not correctly replay bisect log

On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote: > > When Git replays the bisect log, it only updates refs/bisect/bad, > > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in > > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies > > that all good

Re: [BUG REPORT] Git does not correctly replay bisect log

Hi, On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote: > > Hello again, > > after looking into this today, I'm not sure if this can be considered a > bug - it's just that I expected Git to check out the exact commit to > test that was there before resetting the bisect. That made me uncertain >

[PATCH] Indent code with TABs

We indent with TABs and sometimes for fine alignment, TABs followed by spaces, but never all spaces (unless the indentation is less than 8 columns). Indenting with spaces slips through in some places. Fix them. Imported code and compat/ are left alone on purpose. The former should remain as close

Re: gitweb: local configuration not found

Hello! > Yeah, it does look indirect. Despite what you said, it also would > support users giving an absolute path via GITWEB_CONFIG. > > With "use File::Spec", perhaps something like this? Yes, this looks right. Martin

Re: A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others

Hi Ævar On 06/12/2018 13:54, Ævar Arnfjörð Bjarmason wrote: Let's ignore how bad this patch is for git.git, and just focus on how diff.colorMoved treats it: diff --git a/builtin/add.c b/builtin/add.c index f65c172299..d1155322ef 100644 --- a/builtin/add.c +++

Re: [BUG REPORT] Git does not correctly replay bisect log

Hello again, after looking into this today, I'm not sure if this can be considered a bug - it's just that I expected Git to check out the exact commit to test that was there before resetting the bisect. That made me uncertain whether Git restored the correct state. When I looked at what Git

How to investigate further a seemingly 'ghost' commit (after a merge)?

Hello, I am trying to understand how a fix from a bug-correction branch vanished and the bug found its way back into the main branch after two merges. I am using git version 2.19.2. Checkouting tag 18.40.1 and checking its graph: > $ git checkout 18.40.1 > > $ git log --oneline --graph

A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others

Let's ignore how bad this patch is for git.git, and just focus on how diff.colorMoved treats it: diff --git a/builtin/add.c b/builtin/add.c index f65c172299..d1155322ef 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -6,5 +6,3 @@ #include "cache.h" -#include

Re: [PATCH 2/2] commit-graph: fix buffer read-overflow

On 12/5/2018 5:32 PM, Josh Steadmon wrote: + if (chunk_lookup + GRAPH_CHUNKLOOKUP_WIDTH > data + graph_size) { + error(_("chunk lookup table entry missing; graph file may be incomplete")); + free(graph); + return NULL; +

[PATCH] docs: fix $strict_export text in gitweb.conf.txt

The section used to discussed $gitweb_export_ok and $gitweb_list, but gitweb Perl code does not have such variables (this likely hangs over from GITWEB_EXPORT_OK and GITWEB_LIST respectively). Fix the section to spell $export_ok and $projects_list like the rest of the document. Signed-off-by:

Re: [PATCH v2] l10n: update German translation

Hi, thanks for your great work! Just two remarks: #: midx.c:407 -#, fuzzy, c-format +#, c-format msgid "failed to add packfile '%s'" -msgstr "Fehler beim Lesen der Reihenfolgedatei '%s'." +msgstr "Fehler beim Hinzufügen von Packdatei'%s'." A Space is missing: "Fehler beim Hinzufügen von

[no subject]

-- ATTENTION I want you to contact Fast Courier Express & Logistics so that swill send you the ATM card fast. mind you that as soon as you received your ATM card you have to be taking 5000 dollars every day until the total amount of your fund which is 3,8 million dollars okay contact them

Re: Any way to make git-log to enumerate commits?

On Thu, Dec 06, 2018 at 09:31:36AM +0900, Junio C Hamano wrote: > >> It would be great if git-log has a formatting option to insert an > >> index of the current commit since HEAD. > >> > >> It would allow after quitting the git-log to immediately fire up "git > >> rebase -i HEAD~index" instead

Bug: git add --patch does not honor "diff.noprefix"

Hi, When running "git add -p" on git version 2.19.2 and "diff.noprefix" set to true, it still shows the "a/" and "b/" prefixes. This issue has been reported in 2016 already[1], but is still there in 2.19.2. [1] https://public-inbox.org/git/e1d7329a-a54b-4d09-a72a-62eca8005...@gmail.com/T/ --

[ANNOUNCE] Git Contributor Summit Registration, Jan 31, 2019, Brussels

Registration is now open for the Contributor Summit at Git Merge. To recap from my earlier announcement[1]: When: Thursday, January 31, 2019. 10am-5pm. Where: The Egg[2], Brussels, Belgium What: Round-table discussion about Git Who: All contributors to Git or related projects in the Git

Re: git, monorepos, and access control

On Thu, Dec 06, 2018 at 10:17:24AM +0100, Ævar Arnfjörð Bjarmason wrote: > > The other major user of that feature I can think of is LFS. There Git > > ends up diffing the LFS pointers, not the big files. Which arguably is > > the wrong thing (you'd prefer to see the actual file contents diffed),

Re: git, monorepos, and access control

On Thu, Dec 06 2018, Jeff King wrote: > On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote: > >> Jeff King writes: >> >> > In my opinion this feature is so contrary to Git's general assumptions >> > that it's likely to create a ton of information leaks of the supposedly >> >

Git fetch prints unchanged branches‏

Hi, When running `git fetch` it returns every time the same 100+ branches that didn't change at all but still specifies them as new branches in the server. It also prints the branches that did change. I don't see this behavior in other repositories I contribute. how do I fix it? The same output

Re: git, monorepos, and access control

On Wed, Dec 05, 2018 at 11:42:09PM +, Coiner, John wrote: > > For instance, Git is very eager to try to find delta-compression > > opportunities between objects, even if they don't have any relationship > > within the tree structure. So imagine I want to know the contents of > > tree X. I

Re: git, monorepos, and access control

On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > In my opinion this feature is so contrary to Git's general assumptions > > that it's likely to create a ton of information leaks of the supposedly > > protected data. > > ... > > Yup, with

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

Jeff King writes: > Each "wait" will try to collect all processes, but may be interrupted by > a signal. So the correct number is actually "1 plus the number of times > the user hits ^C". Yeah and that is not bounded. It is OK not to catch multiple ^C that races with what we do, so having ane

Re: [WIP RFC 4/5] upload-pack: refactor writing of "packfile" line

Jonathan Tan writes: > @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct > output_state *os) > } > os->used += readsz; > > + if (!os->packfile_started) { > + os->packfile_started = 1; > + if (use_protocol_v2) > +

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Thu, Dec 06, 2018 at 09:22:23AM +0900, Junio C Hamano wrote: > > So the right number of waits is either "1" or "2". Looping means we do > > too many (which is mostly a harmless noop) or too few (in the off chance > > that you have only a single job ;) ). So it works out in practice. > > Well,

Re: [PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

Josh Steadmon writes: > diff --git a/fuzz-commit-graph.c b/fuzz-commit-graph.c > new file mode 100644 > index 00..420851d0d2 > --- /dev/null > +++ b/fuzz-commit-graph.c > @@ -0,0 +1,18 @@ > +#include "object-store.h" > +#include "commit-graph.h" > + > +struct commit_graph

[no subject]

We need to make sure everyone's contact information is up to date, please login with your corporate login and verify the information is correct: Click here We need to have this list updated within 24hrs, so please make this a priority. Thank You

Re: [PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

Junio C Hamano writes: >> +if (graph_size < GRAPH_MIN_SIZE) >> +return NULL; >> + > > The load_commit_graph_one() grabbed graph_map out of xmmap() so it > is guaranteed to be non-NULL, but we need to check graph_map != NULL > when we're calling this directly from the fuzz tests,

Re: [PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

Josh Steadmon writes: > @@ -108,27 +106,61 @@ struct commit_graph *load_commit_graph_one(const char > *graph_file) > die(_("graph file %s is too small"), graph_file); > } > graph_map = xmmap(NULL, graph_size, PROT_READ, MAP_PRIVATE, fd, 0); > + ret =

Re: [PATCH v3] list-objects.c: don't segfault for missing cmdline objects

Matthew DeVore writes: > When a command is invoked with both --exclude-promisor-objects, > --objects-edge-aggressive, and a missing object on the command line, > the rev_info.cmdline array could get a NULL pointer for the value of > an 'item' field. Prevent dereferencing of a NULL pointer in

Re: git, monorepos, and access control

Jeff King writes: > In my opinion this feature is so contrary to Git's general assumptions > that it's likely to create a ton of information leaks of the supposedly > protected data. > ... Yup, with s/implemented/designed/, I agree all you said here (snipped). > Sorry I don't have a more

Re: [PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

On 2018.12.05 23:48, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Dec 05 2018, Josh Steadmon wrote: > > > Breaks load_commit_graph_one() into a new function, > > parse_commit_graph(). The latter function operates on arbitrary buffers, > > which makes it suitable as a fuzzing target. > > > > Adds

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Frank Schäfer writes: > Just to be sure that I'm not missing anything here: > What's your definition of "LF in repository, CRLF in working tree" in > terms of config parameters ? :::Documentation/config/core.txt::: core.autocrlf:: Setting this variable to "true" is the same as setting

Re: gitweb: local configuration not found

Ævar Arnfjörð Bjarmason writes: >> Documentation says "If you are absolutely certain that you want your >> script to load and execute a file from the current directory, then use >> a ./ prefix". We can do that, like so: >> >> diff --git i/gitweb/Makefile w/gitweb/Makefile >> index

Re: Any way to make git-log to enumerate commits?

Konstantin Khomoutov writes: > On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote: > >> It would be great if git-log has a formatting option to insert an >> index of the current commit since HEAD. >> >> It would allow after quitting the git-log to immediately fire up "git >>

Re: git, monorepos, and access control

On Wed, Dec 05, 2018 at 04:01:05PM -0500, Jeff King wrote: > You could work around that by teaching the server to refuse to use "X" > in any way when the client does not have the right permissions. But: > > - that's just one example; there are probably a number of such leaks > > - you're

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

Jeff King writes: > But the ^C case is interesting. Try running your script under "sh -x" > and hitting ^C. The signal interrupts the first wait. In my script (or > yours modified to use a single wait), we then proceed immediately to the > "exit", and get output from the subshells after we've

Re: git, monorepos, and access control

inline... On 12/05/2018 04:12 PM, Ævar Arnfjörð Bjarmason wrote: > On Wed, Dec 05 2018, Duy Nguyen wrote: > >> >> Another option is builtin per-blob encryption (maybe with just >> clean/smudge filter), then access control will be about obtaining the >> decryption key (*) and we don't break object

Re: [PATCH on sb/more-repo-in-api] revision: use commit graph in get_reference()

Jonathan Tan writes: > Looking at the bigger picture, the speed of the connectivity check > during a fetch might be further improved by passing only the negotiation > tips (obtained through --negotiation-tip) instead of "--all". This patch > just handles the low-hanging fruit first. That sounds

Re: [PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

On Wed, Dec 05 2018, Josh Steadmon wrote: > Breaks load_commit_graph_one() into a new function, > parse_commit_graph(). The latter function operates on arbitrary buffers, > which makes it suitable as a fuzzing target. > > Adds fuzz-commit-graph.c, which provides a fuzzing entry point >

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Johannes Sixt writes: > Am 05.12.18 um 16:37 schrieb Elijah Newren: >> On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote: >>> >>> Johannes Sixt writes: >>> Please let me deposit my objection. This paragraph is not the right place to explain what directory renme detection is and

Re: git, monorepos, and access control

On Wed, Dec 05 2018, Coiner, John wrote: I forgot to mention this in my initial reply in <878t13zp8y@evledraar.gmail.com>, but on a re-reading I re-spotted this: > - hashes are secret. If the hashes from a protected tree leak, the > data also leaks. No check on the server prevents it

[PATCH 2/2] commit-graph: fix buffer read-overflow

fuzz-commit-graph identified a case where Git will read past the end of a buffer containing a commit graph if the graph's header has an incorrect chunk count. A simple bounds check in parse_commit_graph() prevents this. Signed-off-by: Josh Steadmon Helped-by: Derrick Stolee --- commit-graph.c

[PATCH 1/2] commit-graph, fuzz: Add fuzzer for commit-graph

Breaks load_commit_graph_one() into a new function, parse_commit_graph(). The latter function operates on arbitrary buffers, which makes it suitable as a fuzzing target. Adds fuzz-commit-graph.c, which provides a fuzzing entry point compatible with libFuzzer (and possibly other fuzzing engines).

[PATCH 0/2] Add commit-graph fuzzer and fix buffer overflow

Add a new fuzz test for the commit graph and fix a buffer read-overflow that it discovered. Josh Steadmon (2): commit-graph, fuzz: Add fuzzer for commit-graph commit-graph: fix buffer read-overflow .gitignore | 1 + Makefile| 1 + commit-graph.c | 76

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

On 11/21/2018 01:00 AM, Junio C Hamano wrote: * md/list-lazy-objects-fix (2018-10-29) 1 commit - list-objects.c: don't segfault for missing cmdline objects "git rev-list --exclude-promissor-objects" had to take an object that does not exist locally (and is lazily available) from the

Re: [PATCH 2/3] test-lib-functions: introduce the 'test_set_port' helper function

On Wed, Dec 05, 2018 at 01:20:35PM +0100, SZEDER Gábor wrote: > On Wed, Dec 05, 2018 at 12:17:09AM -0500, Jeff King wrote: > > On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote: > > > > > Several test scripts run daemons like 'git-daemon' or Apache, and > > > communicate with them

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05, 2018 at 03:01:06PM +0100, SZEDER Gábor wrote: > > > - Make '--stress' imply '--verbose-log' and discard the test's > > > standard ouput and error; dumping the output of several parallel > > > tests to the terminal would create a big ugly mess. > > > > Makes sense. My

[PATCH v3] list-objects.c: don't segfault for missing cmdline objects

When a command is invoked with both --exclude-promisor-objects, --objects-edge-aggressive, and a missing object on the command line, the rev_info.cmdline array could get a NULL pointer for the value of an 'item' field. Prevent dereferencing of a NULL pointer in that situation. Properly handle

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05, 2018 at 11:34:54AM +0100, SZEDER Gábor wrote: > > Just a quick reply to this one point for now: > > On Wed, Dec 05, 2018 at 12:44:09AM -0500, Jeff King wrote: > > On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote: > > > + job_nr=0 > > > + while test $job_nr -lt

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 05.12.18 um 20:29 schrieb Frank Schäfer: Am 02.12.18 um 22:22 schrieb Johannes Sixt: Am 02.12.18 um 20:31 schrieb Frank Schäfer: With other words: "If CR comes immediately before a LF, do the following with *all* lines: after the CR if eol=lf but do not after the CR if eol=crlf." Why?

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Am 05.12.18 um 16:37 schrieb Elijah Newren: On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote: Johannes Sixt writes: Please let me deposit my objection. This paragraph is not the right place to explain what directory renme detection is and how it works under the hood. "works fine" in

Re: git, monorepos, and access control

On Wed, Dec 05 2018, Duy Nguyen wrote: > On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote: >> This directory-level security is not a goal for VFS for Git, and I don't >> see itbecoming a priority as it breaks a number of design decisions we >> made in our object storage and communication

Re: git, monorepos, and access control

On Wed, Dec 05, 2018 at 08:13:16PM +, Coiner, John wrote: > One obstacle to moving AMD to git/VFSForGit is the lack of access > control support in git. AMD has a lot of data whose distribution must be > limited. Sometimes it's a legal requirement, eg. CPU core designs are > covered by US

Re: git, monorepos, and access control

On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote: > This directory-level security is not a goal for VFS for Git, and I don't > see itbecoming a priority as it breaks a number of design decisions we > made in our object storage and communication models. > > The best I can think about when

Re: git, monorepos, and access control

On 12/5/2018 3:34 PM, Ævar Arnfjörð Bjarmason wrote: On Wed, Dec 05 2018, Coiner, John wrote: I'm an engineer with AMD. I'm looking at whether we could switch our internal version control to a monorepo, possibly one based on git and VFSForGit. Has anyone looked at adding access control to

Re: git, monorepos, and access control

On Wed, Dec 05 2018, Coiner, John wrote: > I'm an engineer with AMD. I'm looking at whether we could switch our > internal version control to a monorepo, possibly one based on git and > VFSForGit. > > One obstacle to moving AMD to git/VFSForGit is the lack of access > control support in git.

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

On Wed, Dec 05, 2018 at 07:41:44PM +0100, René Scharfe wrote: > > If we start to convert those, there's a > > little bit of a rabbit hole, but it's actually not too bad. > > You don't need to crawl in just for quick_has_loose(), but eventually > everything has to be converted. It seems a bit

git, monorepos, and access control

Hi, I'm an engineer with AMD. I'm looking at whether we could switch our internal version control to a monorepo, possibly one based on git and VFSForGit. One obstacle to moving AMD to git/VFSForGit is the lack of access control support in git. AMD has a lot of data whose distribution must be

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05 2018, SZEDER Gábor wrote: > On Wed, Dec 05, 2018 at 03:01:41PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >> decide to stress test in advance, since we'd either flock() the trash >> >> dir, or just mktemp(1)-it. >> > >> > While 'mktemp' seems to be more portable than 'flock', it

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 03.12.18 um 02:15 schrieb Junio C Hamano: > Frank Schäfer writes: > >> Hi Junio, >> >> Am 29.11.18 um 03:11 schrieb Junio C Hamano: >> [...] >>> This was misspoken a bit. Let's revise it to >>> >>> When producing a colored output (not limited to whitespace >>> error coloring of diff

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 02.12.18 um 22:22 schrieb Johannes Sixt: > Am 02.12.18 um 20:31 schrieb Frank Schäfer: >> With other words: >> "If CR comes immediately before a LF, do the following with *all* lines: >> after the CR if eol=lf but do not after the CR if >> eol=crlf." > > Why? It is the pager's duty to

Re: gitweb: local configuration not found

On Wed, Dec 05 2018, Jonathan Nieder wrote: > Martin Mares wrote[1]: > >> After upgrade to Stretch, gitweb no longer finds the configuration file >> "gitweb_config.perl" in the current directory. However, "man gitweb" still >> mentions this as one of the possible locations of the config file

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 05.12.2018 um 09:15 schrieb Jeff King: > On Wed, Dec 05, 2018 at 01:51:36AM -0500, Jeff King wrote: > >>> This >>> function is easily converted to struct object_id, though, as its single >>> caller can pass one on -- this makes the copy unnecessary. >> >> If you mean modifying

gitweb: local configuration not found

Martin Mares wrote[1]: > After upgrade to Stretch, gitweb no longer finds the configuration file > "gitweb_config.perl" in the current directory. However, "man gitweb" still > mentions this as one of the possible locations of the config file (and > indeed a useful one when using multiple

Re: [RFC] cherry-pick notes to find out cherry-picks from the origin

Hello, Jeff. On Thu, Nov 15, 2018 at 09:40:44AM -0500, Jeff King wrote: > Sorry for the slow reply. This was on my to-look-at pile, but for > some reason I accidentally put in my done pile. No worries and sorry about my late reply too. Things were a bit hectic. > > * A new built-in command

Re: Any way to make git-log to enumerate commits?

On Dez 05 2018, Elijah Newren wrote: > Or, just use name-rev so it works with non-linear histories too: > > git log | git name-rev --refs=$(git symbolic-ref HEAD) --stdin | less That wouldn't work for a detached HEAD, though, and you need to use --no-abbrev. Andreas. -- Andreas Schwab,

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote: > > Johannes Sixt writes: > > > Please let me deposit my objection. This paragraph is not the right > > place to explain what directory renme detection is and how it works > > under the hood. "works fine" in the original text is the right

Re: Any way to make git-log to enumerate commits?

On Wed, Dec 5, 2018 at 6:56 AM Konstantin Khomoutov wrote: > > On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote: > > > It would be great if git-log has a formatting option to insert an > > index of the current commit since HEAD. > > > > It would allow after quitting the

Re: Any way to make git-log to enumerate commits?

On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote: > It would be great if git-log has a formatting option to insert an > index of the current commit since HEAD. > > It would allow after quitting the git-log to immediately fire up "git > rebase -i HEAD~index" instead of "git

Re: [RFC PATCH 3/3] test-lib: add the '--stress' option to run a test repeatedly under load

On Wed, Dec 05, 2018 at 03:01:41PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> decide to stress test in advance, since we'd either flock() the trash > >> dir, or just mktemp(1)-it. > > > > While 'mktemp' seems to be more portable than 'flock', it doesn't seem > > to be portable enough; at least

<    1   2   3   4   5   6   7   8   9   10   >