rev-parse --is-bare-repository incorrectly outputs "false" when testing
a bare repository with the work tree set.
To reproduce:
$ git init --bare testbare
$ git --git-dir=testbare rev-parse --is-bare-repository
true
$ git --git-dir=testbare --work-tree=something rev-parse \
--is-bare-repository
I know name-scrubbing is already covered in filter-branch and other
places. But we have a scenario becoming more common that makes it a
more sensitive topic.
At $work we have a long time employee who has changed their name from
Alice to Bob. Bob doesn't want anyone to call him "Alice" anymore and
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
Make the filter_spec string a string_list rather than a raw C string.
The list of strings must be concatted together to make a complete
filter_spec. A future patch will use this capability to build "combine:"
filter specs gradually.
A strbuf would seem to be a more natural choice for this object,
Allow callers to specify exactly what characters need to be URL-encoded
and which do not. This new API will be taken advantage of in a patch
later in this set.
Helped-by: Jeff King
Signed-off-by: Matthew DeVore
---
credential-store.c | 9 +
http.c | 6 --
strbuf.c
This function always returns 0, so make it return void instead.
Signed-off-by: Matthew DeVore
---
list-objects-filter-options.c | 12 +---
list-objects-filter-options.h | 2 +-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/list-objects-filter-options.c b/list-objects-fi
I had to rebase this onto the latest master rev. master now has the patch which
disables the sparse:path filter, and v3 of this patch set has conflicts with it.
This version does not so it can be patched in and tried out by others.
I have re-run the test suite on each commit. Sorry for the spammin
Introduce a new macro ALLOC_GROW_BY which automatically zeros the added
array elements and takes care of updating the nr value. Use the macro in
code introduced earlier in this patchset.
Signed-off-by: Matthew DeVore
---
cache.h | 22 ++
list-objects-fil
Make the list-objects-filter.h API more opaque and easier to use. This
prepares for combined filter support, where filters will be created and
used in a new context.
Helped-by: Jeff Hostetler
Helped-by: Junio C Hamano
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 111 ++
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
The oidset *omits pointer must be accessed by the combine filter in a
type-agnostic way once the graph traversal is over. Store that pointer
in the general `filter` struct. This will be used in a follow-up patch
to implement the combine filter.
Signed-off-by: Matthew DeVore
---
list-objects-filt
Making errbuf an optional argument complicates error reporting. Fix this
by making all callers supply an errbuf, even if they may ignore it. This
will be important in follow-up patches where the filter-spec parsing has
more pitfalls and possible errors.
Signed-off-by: Matthew DeVore
---
list-obj
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
On Fri, Jun 14, 2019 at 12:29 AM Vincent Legoll
wrote:
> On Fri, Jun 14, 2019 at 12:56 AM Elijah Newren wrote:
> > When you cherry-pick a commit, it reapplies its diff on top of a
> > (usually different) commit, preserving the author name/email/date, but
> > throwing away the committer name/email
Allow easier parsing by cat-file by giving rev-list an option to print
only the OID of a non-commit object without any additional information.
This is a short-term shim; later on, rev-list should be taught how to
print the types of objects it finds in a format similar to cat-file's.
Before this co
On Fri, Jun 14, 2019 at 12:07:28PM -0400, Jeff King wrote:
> On Thu, Jun 13, 2019 at 02:51:03PM -0700, Emily Shaffer wrote:
> > +test_expect_success 'rev-list --objects --oid-only is usable by cat-file' '
> > + git rev-list --objects --oid-only --all >list-output &&
> > + git cat-file --batch-
On Sat, Jun 15 2019, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 13 2019, Johannes Schindelin via GitGitGadget wrote:
>
>> The kwset functionality makes use of the obstack code, which expects to
>> be handed a function that can allocate large chunks of data. It expects
>> that function to accep
On Fri, Jun 14, 2019 at 01:25:59PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But I wonder if things would be simpler if we did not touch the commit
> > code path at all. I.e., if this were simply "--no-object-names", and it
> > touched only show_object().
>
> Yeah, that sounds more
On Fri, Jun 14, 2019 at 05:27:14PM -0400, Jeff King wrote:
> On Fri, Jun 14, 2019 at 01:59:50PM -0700, Emily Shaffer wrote:
>
> > > So no, I cannot see a way in which "rev-list --abbrev" is useful without
> > > "--abbrev-commit". Which means that perhaps the former should imply the
> > > latter.
>
On Thu, Jun 13 2019, Johannes Schindelin via GitGitGadget wrote:
> The kwset functionality makes use of the obstack code, which expects to
> be handed a function that can allocate large chunks of data. It expects
> that function to accept a `size` parameter of type `long`.
>
> This upsets GCC 8
On Thu, Jun 13 2019, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> The kwset functionality makes use of the obstack code, which expects to
> be handed a function that can allocate large chunks of data. It expects
> that function to accept a `size` parameter of type
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
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 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
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 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 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
Hi all,
Although 'config: learn the "onbranch:" includeIf condition'[1] seems to be
on track for "next", the content in this patchset is not entirely
superseded by it.
Patches 1 and 2 should be relatively uncontroversial since they just do
a bit of cleanup.
Patch 3 is a new feature that isn't in
On Fri, Jun 14, 2019 at 01:59:50PM -0700, Emily Shaffer wrote:
> > So no, I cannot see a way in which "rev-list --abbrev" is useful without
> > "--abbrev-commit". Which means that perhaps the former should imply the
> > latter.
>
> Maybe it should; maybe this patch is a good excuse to do so, and
On 14/06/2019 21:30, Ramsay Jones wrote:
>
>
> On 14/06/2019 11:00, SZEDER Gábor wrote:
>> Update 'compat/obstack.{c,h}' from upstream, because they already use
>> 'size_t' instead of 'long' in places that might eventually end up as
>> an argument to malloc(), which might solve build errors wi
Hi Junio,
On 10/06/2019 18:57, Junio C Hamano wrote:
Philip Oakley writes:
The availability of these pattern selections is not obvious from
the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
Provide examples.
Re-order the `git branch` synopsis to emphasise the `--list `
On Fri, Jun 14, 2019 at 12:18:41PM -0400, Jeff King wrote:
> On Thu, Jun 13, 2019 at 03:15:41PM -0700, Emily Shaffer wrote:
>
> > I thought this was odd when I was working on the other rev-list changes
> > - --abbrev doesn't do anything on its own. It looks like it does work by
> > itself in other
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The first batch of topics post 2.2
On 14/06/2019 11:00, SZEDER Gábor wrote:
> Update 'compat/obstack.{c,h}' from upstream, because they already use
> 'size_t' instead of 'long' in places that might eventually end up as
> an argument to malloc(), which might solve build errors with GCC 8 on
> Windows.
>
> The first patch just imp
Jeff King writes:
> But I wonder if things would be simpler if we did not touch the commit
> code path at all. I.e., if this were simply "--no-object-names", and it
> touched only show_object().
Yeah, that sounds more tempting. And the refined code structure you
suggested ...
>> @@ -255,6 +262
Matthew DeVore writes:
> It has been a while since a sent a roll-up. Here are the changes since v2:
>
> - Re-use more URL-encoding logic in strbuf.c
>* This was partially achieved by changing the helper function to accept a
> function that will indicate whether some character must be es
Hi Gábor,
On Thu, 13 Jun 2019, SZEDER Gábor wrote:
> On Thu, Jun 13, 2019 at 06:51:04PM +0200, Johannes Schindelin wrote:
>
> > On Thu, 13 Jun 2019, Junio C Hamano wrote:
> >
> > > SZEDER Gábor writes:
> > >
> > > > On Thu, Jun 13, 2019 at 05:53:51AM -0700, Johannes Schindelin via
> > > > GitGit
Hey Everyone!
I sent my first patch[1] to the mailing list this week and received
very nice feedback. The blog about my week is hosted here[2]. Hope
you'll find it interesting.
Thanks
Rohit
[1]:
https://public-inbox.org/git/20190608191958.4593-1-rohit.ashiwal...@gmail.com/
[2]: https://rashiwal
Hi,
On Wed, 12 Jun 2019, SZEDER Gábor wrote:
> On Wed, Jun 12, 2019 at 09:14:40PM +0200, Johannes Schindelin wrote:
>
> > On Tue, 11 Jun 2019, SZEDER Gábor wrote:
> >
> > > On Tue, Jun 11, 2019 at 01:36:16PM -0700, Junio C Hamano wrote:
> > > > SZEDER Gábor writes:
> > > >
> > > > > -Rebasing (1
We have a hard limit in the service of 5GB for a single push.
The advice we've given other customers is to do partial pushes by checking out
an older commit, pushing that, and then checking out a newer commit, pushing,
etc. You have to push multiple times, but you can build up the entire histor
SZEDER Gábor writes:
> And here is an all-green build of these patches on Travis CI:
>
> https://travis-ci.org/szeder/git/builds/545645247
>
> (and one bonus patch on top to deal with some Homebrew nonsense)
Is this the one that making all of the jobs pass in the above
output, including the ma
On Fri, Jun 14, 2019 at 12:00:55PM +0200, SZEDER Gábor wrote:
> Update 'compat/obstack.{c,h}' from upstream, because they already use
> 'size_t' instead of 'long' in places that might eventually end up as
> an argument to malloc(), which might solve build errors with GCC 8 on
> Windows.
>
> The f
To @Git Community
>From the perspective of an Azure DevOps support engineer. I have a customer
>who is unable to make a push with following error:
fatal: The remote end hung up unexpectedly
failed to push some refs into
https://zelos.healthcare.siemens.com/tfs/Hoover/VA20A.DevInt.Gvfs/_git/Satur
On Thu, Jun 13, 2019 at 03:15:41PM -0700, Emily Shaffer wrote:
> I thought this was odd when I was working on the other rev-list changes
> - --abbrev doesn't do anything on its own. It looks like it does work by
> itself in other commands, but apparently not in rev-list.
>
> Listed this patch as
SZEDER Gábor writes:
>> Now, the proper thing to do would be to switch to `size_t`. But this
>> would make us deviate from the "upstream" code even further,
>
> This is not entirely true: upstream already uses 'size_t', so the
> switch would actually bring our copy closer to upstream.
Ah, earlie
Emily Shaffer writes:
> It looks like `git log --abbrev=5` also doesn't work the way one might
> expect, which makes sense to me, as they use the same internals for
> option parsing (parse_revisions()).
I suspect that was primarily because --abbrev-commit was only to
abbreviate the commit object
On Thu, Jun 13, 2019 at 02:51:03PM -0700, Emily Shaffer wrote:
> It didn't appear that using an existing --pretty string would do the
> trick, as the formatting options for --pretty apply specifically to
> commit objects (you can specify the commit hash and the tree hash, but
> I didn't see a way
On 6/11/2019 7:31 PM, Josh Steadmon wrote:
Define a JSON schema[1] that can be used to validate trace2 event
objects. This can be used to add regression tests to verify that the
event output format does not change unexpectedly.
Two versions of the schema are provided:
* event_schema.json is m
Rohit Ashiwal writes:
>> Is this correct, or do we need to enclose these choices inside (),
>> i.e.
>>
>> 'git cherry-pick' ( --continue | --skip | --abort | --quit )
>>
>> ?
>
> Documentation of `git rebase` also lists these options without the
> '('s so, I thought to make it similar to t
On 6/11/2019 7:31 PM, Josh Steadmon wrote:
Correct the api-trace2 documentation, which lists "signal" as an
expected field for the signal event type, but which actually outputs
"signo" as the field name.
Signed-off-by: Josh Steadmon
---
Documentation/technical/api-trace2.txt | 2 +-
1 fil
On Fri, Jun 14, 2019 at 11:27:10AM -0400, Jeff King wrote:
> So in short, it was never supposed to work, but between bugs and
> protocol vagaries, there are a few version and protocol combinations
> where it did.
I'd add that in protocol v2, the reachability restrictions are lifted
(i.e., every s
On Fri, Jun 14, 2019 at 01:54:15PM +0300, Karen Arutyunov wrote:
> git 2.22, in contrast to previous versions, fails to fetch advertised commit
> using commit id:
>
> Is it a bug or advertised object semantics change?
This is working as designed, but the behavior is a rather tricky
historical cas
On Fri, Jun 14, 2019 at 08:35:04PM +0900, Masahiro Yamada wrote:
> Perhaps, 'git interpret-trailers' should be changed
> to recognize core.commentChar ?
It looks like the trailer code does respect it, but the
interpret-trailers program never loads the config. Does the patch below
make your proble
ÓO=ó4ïÝøÓO5Ó_yçßvÔ*'µéíO*^µìmþZw!j»
From: Johannes Schindelin
This one slipped through the review of a9279c678588 (sequencer: do not
squash 'reword' commits when we hit conflicts, 2018-06-19).
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Just a typo I found while debugging something else.
Johannes Schindelin (1):
t3404: fix a typo
t/t3404-rebase-interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 0aae918dd929862d3ce0ea2960897787bb269a3b
Published-As:
https://github.com/gitgitgadget/git/releases
Currently, git submodule does not display operation progress unless
explicitly demanded by adding the --progress option to the command.
This makes a bad user experience in cases of initializing a huge
submodule, as one might get an impression that something went
wrong and the execution froze (which
Hi.
When I tried to add ChangeId tag for Gerrit Code Review,
I noticed 'git interpret-trailers' went wrong
if a comment character other than '#' is used.
Quick Test Code
---
cat <
; This is a comment line with non-default char
EOF
[result]
subject: this is commit subject
Blah B
Hello,
git 2.22, in contrast to previous versions, fails to fetch advertised
commit using commit id:
$ git --version
git version 2.22.0
$ git init git
$ git -C git remote add origin https://github.com/git/git
$ git ls-remote https://github.com/git/git | grep v2.21
2bb64867dc05d9a8432488ddc1d
On Fri, Jun 14, 2019 at 12:22 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> >> > I know there are testing philosophies that go to this level of
> >> > white-box testing, but I don't think we usually do in Git. A unit
> >> > test of oidmap's externally visible behavior seems like the right
>
Here is today's test coverage report.
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-14.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-14.txt
---
pu d3545145f9e3f092c0031535c51c6c88e4646c44
jch c7b1a102ca91f3fc04951c551da7a92f91
Compiling 'compat/obstack.c' with Clang on Linux and macOS fails with
different errors:
On Linux:
CC compat/obstack.o
compat/obstack.c:330:31: error: incompatible pointer types initializing
'void (*)(void) __attribute__((noreturn))' with an expression of type
'void (void)'
'compat/obstack.c' occasionally assigns/compares a plain 0 to a
pointer, which triggers sparse warnings. Use NULL instead.
This is basically a cherry-pick of 3254310863 (obstack.c: Fix some
sparse warnings, 2011-09-11) on top of the just updated code from
upstream.
Signed-off-by: SZEDER Gábor
-
!! This does not compile !!
Update 'compat/obstack.{c,h}' from commit
5905d8ca9945f0d60ff40eb6cfa42afc0199ab8f in
https://git.savannah.gnu.org/git/gnulib.git
We have made a couple of changes to our copy of 'compat/obstack.{c,h}'
since it was introduced in e831171d67 (Add obstack.[ch] from EGLIBC
This is sort-of a cherry-pick of d190a0875f (obstack: Fix portability
issues, 2011-08-28), which is necessary to make 'compat/obstack.c'
compile again. Only "sort-of a cherry-pick", because the divergence
between upstream and our copy was just too bit and I gave up on the
conflict resolution, and
Update 'compat/obstack.{c,h}' from upstream, because they already use
'size_t' instead of 'long' in places that might eventually end up as
an argument to malloc(), which might solve build errors with GCC 8 on
Windows.
The first patch just imports from upstream and doesn't modify anything
at all, a
> Subject: Re: [PATCH 2/4] kwset: allow building with GCC 8
The subject could benefit from a "on Windows" at the end; 'kwset' and
compat/obstack can be build with GCC 8 and 9 just fine on some other
platforms.
On Thu, Jun 13, 2019 at 04:49:45AM -0700, Johannes Schindelin via GitGitGadget
wrote:
Hi,
`git stash ` where n is a number used to work until 2.21.*.
It doesn't work in 2.22.0.
Bisection points to:
dc7bd382b1063303f4f45d243bff371899285acb is the first bad commit
commit dc7bd382b1063303f4f45d243bff371899285acb
Author: Paul-Sebastian Ungureanu
Date: Mon Feb 25 23:16:20 2019 +00
Hello,
On Fri, Jun 14, 2019 at 12:56 AM Elijah Newren wrote:
>
> On Thu, Jun 13, 2019 at 3:42 PM Vincent Legoll
> wrote:
> >
> > What am I missing ?
>
> When you cherry-pick a commit, it reapplies its diff on top of a
> (usually different) commit, preserving the author name/email/date, but
> th
71 matches
Mail list logo
