"Randall S. Becker" writes:
> On January 14, 2019 12:46, Junio C Hamano wrote:
>> Barret Rhoden writes:
>>
>> > On 2019-01-10 at 14:29 Junio C Hamano wrote:
>> >> > For instance, commit X does this:
>> >> >
>> >> > -foo(x,y);
>> >> > +foo(x,y,z);
>> >> >
>> >> > Then commit Y comes along to re
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> In short, are you shooting js/smart-http-detect-remote-error topic
>> down and replacing it with this one?
>>
>> As that topic is not yet in 'next', I am perfectly fine doing that.
>> I just want to make sure that is what you meant, as my reading o
Hi,
Junio C Hamano wrote:
> Masaya Suzuki writes:
>> This makes it possible for servers to send an error message back to clients
>> in
>> an arbitrary situation.
Yay! Yes, this should simplify server implementations and user support.
[...]
> In short, are you shooting js/smart-http-detect-re
Josh Steadmon wrote:
> I am not very familiar with most of the submodule code, but for what
> it's worth, this entire series looks good to me. I'll note that most of
> the commits caused some style complaints, but I'll leave it up to your
> judgement as to whether they're valid or not.
>
> Reviewe
Hi,
In August, 2018, Brandon Williams wrote:
> Commit 0383bbb901 (submodule-config: verify submodule names as paths,
> 2018-04-30) introduced some checks to ensure that submodule names don't
> include directory traversal components (e.g. "../").
>
> This addresses the vulnerability identified in
Hi,
Jeff Hostetler wrote:
> This patch series contains a new trace2 facility that hopefully addresses
> the recent trace- and structured-logging-related discussions. The intent is
> to eventually replace the existing trace_ routines (or to route them to the
> new trace2_ routines) as time permits
When parsing a tree, we read the object ID directly out of the tree
buffer. This is normally fine, but such an object ID cannot be used with
oidcpy, which copies GIT_MAX_RAWSZ bytes, because if we are using SHA-1,
there may not be that many bytes to copy.
Instead, store the object ID in a separate
When we splice trees together, we operate in place on the tree buffer.
If we're using SHA-1 for the hash algorithm, we may not have a full
GIT_MAX_RAWSZ (32) bytes to copy. Consequently, it doesn't logically
make sense for us to use a struct object_id to represent this type,
since it isn't a comple
There are some situations in which we want to store an object ID into
struct object_id without the_hash_algo necessarily being set correctly.
One such case is when cloning a repository, where we must read refs from
the remote side without having a repository from which to read the
preferred algorit
In a future commit, the pointer returned by tree_entry_extract will
point into the struct tree_desc, causing its lifetime to be bound to
that of the struct tree_desc itself. To ensure this code path keeps
working, copy the object_id into a local variable so that it lives long
enough.
Signed-off-b
There are a small number of places in our codebase where we cast a
buffer of unsigned char to a struct object_id pointer. When we have
GIT_MAX_RAWSZ set to 32 (because we have SHA-256), one of these places
(the buffer for tree objects) can lead to us copying too much data when
using SHA-1 as the ha
Currently, the struct object_id pointer returned from tree_entry_extract
lives directly inside the parsed tree buffer. In a future commit, this
will change so that it instead points to a dedicated struct member.
Since in this code path, we want to modify the buffer directly, compute
the buffer offs
Perforce requires a complete list of files being operated on. If
git is updating an existing shelved changelist, then any files
which are moved were not being added to this list.
Signed-off-by: Luke Diamand
---
git-p4.py| 1 +
t/t9807-git-p4-submit.sh | 2 +-
2 files changed, 2 i
Updated as per comments from Junio, Eric.
https://public-inbox.org/git/20190113135815.11286-1-l...@diamand.org/
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move
git-p4: handle update of moved files when updating a shelve
git-p4.py| 1 +
t/t980
Updating a shelved P4 changelist where one or more files have
been moved does not work. Add a test for this.
The problem is that P4 requires a complete list of the files being
changed, and move/rename only includes the _source_ in the case of
updating a shelved changelist. This results in errors f
On January 14, 2019 10:07, Duy Nguyen wrote:
> To: Randall S. Becker
> Cc: Git Mailing List
> Subject: Re: [Possible Bug] Commit generates GC repack failure
>
> On Mon, Jan 14, 2019 at 10:03 PM Duy Nguyen
> wrote:
> >
> > On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker
> > wrote:
> > >
> > >
From: Jeff King
Date: Sun, 13 May 2018 14:14:34 -0400
This case is already forbidden by verify_path(), so let's
check it in fsck. It's easier to handle than .gitmodules,
because we don't care about checking the blob content. This
is really just about whether the name and mode for the tree
entry a
On Mon, Jan 14 2019, Matthieu Moy wrote:
> I haven't been active for a while on this list, but for those who don't
> know me, I'm a CS teacher and I'm regularly offering my students to
> contribute to open-source projects as part of their school projects. A
> few nice features like "git rebase -
Hi,
Stefan Beller wrote:
> Internally we have rolled out this as an experiment for
> "submodules replacing the repo tool[1]".
Thanks again for writing and explaining it. Here's an updated
version, basically identical (just rebased). "git range-diff" shows
mostly context lines affected, so this
Jonathan Tan writes:
> Currently, a response to a fetch request has sideband support only while
> the packfile is being sent, meaning that the server cannot send notices
> until the start of the packfile.
>
> Extend sideband support in protocol v2 fetch responses to the whole
> response. upload-p
Junio C Hamano writes:
> Lack of corresponding comment bothers readers. In all of
> REMOTE_ERROR, PROGRESS and PROTOCOL_ERROR cases, the other helper
> stuffs the message in outbuf in "switch (band) { ... }" and writes
> it out with xwrite(2, outbuf.buf, outbuf.len) [*1*], so I can see
> there i
Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Marc Branchaud wrote:
>>> The new workdir is empty before the checkout, so attempts to recurse into
>>> a non-existent submodule directory fail.
>>>
>>> Signed-off-by: Marc Branchaud
>>> ---
>>
>> Thanks for reporting. Can you describe the
Jonathan Nieder writes:
> https://public-inbox.org/git/2007080926.gc30...@elie.hsd1.il.comcast.net/
>
> Any idea what happened there? Would it be useful for me to rebase
> and revive that series?
No idea what happend there.
Anyway, I quickly read them over and found nothing questionable,
e
Jonathan Nieder writes:
>> The new workdir is empty before the checkout, so attempts to recurse into
>> a non-existent submodule directory fail.
>>
>> Signed-off-by: Marc Branchaud
>> ---
>
> Thanks for reporting. Can you describe the error message when it fails
> here?
>
>> Until the worktree
Hi,
Junio C Hamano wrote:
> Patterns with slash is anchored at
> one directory, and that directory is the one that has per-directory
> .gitignore file. Patterns without slash (including a pattern that
> ends with but otherwise has no other slash) are supposed to
Hi,
Marc Branchaud wrote:
> The new workdir is empty before the checkout, so attempts to recurse into
> a non-existent submodule directory fail.
>
> Signed-off-by: Marc Branchaud
> ---
Thanks for reporting. Can you describe the error message when it fails
here?
> Until the worktree command su
Greetings! I sent this letter to you 2days ago,but I'm not sure if you get
it,and this is the reason i repeat it again.Please get back to me for more
details.
Regards,
Khim Leang
Jonathan Tan writes:
> +int recv_sideband(const char *me, int in_stream, int out)
> +{
> + char buf[LARGE_PACKET_MAX + 1];
> + int retval = 0;
> + int len;
> +
> + while (1) {
> + len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX,
> 0);
> + re
Jonathan Tan writes:
The patch itself look quite noisy, but in esssense, at the lowest
level we used to have a single format_packet() that was used to
write out normal payload and an error message prefixed with "ERR ";
now the users of the function are updated to call one of the two
helper functi
> In other parts of the code we often have an early exit instead of
> setting a variable and reacting to that in the end, i.e. what
> do you think about:
>
> static void receive_shallow_info(struct fetch_pack_args *args,
> struct packet_reader *reader)
> {
> process_section_header(reader,
On 2019-01-14 at 13:26 "Randall S. Becker"
wrote:
> >
> > Sorry, I made a too-fuzzy statement. What I meant was, that unless you
> are
> > ignoring E, I do not know why you "would want to" attribute a line "foo(x,
> y,
> > z)" that appears in F to X. Starting from X up to D (and to Y in rea
Eric Sunshine writes:
> On Sun, Jan 13, 2019 at 8:58 AM Luke Diamand wrote:
>> Updating a shelved P4 changelist where one or more of the files have
>> been moved does not work. Add a test for this.
>
> Perhaps this message could give more detail about the actual problem
> than the generic "does
Luke Diamand writes:
> I found this bug recently in git-p4 - updating a shelved changelist where
> files
> are being moved doesn't work. The destination of any moves needs to be
> added to the list of files passed to P4.
Thanks.
>
> Luke Diamand (2):
> git-p4: add failing test for shelved CL
Maris Razvan writes:
> I was reading the gitignore documentation
> (https://git-scm.com/docs/gitignore), especially the following
> paragraph:
>
> "If the pattern does not contain a slash /, Git treats it as
> a shell glob pattern and checks for a match against the pathname
> relative to
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
Before assigning to `data->work_tree` in `read_worktree_config()`, free
any value we might already have picked up, so that we do not leak it.
Signed-off-by: Martin Ågren
---
setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/setup.c b/setup.c
index 1be5037f12..bb633942bb 100644
--- a/se
This patch series addresses memory leaks related to `struct
repository_format`. Compared to v1 [1], this v2 has dropped the first
patch ("setup: drop return value from `read_repository_format()`") and
added another patch 1/3 (which solves a different problem).
Patch 2/3 is unchanged. Patch 3/3 now
Alban Gruin writes:
> thank you for your patch. I left a few comments below.
>
> Le 11/01/2019 à 22:51, Stephen Boyd a écrit:
>> The Linux kernel receives many patches to the devicetree files each
>> release. The hunk header for those patches typically show nothing,
>> making it difficult to fig
Quoting Alban Gruin (2019-01-13 13:26:21)
> Hi Stephen,
>
> thank you for your patch. I left a few comments below.
>
> Le 11/01/2019 à 22:51, Stephen Boyd a écrit :
> > diff --git a/userdiff.c b/userdiff.c
> > index 97007abe5b16..2bc964e11089 100644
> > --- a/userdiff.c
> > +++ b/userdiff.c
> >
On January 14, 2019 12:46, Junio C Hamano wrote:
> Barret Rhoden writes:
>
> > On 2019-01-10 at 14:29 Junio C Hamano wrote:
> >> > For instance, commit X does this:
> >> >
> >> > -foo(x,y);
> >> > +foo(x,y,z);
> >> >
> >> > Then commit Y comes along to reformat it:
> >> >
> >> > -foo(x,y,z);
> >
Nickolai Belakovski writes:
> Not trying to paint anything one way or another. I found that these
> features got in the way of my workflows and didn't see any immediate
> reason why they had to exist. Thinking about it a bit more, is it
> unreasonable to delete a branch even if it's checked out i
Hi,
I haven't been active for a while on this list, but for those who don't
know me, I'm a CS teacher and I'm regularly offering my students to
contribute to open-source projects as part of their school projects. A
few nice features like "git rebase -i --exec" or many of the hints in
"git status"
Barret Rhoden writes:
> On 2019-01-10 at 14:29 Junio C Hamano wrote:
>> > For instance, commit X does this:
>> >
>> > -foo(x,y);
>> > +foo(x,y,z);
>> >
>> > Then commit Y comes along to reformat it:
>> >
>> > -foo(x,y,z);
>> > +foo(x, y, z);
>> >
>> > And the history / rev-list for the file look
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Until the worktree command supports submodules I've gone back to using the
git-new-workdir script, but it fails if my config has
submdodule.recurse
On January 14, 2019 10:12, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jan 14 2019, Randall S. Becker wrote:
>
> > Hi All,
> >
> > I'm trying to track down what happened this morning. We had a commit
> > that caused a background gc to occur. What happened was:
> >
> > $ git commit -m "history commit
On Mon, Jan 14, 2019 at 01:30:17AM +, brian m. carlson wrote:
> > > So the "most correct" thing is probably something like this:
> >
> > Of course, it would be nice if what I sent compiled. ;)
> >
> > rewrite_here does double duty: it's the pointer in the tree that we need
> > to rewrite, an
On 2019-01-10 at 14:29 Junio C Hamano wrote:
> > For instance, commit X does this:
> >
> > -foo(x,y);
> > +foo(x,y,z);
> >
> > Then commit Y comes along to reformat it:
> >
> > -foo(x,y,z);
> > +foo(x, y, z);
> >
> > And the history / rev-list for the file looks like:
> >
> > ---O---A---X---B---C-
On Mon, Jan 14 2019, Randall S. Becker wrote:
> Hi All,
>
> I'm trying to track down what happened this morning. We had a commit that
> caused a background gc to occur. What happened was:
>
> $ git commit -m "history commit ... "
> Auto packing the repository in background for optimum performanc
On Mon, Jan 14, 2019 at 10:03 PM Duy Nguyen wrote:
>
> On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker
> wrote:
> >
> > Hi All,
> >
> > I'm trying to track down what happened this morning. We had a commit that
> > caused a background gc to occur. What happened was:
> >
> > $ git commit -m "hist
On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker
wrote:
>
> Hi All,
>
> I'm trying to track down what happened this morning. We had a commit that
> caused a background gc to occur. What happened was:
>
> $ git commit -m "history commit ... "
> Auto packing the repository in background for optimum
Hi All,
I'm trying to track down what happened this morning. We had a commit that
caused a background gc to occur. What happened was:
$ git commit -m "history commit ... "
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
warning: The la
Thank you for the resolution.
I didn't know it was a plumbing command, hence
`--list-cmds=list-mainporcelain,others,nohelpers,alias,list-complete,config`
didn't inspire me further
Apologies for the non-important topic.
Ntentos Stavros
On Mon, Jan 14, 2019 at 3:36 PM Duy Nguyen wrote:
>
> On Mo
On Mon, Jan 14, 2019 at 7:19 PM Ντέντος Σταύρος wrote:
>
> I have install the latest git version from the PPA:
> $ git --version
> git version 2.20.1
> $ lsb_release -rd
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
>
> Running
> `https://github.com/git/git/blob/master/contrib/completion/git
FYI $ git --version
git version 2.20.1
solves this. I am not aware if you somehow track them / how to close
this thread.
Ntentos Stavros
On Tue, Oct 9, 2018 at 8:59 PM Stefan Beller wrote:
>
> On Tue, Oct 9, 2018 at 7:33 AM Ντέντος Σταύρος wrote:
> >
> > I have install the latest git version f
I have install the latest git version from the PPA:
$ git --version
git version 2.20.1
$ lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Running
`https://github.com/git/git/blob/master/contrib/completion/git-completion.bash#L2898`
does not give ls-files
$ git --list-cmds=list-main
Hi Slavica
On 20/12/2018 12:09, Slavica Djukic via GitGitGadget wrote:
> From: Slavica Djukic
>
> Change help_cmd sub in git-add--interactive.perl to use
> show-help command from builtin add--helper.
>
> Add test to t3701-add-interactive to verify that show-help
> outputs expected content. Use
Hi Salvica/Johannes
On 20/12/2018 12:09, Slavica Djukic via GitGitGadget wrote:
> From: Slavica Djukic
>
> To enable testing the colored output on Windows, enable TTY
> by using environment variable GIT_TEST_PRETEND_TTY.
>
> This is the original idea by Johannes Schindelin.
I normally use GIT_
Hi Slavica
I think the basics of this patch are fine, I've got a few comments below
On 20/12/2018 12:09, Slavica Djukic via GitGitGadget wrote:
> From: Slavica Djukic
>
> Implement show-help command in add-interactive.c and use it in
> builtin add--helper.c.
>
> Use command name "show-help" in
On Mon, Jan 14, 2019 at 4:02 AM Ramsay Jones
wrote:
>
>
> commit 8f7c7f ("config.c: add repo_config_set_worktree_gently()",
> 2018-12-27) adds three function declarations that cause the hdr-check
> make target to complain. The hdr-check complaint is caused by placing
> the new declarations, wh
62 matches
Mail list logo
