When unshelving a changelist, git-p4 tries to work out the appropriate
parent commit in a given branch (default: HEAD). To do this, it looks
at the state of any pre-existing files in the target Perforce branch,
omitting files added in the shelved changelist. Currently, only files
added (or move t
On Wed, May 22, 2019 at 06:49:38AM +0100, Luke Diamand wrote:
> On Tue, 21 May 2019 at 23:50, Simon Williams wrote:
> >
> > When unshelving a changelist, git-p4 tries to work out the appropriate
> > parent commit in a given branch (default: HEAD). To do this, it looks
> > at the state of any pre-
On Tue, 21 May 2019 at 23:50, Simon Williams wrote:
>
> When unshelving a changelist, git-p4 tries to work out the appropriate
> parent commit in a given branch (default: HEAD). To do this, it looks
> at the state of any pre-existing files in the target Perforce branch,
> omiting files added in t
On Tue, May 21, 2019 at 12:29:32AM +0200, Ævar Arnfjörð Bjarmason wrote:
> That added in 568508e765 ("bulk-checkin: replace fast-import based
> implementation", 2011-10-28) would compress the file with zlib, but
> was oblivious as to whether the content would actually be written out
> to disk, whi
On Mon, May 20, 2019 at 11:53:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Amend the intro to note that it's better to ask the index about files
> already tracked by it.
>
> I've seen uses of this in the wild where the use-case was finding
> object IDs for files found in a freshly cloned repo, i.
On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Clarify the hash-object docs to explicitly note that the --literally
> option guarantees that a loose object will be written, but that a
> normal -w ("write") invocation doesn't.
I had to double-check here: you mean that _
On Mon, May 20, 2019 at 11:53:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Remove a reference to git-cvsimport in the intro. As can be seen from
> the history of this command[1] it was originally intended for use with
> git-cvsimport, but how it uses it (and that it uses it at all) is
> irrelevant
Since 7171d8c15f (upload-pack: send symbolic ref information as
capability, 2013-09-17), we've sent cloning and fetching clients special
information about which branch HEAD is pointing to, so that they don't
have to guess based on matching up commit ids.
However, this feature has never worked prop
On Tue, May 21, 2019 at 05:34:02PM -0700, Emily Shaffer wrote:
> I think Peff and Jonathan are right. If someone does want to hack away
> on something in the very early stages, the BUG() line gives a pretty
> clear indicator of what to modify to make it work.
>
> I also moved the BUG() to grep_so
If a user wishes to have a per-branch output directory for patches, they
must manually specify this on the command-line with `-o` for each
invocation of format-patch. However, this can be cumbersome for a user
to keep track of.
Read `format..outputDirectory` to give a branch-specific
output direct
In Git's tests, there is typically no space between the redirection
operator and the filename. Remove these spaces.
Since output is silenced when running without `-v` and debugging
output is useful with `-v`, remove redirections to /dev/null.
Change here-docs from `<<\EOF` to `<<-\EOF` so that th
In git-format-patch.txt, we were missing some key user information.
First of all, using the `--to` and `--cc` options don't override
`format.to` and `format.cc` variables, respectively. They add on to each
other. Document this.
In addition, document the special value of `--base=auto`.
Next, while
If a user wishes to keep track of whom to Cc: on individual patchsets,
they must manually keep track of each recipient and fill it in with the
`--cc` option on git-format-patch each time. However, on the Git mailing
list, Cc:'s are typically never dropped. As a result, it would be nice
to have a me
In a future patch, we need to create the output_directory after the
branch_name logic. Simply transpose this logic later in the function so
that this happens. (This patch is best viewed with `git diff
--color-moved`.)
Note that this logic only depends on `git_config` and the parseopt logic
and is
We used to populate the subject of the cover letter generated by
git-format-patch with "*** SUBJECT HERE ***". However, if a user submits
multiple patchsets, they may want to keep a consistent subject between
rerolls.
If git-format-patch is run with `--infer-cover-letter` or
`format.inferCoverSubj
In a future patch, we need to perform the addition of To: and Cc:
to extra_headers after the branch_name logic. Simply transpose this
logic later in the function so that this happens. (This patch is best
viewed with `git diff --color-moved`.)
Note that this logic only depends on `git_config` and
`
In a future patch, we'll need to take one string_list and append it to
the end of another. Create the `string_list_append_all` function which
does this.
Signed-off-by: Denton Liu
---
string-list.c | 9 +
string-list.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/string-li
Hi Junio,
I've gotten rid of all the `format.*.coverSubject` stuff and replaced it
with a generic `format.inferCoverSubject` that will read the subject
from the branch description. I've also made `git branch -d` stop
deleting the `format..*` variables.
A new addition in this patchset is that form
On Tue, May 21, 2019 at 09:59:53AM -0400, Derrick Stolee wrote:
> When updating the topo-order walk in b454241 (revision.c: generation-based
> topo-order algorithm, 2018-11-01), the logic was a huge rewrite of the
> walk logic. In that massive change, we accidentally included the
> UNINTERESTING co
Emily Shaffer wrote:
> Subject: grep: provide sane default to grep_source struct
This subject line doesn't describe what the patch does any more. How
about something like
grep: fail early if call could print output and name is not set
?
> grep_buffer creates a struct grep_source gs an
On 2019-05-21 at 21:47:54, Randall S. Becker wrote:
> When running the test in isolation, it passes without incident whether or
> not --verbose is used. So far, this only occurs on the first run through. I
> wanted to report it, based on the inconsistency of results. This is not the
> first time te
On 22/05/2019 01:11, Duy Nguyen wrote:
> On Wed, May 22, 2019 at 2:56 AM Ramsay Jones
> wrote:
>>
>> Hi Duy,
>>
>> I am in the middle of rebasing a long running branch onto
>> current master (v2.22.0-rc1) and noticed something odd with
>> commit af2f368091 ("diff-parseopt: convert --output-*",
grep_buffer creates a struct grep_source gs and calls grep_source()
with it. However, gs.name is null, which eventually produces a
segmentation fault in grep_source()->grep_source_1()->show_line()
when grep_opt.status_only is not set.
This seems to be unreachable from existing commands but is reac
The "invalid filter-spec" message is user-facing and not a BUG, so make
it localizeable.
Signed-off-by: Matthew DeVore
---
list-objects-filter-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
index c0036f7
The next patch will create and manage filters in a new way, which means
that this bundle of data will have to be managed at a new callsite. Make
this bundle of data more manageable by putting it in a struct and
making it part of the list-objects-filter module's API.
Signed-off-by: Matthew DeVore
Move the check that filter_options->choice is set to higher in the call
stack. This can only be set when the gentle parse function is called
from one of the two call sites.
This is important because in an upcoming patch this may or may not be an
error, and whether it is an error is only known to t
Allow combining filters such that only objects accepted by all filters
are shown. The motivation for this is to allow getting directory
listings without also fetching blobs. This can be done by combining
blob:none with tree:. There are massive repositories that have
larger-than-expected trees - eve
Allow combining of multiple filters by simply repeating the --filter
flag. Before this patch, the user had to combine them in a single flag
somewhat awkwardly (e.g. --filter=combine:FOO+BAR), including
URL-encoding the individual filters.
To make this work, in the --filter flag parsing callback, r
This implements combining of filters. In any command which accepts the --filter
flag, this patch allows specifying multiple filter flags or using the
"combine:..." filter-spec form.
Combining filters means that only objects which are accepted by all filters get
shown or included.
Compared to the
Hi,
Emily Shaffer wrote:
> On Thu, May 16, 2019 at 06:02:54PM -0400, Jeff King wrote:
>> On Thu, May 16, 2019 at 02:44:44PM -0700, Emily Shaffer wrote:
>>> + /* TODO: In the future it may become desirable to pass in the name as
>>> +* an argument to grep_buffer(). At that time, "(in core)"
On Wed, May 22, 2019 at 2:56 AM Ramsay Jones
wrote:
>
> Hi Duy,
>
> I am in the middle of rebasing a long running branch onto
> current master (v2.22.0-rc1) and noticed something odd with
> commit af2f368091 ("diff-parseopt: convert --output-*",
> 2019-02-21).
>
> As part of the branch I am rebasi
On Thu, May 16, 2019 at 06:02:54PM -0400, Jeff King wrote:
> On Thu, May 16, 2019 at 02:44:44PM -0700, Emily Shaffer wrote:
>
> > grep_buffer creates a struct grep_source gs and calls grep_source()
> > with it. However, gs.name is null, which eventually produces a
> > segmentation fault in
> > gre
When unshelving a changelist, git-p4 tries to work out the appropriate
parent commit in a given branch (default: HEAD). To do this, it looks
at the state of any pre-existing files in the target Perforce branch,
omiting files added in the shelved changelist. Currently, only files
added (or move ta
Hi Junio,
On Sun, 19 May 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 15 May 2019, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> I was imagining what would happen if we treat _everything_ in the two
> >> directories being compared by "difftool -
Another situation came up during regression testing on NonStop:
t5401 broke on the first run through (most tests), with the failures below.
*** t5401-update-hooks.sh ***
not ok 1 - setup
#
# echo This is a test. >a &&
# git update-index --add a &&
# tree
On Mon, May 20, 2019 at 07:59:03PM -0700, Bryan Turner wrote:
> When using GIT_NAMESPACE, it appears the "symref" added to the
> capabilities advertisement doesn't get the namespace stripped. The
> namespace is stripped for the advertised refs, including "HEAD", but
> not on the "symref".
>
> Laf
On Mon, May 20, 2019 at 07:04:14PM -0400, Nicolas Pitre wrote:
> > That still has some value even if your commit ends up with a question
> > mark. There's not much to dig out of 636171cb80 (make index-pack able
> > to complete thin packs., 2006-10-25). Adding Nico, maybe he still
> > remembers...
On Tue, May 21, 2019 at 12:33:58PM -0700, Jeff Hostetler via GitGitGadget wrote:
> As Duy suggested, pthread_getspecific() just returns NULL when NO_PTHREADS
> is defined. And pthread_setspecific() silently does not nothing. So this
> problem was hidden from view.
>
> I have to wonder if we shoul
In builtin/clone.c, the handling of "--recursive" as an alias for
"--recurse-submodules" changed between
v2.22.0-rc0 and v2.22.0-rc1. This report refers to the way it's
documented in the newest version
and suggests some improvements.
The short help (git clone -h) says:
--recursive[=]
On 5/21/2019 10:34 AM, Nathan and Ila Reynolds wrote:
I am not sure if this is the right mailing list. If not, please
redirect me to the right place.
I have Cygwin's git (2.21.0) and Git for Windows (2.21.0) installed on
my Windows 10 machine. I run the following command with each binary
On Tue, May 21, 2019 at 05:34:02PM +0700, Duy Nguyen wrote:
> > 2. There are hundreds of spots that need to swap out "repo->index" for
> > "&repo->index". In the patch below I just did enough to compile
> > archive-zip.o, to illustrate. :)
>
> You are more thorough than me. I saw #2 f
On 5/21/2019 10:19 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, May 20 2019, Jeff Hostetler wrote:
On 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, May 10 2019, Jeff King wrote:
On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
As noted in TODOs in the
Am 21.05.19 um 12:58 schrieb marcandre.lur...@redhat.com:
> From: Marc-André Lureau
>
> This adds xfuncname and word_regex patterns for Rust, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The word_regex patter
Hi Duy,
I am in the middle of rebasing a long running branch onto
current master (v2.22.0-rc1) and noticed something odd with
commit af2f368091 ("diff-parseopt: convert --output-*",
2019-02-21).
As part of the branch I am rebasing, I have defined a new
OPT_LL_CALLBACK() macro[1], which I had inte
This commit addresses the problem reported in:
https://public-inbox.org/git/92cfdf43-8841-9c5a-7838-dda995038...@jeffhostetler.com/T/#mbaf8069f6d1bc18d5a02d3682a1f9282f5547ea9
As Duy suggested, pthread_getspecific() just returns NULL when NO_PTHREADS
is defined. And pthread_setspecific() silently
From: Jeff Hostetler
Teach trace2 TLS code to not rely on pthread_getspecific() when NO_PTHREADS
is defined. Instead, always assume the context data of the main thread.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tls.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Hi Junio,
On Sun, 19 May 2019, Junio C Hamano wrote:
> The first release candidate Git 2.22-rc1 has been tagged. There
> still are a few topics from 'next' that need to go to 'master'
> before the final, but otherwise this should be pretty close to the
> final version. Knock knock...
Fingers c
On Tue, May 21, 2019 at 09:06:18AM -0700, Elijah Newren wrote:
> On Mon, May 20, 2019 at 6:01 PM Emily Shaffer wrote:
> >
> > We check for a handy environment variable GIT_DEBUGGER when running via
> > bin-wrappers/, but this feature is undocumented. Add a hint to how to
> > use it into the Coding
From: Johannes Schindelin
In 06f5608c14e6 (bisect--helper: `bisect_start` shell function partially
in C, 2019-01-02), we introduced a call to `get_oid()` and did not check
whether it succeeded before using its output.
Signed-off-by: Johannes Schindelin
---
builtin/bisect--helper.c | 5 -
1
From: Johannes Schindelin
In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat`
options, 2018-09-04), we added a line that wanted to remove the
`REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation.
Found by Coverity.
Signed-off-by: Johannes Schindelin
---
bu
I looked very briefly over the issues pointed out by Coverity, and decided
to pluck these two low-hanging pieces of fruit.
Johannes Schindelin (2):
rebase: replace incorrect logical negation by correct bitwise one
bisect--helper: verify HEAD could be parsed before continuing
builtin/bisect--
On 5/21/2019 9:07 AM, Randall S. Becker wrote:
On May 21, 2019 07:59, Duy Nguyen wrote:
On Tue, May 21, 2019 at 6:51 PM Ævar Arnfjörð Bjarmason
wrote:
But the real bug looks like the trace2 code unconditionally depending
on pthreads, even though NonStop has 'NO_PTHREADS =
UnfortunatelyYes'
On Mon, May 20, 2019 at 6:01 PM Emily Shaffer wrote:
>
> We check for a handy environment variable GIT_DEBUGGER when running via
> bin-wrappers/, but this feature is undocumented. Add a hint to how to
> use it into the CodingGuidelines (which is where other useful
> environment settings like DEVEL
Octave pattern is almost the same as matlab, except
that '%%%' and '##' can also be used to begin code sections,
in addition to '%%' that is understood by both. Octave
pattern is merged into Matlab pattern. Test cases for
the hunk header patterns of matlab and octave under
t/t4018 are added.
Signe
On Tue, 21 May 2019 at 15:34, Nathan and Ila Reynolds wrote:
>
> I am not sure if this is the right mailing list. If not, please
> redirect me to the right place.
>
> I have Cygwin's git (2.21.0) and Git for Windows (2.21.0) installed on
> my Windows 10 machine. I run the following command with e
I am not sure if this is the right mailing list. If not, please
redirect me to the right place.
I have Cygwin's git (2.21.0) and Git for Windows (2.21.0) installed on
my Windows 10 machine. I run the following command with each binary
"git push --all" on a simple 2 line change to 1 file. If
On Mon, May 20 2019, Jeff Hostetler wrote:
> On 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, May 10 2019, Jeff King wrote:
>>
>>> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>>
As noted in TODOs in the script there's various stuff I'd like to
When updating the topo-order walk in b454241 (revision.c: generation-based
topo-order algorithm, 2018-11-01), the logic was a huge rewrite of the
walk logic. In that massive change, we accidentally included the
UNINTERESTING commits in expand_topo_walk(). This means that a simple
query like
gi
If a commit-graph exists with computed generation numbers, then a
'git rev-list --topo-order -n ' query will use those generation
numbers to reduce the number of commits walked before writing N commits.
One caveat put in b454241 (revision.c: generation-based topo-order
algorithm, 2018-11-01) was
On May 21, 2019 07:59, Duy Nguyen wrote:
> On Tue, May 21, 2019 at 6:51 PM Ævar Arnfjörð Bjarmason
> wrote:
> > But the real bug looks like the trace2 code unconditionally depending
> > on pthreads, even though NonStop has 'NO_PTHREADS =
> UnfortunatelyYes'
> > defined.
> >
> > That's why we get t
On Tue, May 21, 2019 at 6:51 PM Ævar Arnfjörð Bjarmason
wrote:
> But the real bug looks like the trace2 code unconditionally depending on
> pthreads, even though NonStop has 'NO_PTHREADS = UnfortunatelyYes'
> defined.
>
> That's why we get this th%d:unknown stuff, the trace2/tr2_tls.c code
> using
On Tue, May 21 2019, Randall S. Becker wrote:
> Hi All,
>
> On the NonStop platform, the entire test for t0211-trace2-perf.sh does not
> work. The first case, in verbose, reports:
>
> We get errors when the script is run:
>
> Use of uninitialized value within @tokens in pattern match (m//) at
>
On Tue, May 21, 2019 at 6:24 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Tue, May 21 2019, Duy Nguyen wrote:
>
> > (dropping lkml and git-packagers)
> >
> > On Tue, May 21, 2019 at 3:31 PM Duy Nguyen wrote:
> >> > The bug there is that the old opt_arg() code would be torelant to empty
> >> > value
On Tue, May 21 2019, Duy Nguyen wrote:
> (dropping lkml and git-packagers)
>
> On Tue, May 21, 2019 at 3:31 PM Duy Nguyen wrote:
>> > The bug there is that the old opt_arg() code would be torelant to empty
>> > values. I noticed a similar change the other day with the --abbrev
>> > option, but
Hi All,
On the NonStop platform, the entire test for t0211-trace2-perf.sh does not
work. The first case, in verbose, reports:
We get errors when the script is run:
Use of uninitialized value within @tokens in pattern match (m//) at
t0211/scrub_perf.perl line 29, <> line 1.
Initialized empty Git
Hi
On Mon, May 20, 2019 at 9:52 PM Johannes Sixt wrote:
>
> Am 20.05.19 um 19:04 schrieb marcandre.lur...@redhat.com:
> > From: Marc-André Lureau
> >
> > This adds xfuncname and word_regex patterns for Rust, a quite
> > popular programming language. It also includes test cases for the
> > xfuncn
From: Marc-André Lureau
This adds xfuncname and word_regex patterns for Rust, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.
The word_regex pattern finds identifiers, integers, floats and
operators, according to the Ru
On Mon, May 20, 2019 at 8:17 PM Jeff King wrote:
> The patch looks good, though I wonder if we could simplify even further
> by just embedding an index into the repository object. The purpose of
> having it as a pointer, I think, is so that the_repository can point to
> the_index. But we could pos
(dropping lkml and git-packagers)
On Tue, May 21, 2019 at 3:31 PM Duy Nguyen wrote:
> > The bug there is that the old opt_arg() code would be torelant to empty
> > values. I noticed a similar change the other day with the --abbrev
> > option, but didn't think it was worth noting. Maybe it's a mor
On Tue, May 21, 2019 at 5:27 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, May 20 2019, Bryan Turner wrote:
>
> > On Sun, May 19, 2019 at 10:00 AM Junio C Hamano wrote:
> >>
> >> * The diff machinery, one of the oldest parts of the system, which
> >>long predates the parse-options API, use
On Mon, May 20, 2019 at 3:54 PM Jakub Narebski wrote:
> There is also reposurgeon tool; though its main purported purpose is to
> aid migrating from one version control system to another, it can also be
> used to edit repositories (utilizing fast-import stream).
>
> https://gitlab.com/esr/reposu
71 matches
Mail list logo
