Hi Warren
On 08/09/2019 00:44, Warren He wrote:
Everyone in this thread, thanks for your support and encouragement.
[...]
It should not really imply `--interactive`, but `--rebase-merges`.
`imply_interactive` doesn't fully switch on `--interactive`, i.e., causing the
editor to open. It only s
On Sun, Sep 08, 2019 at 10:01:33PM -0600, Eric Freese wrote:
> On Sun, Sep 9, 2019 at 4:34 PM Junio C Hamano wrote:
>
> > I guess with "%(if)...%(then)...%(else)...%(end)" you might be able
> > to do either one of --include/--exclude without supporting the
> > other, e.g. "--include='%(if)%(symr
On 9/5/2019 2:57 PM, Junio C Hamano wrote:
Jeff King writes:
So these patches are punting on the greater question of why we want to
parse so early, and are not making anything worse. AFAICT, "clone
--filter=sparse:oid" has never worked (even though our tests did cover
the underlying rev-lis
[adding git list]
On 9/5/19 7:25 AM, Christian Schoenebeck wrote:
> How are you sending patches ? With git send-email ? If so, maybe you
> can
> pass something like --from='"Christian Schoenebeck"
> '. Since this is a different string, git will
> assume you're sending someone
Hi,
On Mon, 9 Sep 2019, Phillip Wood wrote:
> On 08/09/2019 00:44, Warren He wrote:
> > Everyone in this thread, thanks for your support and encouragement.
> > [...]
> > > It should not really imply `--interactive`, but `--rebase-merges`.
> >
> > `imply_interactive` doesn't fully switch on `--int
On Mon, Sep 09, 2019 at 09:05:45AM -0500, Eric Blake wrote:
> > But as you can already read from the manual, the overall behaviour of git
> > regarding a separate "From:" line in the email body was intended solely for
> > the use case sender != author. So in practice (at least in my git version)
ping
any feedback on code/approach highly appreciated
Carlo
On Wed, Aug 28, 2019 at 9:57 AM Carlo Arenas wrote:
>
> FWIW, the changes in grep.h are IMHO optional and hadn't been really
> tested as I couldn't find a version of PCRE1 old enough to trigger it
> but I am hoping are simple enough to
I think I've just figured out why my workaround works. When ssh sets O_NONBLOCK
on stdout, it's setting it on the write side of the pipe that git created.
Nothing
else writes to that pipe, so this does not cause a problem. Presumably, ssh
itself
is able to deal with writing to a non-blocking "
Jeff King writes:
> On Fri, Sep 06, 2019 at 09:59:04AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > So far so good. But now imagine we call parse_commit_buffer() again, and
>> > we re-parse. How does that interact with the half-parsed state? Some of
>> > it works OK (e.g., lookup
On Mon, Sep 09, 2019 at 09:39:41AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Sep 06, 2019 at 09:59:04AM -0700, Junio C Hamano wrote:
> >
> >> Jeff King writes:
> >>
> >> > So far so good. But now imagine we call parse_commit_buffer() again, and
> >> > we re-parse. How does
On Sun, Sep 08, 2019 at 08:26:10PM +0530, Pratyush Yadav wrote:
> I'd like to put out a proposal regarding first contributions and micro
> projects.
>
> I have a small list of small isolated features and bug fixes that
> _I think_ git-gui would benefit with. And other people using it can
> prob
On Sun, Sep 08, 2019 at 02:18:15PM +, Douglas Graham wrote:
> When I collected that strace output, I had stdout redirected to a pipe to my
> workaround program, but I did not redirect stderr. So ssh made stdout
> non-blocking,
> but since stderr was still connected to my terminal, it didn't
On Mon, Sep 09, 2019 at 09:54:36AM -0400, Jeff Hostetler wrote:
> It would be nice if we could continue to let parse_list_objects_filter()
> do the syntax checking -- that is, we can still check that we received a
> ulong in "blob:limit:" and that "sparse:oid:" looks like a hex
> value, for exampl
Jeff Hostetler writes:
> It would be nice if we could continue to let parse_list_objects_filter()
> do the syntax checking -- that is, we can still check that we received a
> ulong in "blob:limit:" and that "sparse:oid:" looks like a hex
> value, for example. Just save the actual lookup to the
On Sun, Sep 08, 2019 at 06:47:10PM -0700, Stephen P. Smith wrote:
> As part of a previous patch set, the get_time() function was added to
> date.c eliminating the need to pass a `now` parameter from the test
> code.
I'm glad to see this cleanup. I think it is worth explaining a bit more,
though,
On Sun, Sep 08, 2019 at 06:47:11PM -0700, Stephen P. Smith wrote:
> Remove the reference to the GIT_TEST_DATE_NOW which is done in date.c.
> The intialization of variable x with the value from GIT_TEST_DATE_NOW
> is unneeded since x is initalized by skip_prefix().
It took me a minute to understan
"brian m. carlson" writes:
> There are a couple ways around this.
>
> 1. We can force xmlto to use the DocBook 5 stylesheets with the "-x"
> flag, but we have to know where they are. Debian and Fedora have them
> in different places, so we'd need a knob to figure out where they are.
>
> 2. We ca
Jeff King writes:
> Generation numbers are a little trickier, though, because they imply an
> actual topological traversal. It might actually be easier to couple this
> with the connectivity check we do after index-pack finishes (though I've
> often wondered if we could drop that check in favor o
Jeff King writes:
>> Answer. There is a single hit inside fsck.c that wants to report
>> an error without killing ourselves in fsck_commit_buffer(). I
>> however doubt its use of get_commit_tree() is correct in the
>> first place. The function is about validating the commit obje
Rohit Ashiwal writes:
> Following the suggestion of Phillip I've rebased my patch on master
> (745f681289)
> and cherry-picking b0a3186140.
Sorry, but that's horrible. The latter does not even cleanly apply
on the former.
Let me see if I can find time to whip this into a reasonable shape.
Th
Eric Freese writes:
> However, this still prints an empty line for each ref that does not match the
> condition. This can be cleaned up by piping through `grep .`, but what would
> you think of adding a new optional flag to git-for-each-ref to prevent it from
> printing empty expanded format stri
Johannes Schindelin writes:
> In contrast, I would think that
>
> label --update-branch my-side-track
>
> would make for a nicer read than
>
> label my-side-track
> branch my-side-track
Because labelling while recreating a mergey history is conceptually
the same as temporarily
Eric Wong writes:
> Eric Wong wrote:
>> By renaming the "hash" field to "_hash", it's easy to spot
>> improper initialization of hashmap_entry structs which
>> can leave "hashmap_entry.next" uninitialized.
>
> Junio, I'm planning to reroll this series.
> (Sorry for not following up sooner)
>
> W
René Scharfe writes:
> Demonstrate that a decoration filter given with --decorate-refs-exclude
> is inadvertently overruled by --simplify-by-decoration.
>
> Reported-by: Étienne SERVAIS
> Signed-off-by: René Scharfe
> ---
> t/t4202-log.sh | 15 +++
> 1 file changed, 15 insertions(+
"Stephen P. Smith" writes:
> As part of a previous patch submission[1], a cleanup patch was
> suggested to remove a now unnecessary passing of a date environment
> variable to the production code.
It looks like that the idea to realize that get_time() that is aware
of GIT_TEST_DATE_NOW is always
Eric Blake writes:
> How hard would it be to improve 'git format-patch'/'git send-email' to
> have an option to ALWAYS output a From: line in the body, even when the
> sender is the author, for the case of a mailing list that munges the
> mail headers due to DMARC/DKIM reasons?
I'd say that it s
Carlo Arenas writes:
> ping
>
> any feedback on code/approach highly appreciated
I'd prefer to see others weigh in before starting to merge the pcre
stuff to 'next'.
I do not mind taking this updated one that limits the scope to pcre1
as a pure regressino fix, if others agree. Thanks for keepi
On 09/09/2019 19:02, Junio C Hamano wrote:
Rohit Ashiwal writes:
Following the suggestion of Phillip I've rebased my patch on master (745f681289)
and cherry-picking b0a3186140.
Sorry, but that's horrible. The latter does not even cleanly apply
on the former.
Yes I had assumed that the che
Hi Junio,
On Sat, Sep 07, 2019 at 10:26:53AM -0700, Junio C Hamano wrote:
> * dl/complete-cherry-pick-revert-skip (2019-08-27) 3 commits
> - status: mention --skip for revert and cherry-pick
> - completion: add --skip for cherry-pick and revert
> - completion: merge options for cherry-pick and
Hi Denton,
On Wed, 4 Sep 2019, Denton Liu wrote:
> On Wed, Sep 04, 2019 at 11:43:06PM +0200, Johannes Schindelin wrote:
> >
> > On Wed, 4 Sep 2019, Denton Liu wrote:
> >
> > > In 554544276a (*.[ch]: remove extern from function declarations using
> > > spatch, 2019-04-29), we removed externs from
When cherry-picking (for example), new trees may be constructed. During
this process, Git constructs the new tree in a struct strbuf, computes
the OID of the new tree, and checks if the new OID already exists on
disk. However, in a partial clone, the disk check causes a lazy fetch to
occur, which i
Phillip Wood writes:
> Yes I had assumed that the cherry pick would become the first patch of
> this series and be dropped from pw/rebase-i-show-HEAD-to-reword.
Ah, such an arrangement would have made a log more sense, indeed.
> As pw/rebase-i-show-HEAD-to-reword is slated for next perhaps thes
Jeff King writes:
> On Sun, Sep 08, 2019 at 06:47:11PM -0700, Stephen P. Smith wrote:
>
>> Remove the reference to the GIT_TEST_DATE_NOW which is done in date.c.
>> The intialization of variable x with the value from GIT_TEST_DATE_NOW
>> is unneeded since x is initalized by skip_prefix().
>
> It
On 9/9/2019 1:12 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
It would be nice if we could continue to let parse_list_objects_filter()
do the syntax checking -- that is, we can still check that we received a
ulong in "blob:limit:" and that "sparse:oid:" looks like a hex
value, for examp
Jonathan Tan writes:
> When cherry-picking (for example), new trees may be constructed. During
> this process, Git constructs the new tree in a struct strbuf, computes
> the OID of the new tree, and checks if the new OID already exists on
> disk. However, in a partial clone, the disk check causes
Denton Liu writes:
> Hi Junio,
>
> On Sat, Sep 07, 2019 at 10:26:53AM -0700, Junio C Hamano wrote:
>> * dl/complete-cherry-pick-revert-skip (2019-08-27) 3 commits
>> - status: mention --skip for revert and cherry-pick
>> - completion: add --skip for cherry-pick and revert
>> - completion: merg
On 9/9/2019 1:08 PM, Jeff King wrote:
On Mon, Sep 09, 2019 at 09:54:36AM -0400, Jeff Hostetler wrote:
It would be nice if we could continue to let parse_list_objects_filter()
do the syntax checking -- that is, we can still check that we received a
ulong in "blob:limit:" and that "sparse:oid:
Hi Elijah,
On Wed, 4 Sep 2019, Elijah Newren wrote:
> fast-export and fast-import can easily handle the simple rewrite that
> was being done by filter-branch, and should be faster on systems with a
> slow fork. Measuring the overall time taken for all of t3427 (not just
> the difference between
Junio C Hamano writes:
> Isn't that what is going on? I thought I dug up the original that
> introduced the has_object_file() call to this codepath to make sure
> we understand why we make the check (and I expected the person who
> is proposing this change to do the same and record the finding i
Johannes Schindelin writes:
> Hi Elijah,
>
> On Wed, 4 Sep 2019, Elijah Newren wrote:
>
>> fast-export and fast-import can easily handle the simple rewrite that
>> was being done by filter-branch, and should be faster on systems with a
>> slow fork. Measuring the overall time taken for all of t3
Hello,
if the password contains a hash, then it's impossible to clone a
repository, either with https or ssh protocols. I've had to use a
`gitg' GUI to clone such a repo.
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
B
Sebastian Gniazdowski writes:
> Hello,
> if the password contains a hash, then it's impossible to clone a
> repository, either with https or ssh protocols. I've had to use a
> `gitg' GUI to clone such a repo.
Hmph, do you mean that
git clone https://user:passw...@hosting.site/repository
On Mon, Sep 09, 2019 at 03:01:32PM -0700, Junio C Hamano wrote:
> Sebastian Gniazdowski writes:
>
> > Hello,
> > if the password contains a hash, then it's impossible to clone a
> > repository, either with https or ssh protocols. I've had to use a
> > `gitg' GUI to clone such a repo.
>
> Hmph,
On Mon, Sep 09, 2019 at 02:05:53PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Isn't that what is going on? I thought I dug up the original that
> > introduced the has_object_file() call to this codepath to make sure
> > we understand why we make the check (and I expected the pe
Hi,
On Fri, 6 Sep 2019, SZEDER Gábor wrote:
> On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> > To test 'git-p4' in the Linux Clang and GCC build jobs we used to
> > install the 'p4' and 'p4d' binaries by directly downloading those
> > binaries from a Perforce filehost. This has
From: Cameron Steffen
move an incorrectly placed backtick
Signed-off-by: Cameron Steffen
---
Documentation/pretty-formats.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 079598307a..b87e2e83e6 100
Edit: I need permission to submit please
Cameron Steffen (1):
doc: small formatting fix
Documentation/pretty-formats.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 75b2f01a0f642b39b0f29b6218515df9b5eb798e
Published-As:
https://github.com/gitgitgadget/git/releases/tag
On 2019-09-07 at 17:26:53, Junio C Hamano wrote:
> * bc/object-id-part17 (2019-08-19) 26 commits
> - midx: switch to using the_hash_algo
> - builtin/show-index: replace sha1_to_hex
> - rerere: replace sha1_to_hex
> - builtin/receive-pack: replace sha1_to_hex
> - builtin/index-pack: replace sha
On Mon, Sep 09, 2019 at 12:57:17PM -0700, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Hi Junio,
> >
> > On Sat, Sep 07, 2019 at 10:26:53AM -0700, Junio C Hamano wrote:
> >> * dl/complete-cherry-pick-revert-skip (2019-08-27) 3 commits
> >> - status: mention --skip for revert and cherry-pick
"brian m. carlson" writes:
> On 2019-09-07 at 17:26:53, Junio C Hamano wrote:
>> * bc/object-id-part17 (2019-08-19) 26 commits
>> - midx: switch to using the_hash_algo
>> ...
>> - builtin/replace: make hash size independent
>>
>> Preparation for SHA-256 upgrade continues.
>>
>> Looked most
Jeff King writes:
> I wondered also if this means we should be using OBJECT_INFO_QUICK.
> I.e., do we expect to see a "miss" here often, forcing us to re-scan the
> packed directory?
As a performance optimization hack, it is OK if we did not notice
that the tree object, which corresponds to what
Hi Junio,
On Sun, 8 Sep 2019 at 14:51, Junio C Hamano wrote:
>
> * ma/asciidoctor-refmiscinfo (2019-09-03) 2 commits
> - doc-diff: replace --cut-header-footer with --cut-footer
> - asciidoctor-extensions: provide ``
>
> Update support for Asciidoctor documentation toolchain.
>
> Will merge to
Hi,
This is a follow-up patch based on conversation from the thread: "[RFC
PATCH 1/1] for-each-ref: add '--no-symbolic' option"
I had proposed a `--no-symbolic` option to git-for-each-ref that would
filter out symbolic refs from the output. It was discovered that the
behavior was already possible
If the format string expands to an empty string for a given ref, do not
print the empty line.
This is helpful when wanting to print only certain kinds of refs that
you can't already filter for.
For example, to exclude symbolic refs, use format string:
"%(if)%(symref)%(then)%(else)%(refname)%(en
Eric Freese writes:
> If the format string expands to an empty string for a given ref, do not
> print the empty line.
>
> This is helpful when wanting to print only certain kinds of refs that
> you can't already filter for.
We tend to prefer stating the reason why we want to do so first and
then
Junio C Hamano writes:
>> fwrite(final_buf.buf, 1, final_buf.len, stdout);
>> +if (final_buf.len)
>> +putchar('\n');
>
> While we are introducing a conditional, let's drop the useless
> fwrite of 0-byte while we are at it [*1*], i.e.
>
> if (final_buf.len && !omit_empty
From: Dominic Winkler
A literal "{" should now be escaped in a pattern starting from perl
versions >= v5.26. In perl v5.22, using a literal { in a regular
expression was deprecated, and will emit a warning if it isn't escaped: \{.
In v5.26, this won't just warn, it'll cause a syntax error.
(see
A literal "{" should now be escaped in a pattern starting from perl versions
>= v5.26. In perl v5.22, using a literal { in a regular expression was
deprecated, and will emit a warning if it isn't escaped: {. In v5.26, this
won't just warn, it'll cause a syntax error.
(see https://metacpan.org/pod/
58 matches
Mail list logo
