After we set up a `struct repository_format`, it owns various pieces of
allocated memory. We then either use those members, because we decide we
want to use the "candidate" repository format, or we discard the
candidate / scratch space. In the first case, we transfer ownership of
the memory to a fe
If `read_repository_format()` encounters an error, `format->version`
will be -1 and all other fields of `format` will be undefined. However,
in `setup_git_directory_gently()`, we use `repo_fmt.hash_algo`
regardless of the value of `repo_fmt.version`.
This can be observed by adding this to the end
Patch 3 adds `clear_repository_format()` to plug a few memory leaks
related to `struct repository_format`. In preparation for that, patch 2
tightens up some code which uses a possibly-undefined value from the
struct. Patch 1 drops a return value that no-one has ever used.
Cc-ing Peff, who introduc
No-one looks at the return value, so we might as well drop it. It's
still available as `format->version`.
In v1 of what became commit 2cc7c2c737 ("setup: refactor repo format
reading and verification", 2016-03-11), this function actually had
return type "void", but that was changed in v2. Almost t
On Mon, 17 Dec 2018 at 22:56, Jonathan Nieder wrote:
> That makes experimenting with the stripspace command unnecessarily
> fussy. Fix it by discovering the git directory gently, as intended
> all along.
> if (mode == STRIP_COMMENTS || mode == COMMENT_LINES) {
> - setup_git
Hi,
Jonathan Tan wrote:
> When setup_alternate_shallow() is invoked a second time in the same
> process, it fails with the error "shallow file has changed since we read
> it". One way of reproducing this is to fetch using protocol v2 in such a
> way that backfill_tags() is required, and that the
Hi Junio, thanks for your feedback. I'll submit a new patch as soon as
I've addressed all the feedback.
On Mon, Dec 17, 2018 at 1:31 AM Junio C Hamano wrote:
>
> Issac Trotts writes:
>
> > Make it possible to write for example
> >
> > git log --format="%H,%S"
> >
> > where the %S at the
When setup_alternate_shallow() is invoked a second time in the same
process, it fails with the error "shallow file has changed since we read
it". One way of reproducing this is to fetch using protocol v2 in such a
way that backfill_tags() is required, and that the responses to both
requests contain
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>> This would make per-branch ACLs (as implemented both by Gerrit and
>> gitolite) an essentially useless feature, so please no.
>
> Doesn't Gerrit always use JGit?
>
> The discussion upthread is about what we should do a
On Mon, Dec 17 2018, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>> On Fri, Dec 14, 2018 at 11:55:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>>> More importantly this bypasses the security guarantee we've had with the
>>> default of uploadpack.allowAnySHA1InWant=false.
>>
>> IMHO those s
Hi,
Jeff King wrote:
> On Fri, Dec 14, 2018 at 11:55:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> More importantly this bypasses the security guarantee we've had with the
>> default of uploadpack.allowAnySHA1InWant=false.
>
> IMHO those security guarantees there are overrated (due to delta
> gue
On December 17, 2018 5:57:50 PM EST, "Ævar Arnfjörð Bjarmason"
wrote:
>
>On Mon, Dec 17 2018, David Turner wrote:
>
>> Overall, I like this. One nit:
>
>Thanks for the review!
>
>> On December 17, 2018 5:16:25 PM EST, "Ævar Arnfjörð Bjarmason"
> wrote:
>>>--- a/upload-pack.c
>>>+++ b/upload-pa
On Mon, Dec 17 2018, David Turner wrote:
> Overall, I like this. One nit:
Thanks for the review!
> On December 17, 2018 5:16:25 PM EST, "Ævar Arnfjörð Bjarmason"
> wrote:
>>--- a/upload-pack.c
>>+++ b/upload-pack.c
>>@@ -54,7 +54,8 @@ static int no_progress, daemon_mode;
>> #define ALLOW_REA
Guys, having git merge --dry-run would be great, but I am OK with git
merge for real as long as its output is parseable.
However, somewhere in between git 2.18 and git 2.20 the output of
merge changed and now I do not know how to parse it.
it used to be something like that:
bla bla bla
file name
Overall, I like this. One nit:
On December 17, 2018 5:16:25 PM EST, "Ævar Arnfjörð Bjarmason"
wrote:
>--- a/upload-pack.c
>+++ b/upload-pack.c
>@@ -54,7 +54,8 @@ static int no_progress, daemon_mode;
> #define ALLOW_REACHABLE_SHA1 02
>/* Allow request of any sha1. Implies ALLOW_TIP_SHA1 and
>ALL
From: Jonathan Tan
When the scaffolding for protocol version 2 was initially added in
8f6982b4e1 ("protocol: introduce enum protocol_version value
protocol_v2", 2018-03-14). As seen in:
git log -p -G'support for protocol v2 not implemented yet' --full-diff
--reverse v2.17.0..v2.20.0
Many o
From: Jeff King
In protocol v2, instead of just running "upload-pack", we have a generic
"serve" loop which runs command requests from the client. What used to
be "upload-pack" is now generally split into two operations: "ls-refs"
and "fetch". The latter knows it must respect uploadpack.* config,
From: Jeff King
This helper function looks for config in two places: transfer.hiderefs,
or $section.hiderefs, where $section is passed in by the caller (and is
"uploadpack" or "receive", depending on the context).
In preparation for callers which do not even have that context (namely
the "git-se
From: Jeff King
In the v2 protocol, upload-pack's advertisement has been moved to the
"ls-refs" command. That command does not respect hidden-ref config (like
transfer.hiderefs) at all, and advertises everything.
While there are some features that are not supported in v2 (e.g., v2
always allows
The v2 of this series conflicted with Josh Steadmon's work when merged
in "pu". That's still outstanding, see
https://public-inbox.org/git/87h8ff20ol@evledraar.gmail.com/
Then my just-sent
https://public-inbox.org/git/20181217221625.1523-1-ava...@gmail.com/
conflicts with even more things in i
Unconditionally turn on uploadpack.allowAnySHA1InWant=true which means
that the lesser uploadpack.allow{Tip,Reachable}SHA1InWant settings are
implicitly "true" as well.
This is because as mentioned in 235ec24352e ("doc: mention transfer
data leaks in more places", 2016-11-14) this has always been
On Tue, Dec 11, 2018 at 01:42:45PM +0100, SZEDER Gábor wrote:
> > But looking at what this is replacing:
> >
> > > -case "$GIT_TEST_TEE_STARTED, $* " in
> > > -done,*)
> > > - # do not redirect again
> > > - ;;
> > > -*' --tee '*|*' --va'*|*' -V '*|*' --verbose-log '*)
>
>
> Anyway, I had anoth
On Thu, Dec 13, 2018 at 02:18:26PM -0800, Josh Steadmon wrote:
> On 2018.12.12 17:17, Masaya Suzuki wrote:
> > On Wed, Dec 12, 2018 at 3:02 AM Jeff King wrote:
> > > This ERR handling has been moved to a very low level. What happens if
> > > we're passing arbitrary data via the packet_read() code
On Fri, Dec 14, 2018 at 1:31 PM Derrick Stolee wrote:
>
> Please double-check that you have the 'core.commitGraph' config setting
> enabled, or you will not read the commit-graph at run-time:
>
> git config core.commitGraph true
>
Yeah, this is what happens when trying too many things at onc
did hOn Fri, Dec 14, 2018 at 11:10 AM Bryan Turner
wrote:
>
> After you converted the repository from CVS to Git, did you run a manual
> repack?
>
> The process of converting a repository from another SCM often results
> in poor delta chain selections which result in a repository that's
> unneces
On Fri, Dec 14, 2018 at 2:48 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Dec 14 2018, Clement Moyroud wrote:
>
> > My group at work is migrating a CVS repo to Git. The biggest issue we
> > face so far is the performance of git blame, especially compared to
> > CVS on the same file. One file es
On Fri, Dec 14, 2018 at 11:07:03AM -0500, John Passaro wrote:
> Then I might rename the other new placeholders too:
>
> %Gs: signed commit signature (blank when unsigned)
> %Gp: signed commit payload (i.e. in practice minus the gpgsig header;
> also blank when unsigned as well)
One complication:
On Fri, Dec 14, 2018 at 12:08:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Also, parts of the v2 code, e.g. this in 685fbd3291 ("fetch-pack:
> perform a fetch using v2", 2018-03-15):
>
> /* v2 supports these by default */
> allow_unadvertised_object_request |= ALLOW_REACHABLE_SHA1;
>
On Fri, Dec 14, 2018 at 11:55:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > An interesting implication of this at GitHub (and possibly other
> > hosters) is that it exposes objects from shared storage via unexpected
> > repos. If I fork torvalds/linux to peff/linux and push up object X, a v0
> >
On Sun, Dec 16, 2018 at 04:52:13PM -0500, Farhan Khan wrote:
> It seems that there is a 12 byte header (signature, version, number of
> objects), then it immediately jumps into each individual object. The
> object consists of the object header, then the zlib deflated object,
> followed by a SHA1 o
On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren wrote:
>
> On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:
> >
> > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
> > wrote:
> > >
> > > Hi,
> > > I have asked this question on SO
> > > (https://stackoverflow.com/questions/53679167/can-git-tell-me
On Mon, Dec 17, 2018 at 07:49:00PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > The answer that gives will be overly broad (e.g., in a case where our
> > local branch had touched file "foo" but other side had not, we'd
> > consider "foo" as a difference the two-point diff-tree, whereas a real
> > 3-w
On Mon, Dec 17 2018, Jeff King wrote:
> On Mon, Dec 17, 2018 at 08:08:49AM -0500, Mark Kharitonov wrote:
>
>> C:\Dayforce\test [master ↓2 +0 ~2 -0 !]> git pull
>> error: Your local changes to the following files would be
>> overwritten by merge:
>> 2.txt
>> Please commit
On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:
>
> On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
> wrote:
> >
> > Hi,
> > I have asked this question on SO
> > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
> > and usuall
v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
improved stripspace --strip-comments / --comentlines by teaching them
to read repository config, but it went a little too far: when running
stripspace outside any repository, the result is
$ git stripspace --strip-commen
On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
wrote:
>
> Hi,
> I have asked this question on SO
> (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
> and usually there are tons of responses on Git questions, but not on
> this o
On Mon, Dec 17, 2018 at 08:08:49AM -0500, Mark Kharitonov wrote:
> C:\Dayforce\test [master ↓2 +0 ~2 -0 !]> git pull
> error: Your local changes to the following files would be
> overwritten by merge:
> 2.txt
> Please commit your changes or stash them before you merge.
>
On Sun, Dec 16, 2018 at 10:25:14PM -0800, Issac Trotts wrote:
> Make it possible to write for example
>
> git log --format="%H,%S"
>
> where the %S at the end is a new placeholder that prints out the ref
> (tag/branch) for each commit.
Seems like a reasonable thing to want.
One curious
On Sun, Dec 16, 2018 at 04:14:46PM -0800, Jonathan Nieder wrote:
> Hi,
>
> Farhan Khan wrote:
> >> Farhan Khan wrote:
>
> >>> I am having trouble figuring out the boundary between two objects in
> >>> the pack file.
> [...]
> > I think the issue is, the compressed object has a fixed
On 12/17/2018 9:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Dec 17 2018, Derrick Stolee wrote:
As for adding progress to this step, I'm open to it. It can be done as
a sequel series.
Okey. To clarify I wasn't complaining about the lack of progress output,
we didn't have it before, just clar
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-46.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
On Mon, Dec 17 2018, Derrick Stolee wrote:
> On 12/14/2018 6:32 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote:
>>
>>> Despite these potential drawbacks, the benefits of the algorithm
>>> are clear. By adding a counter to 'add_children_by_path' a
On 12/14/2018 6:32 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote:
Despite these potential drawbacks, the benefits of the algorithm
are clear. By adding a counter to 'add_children_by_path' and
'mark_tree_contents_uninteresting', I measured the numb
Hi,
I have asked this question on SO
(https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
and usually there are tons of responses on Git questions, but not on
this one.
Allow me to quote it now.
Please, observe:
C:\Dayforce\te
Hi Gábor,
On Sat, 15 Dec 2018, SZEDER Gábor wrote:
> On Sat, Dec 15, 2018 at 02:14:56AM -0500, Gennady Uraltsev wrote:
> > I am on git version 2.20.0
> >
> > $ git remote
> >
> > does not show remotes configured in named files in $GIT_DIR/remotes/
> >
> > I do not think that this is the intende
Issac Trotts writes:
> Make it possible to write for example
>
> git log --format="%H,%S"
>
> where the %S at the end is a new placeholder that prints out the ref
> (tag/branch) for each commit.
>
> Using %d might seem like an alternative but it only shows the ref for
> the last commit in
46 matches
Mail list logo
