Re: git svn clone/fetch hits issues with gc --auto

Martin Langhoff wrote: > Hi folks, > > Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo > I hit the gc error: > > warning: There are too many unreachable loose objects; run 'git prune' > to remove them. > gc --auto: command returned error: 255 GC can be annoying when that

Re: Thank you for public-inbox!

Jonathan Nieder wrote: > Eric Wong wrote: > > Jonathan Nieder wrote: > >> Jeff King wrote: > > >>> I guess I just wonder if I set up a mirror on another domain, would > >>> anybody actually _use_ it? I'd think most people would just go

Re: Thank you for public-inbox!

Jonathan Nieder wrote: > Jeff King wrote: > > > I guess I just wonder if I set up a mirror on another domain, would > > anybody actually _use_ it? I'd think most people would just go to > > public-inbox.org as the de facto URL. > > If it's faster than public-inbox.org and you don't mind the

Re: Thank you for public-inbox!

Jeff King wrote: > On Wed, Aug 29, 2018 at 10:02:43AM +0000, Eric Wong wrote: > > Anyways I hope to teach public-inbox to auto-linkify Message-ID-looking > > strings "" into URLs for domain-portability, > > (but it's ambiguous with email addresses). But yeah, I d

Re: Thank you for public-inbox!

Jeff King wrote: > I've thought about mirroring it to a public server as well, just for > redundancy. But without the same domain, I'm not sure it would be all > that useful as a community resource. I wouldn't get too attached to the domain, "public-inbox.org" is too long for my tastes anyways.

Re: Thank you for public-inbox!

You're very welcome, Johannes. And I'm hoping to have a few more goodies live this fall/winter for public-inbox :>

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

Jeff King wrote: > On Tue, Aug 14, 2018 at 12:47:59PM -0700, Stefan Beller wrote: > > With the advent of public inbox, this is easy to obtain? > > For our project, yes. But I was thinking of a tool that could be used > for other projects, too. Nothing prevents public-inbox from being adopted by

Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails

Ævar Arnfjörð Bjarmason wrote: > Add a --send-delay option with a corresponding sendemail.smtpSendDelay > configuration variable. When set to e.g. 2, this causes send-email to > sleep 2 seconds before sending the next E-Mail. We'll only sleep > between sends, not before the first send, or after

Re: Is detecting endianness at compile-time unworkable?

Junio C Hamano wrote: > Well, having said all that, I do not think I personally mind if > ./configure learned to include a "compile small program and run it > to determine byte order on the build machine" as part of "we make a > reasonable effort" as long as it cleanly excludes cross building >

Re: [PATCH] git-send-email: allow re-editing of message

Drew DeVault wrote: > When shown the email summary, an opportunity is presented for the user > to edit the email as if they had specified --annotate. This also permits > them to edit it multiple times. Thanks, this seems like a good idea for the cover letter, especially. I prefer

subscription (was: (no subject))

Daniel Villeneuve wrote: > subscribe That line should be "subscribe git" and it needs to be sent to majord...@vger.kernel.org , not this list.

Re: public-inbox.org down?

Oops, some upgrades went awry for the non-Tor HTTPS endpoint termination. The Tor .onions should remain available if that happens http://ou63pmih66umazou.onion/git http://czquwvybam4bgbro.onion/git http://hjrcffqmbrq6wope.onion/git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git

Re: commit -> public-inbox link helper

Johannes Schindelin wrote: > Hi team, > > I found myself in dear need to quickly look up mails in the public-inbox > mail archive corresponding to any given commit in git.git. Some time ago, > I wrote a shell script to help me with that, and I found myself using it a

Re: [PATCH] send-email: avoid duplicate In-Reply-To/References

Stefan Agner wrote: > This addresses the issue reported here: > https://public-inbox.org/git/997160314bbafb3088a401f1c09cc...@agner.ch/ Thanks for bringing this up. > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -1642,10 +1642,15 @@ foreach my $t (@files) { >

Re: [PATCH 5/6] git-svn: commit-diff does not support --add-author-from

Andreas Heiduk <ashei...@gmail.com> wrote: > Signed-off-by: Andreas Heiduk <ashei...@gmail.com> Thanks. Signed-off-by: Eric Wong <e...@80x24.org> And pushed for Junio: The following changes since commit fe0a9eaf31dd0c349ae4308498c33a5c3794b293: Merge branch 'svn/a

Re: Git send-email not sending email patches as subsequent replies

David Davis wrote: > I'm seeing 6 individual emails, how do I just see one email followed by 5 > email replies to the one? I don't want six individual emails. The five email replies you want are still individual emails. Emails are ALWAYS "individual", and reply

Re: Git send-email not sending email patches as subsequent replies

David Davis wrote: > Hello, I have the following git send-email command: > > git send-email -5 --quiet --thread --no-chain-reply-to --compose > --subject='Recent Base Prototype Changes Summary' > --to=davisda...@google.com --from=davisda...@google.com > > It's

Re: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Fri, Apr 06 2018, Eric Wong wrote: > > Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > > >> --- a/perl/Git.pm > >> +++ b/perl/Git.pm > >> @@ -554,7 +554,7 @@ sub get_record { > >

Re: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason wrote: > See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the > original report. Thanks for taking a look at this. Also https://bugs.debian.org/894997 > --- a/perl/Git.pm > +++ b/perl/Git.pm > @@ -554,7 +554,7 @@ sub get_record { >

Re: [PATCH v3] git-svn: allow empty email-address using authors-prog and authors-file

Andreas Heiduk <ashei...@gmail.com> wrote: > Am 05.04.2018 um 09:51 schrieb Eric Wong: > > Can you confirm it's OK for you? Thanks. > > Looks good, works for me. > > Do you squash this patch with with my commit or do you need a reroll? Nope, no need to reroll.

Re: [PATCH v3] git-svn: allow empty email-address using authors-prog and authors-file

Thanks for the update. The patch itself looks good, but I noticed one --show-item isn't supported on SVN 1.8.10 for me. I've tested the following on both SVN 1.8.10 and 1.9.5: --- a/t/t9138-git-svn-authors-prog.sh +++ b/t/t9138-git-svn-authors-prog.sh @@ -83,7 +83,8 @@ test_expect_success

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

Ævar Arnfjörð Bjarmason wrote: > Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH > ') that this series itself arrived out of order (0 -> 2 -> 1), but I > don't know to what extent public-inbox itself might be batching things. public-inbox doesn't batch,

Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file

Andreas Heiduk <ashei...@gmail.com> wrote: > Am 19.03.2018 um 00:04 schrieb Eric Wong: > > Andreas Heiduk <ashei...@gmail.com> wrote: > >> The email address in --authors-file and --authors-prog can be empty but > >> git-svn translated it into a syntethic e

Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file

Andreas Heiduk wrote: > The email address in --authors-file and --authors-prog can be empty but > git-svn translated it into a syntethic email address in the form > $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the email > is explicitly set to the empty string,

Re: [PATCH 2/2] git-svn: allow empty email-address in authors-prog and authors-file

Andreas Heiduk wrote: > 2018-03-05 2:42 GMT+01:00 Eric Sunshine : > > Doesn't such a behavior change deserve being documented (and possibly > > tests)? > > The old behaviour was neither documented nor tested - the > change did not break any test

Re: [PATCH 1/2] git-svn: search --authors-prog in PATH too

Eric Sunshine wrote: > On Sun, Mar 4, 2018 at 6:22 AM, Andreas Heiduk wrote: > > In 36db1eddf9 ("git-svn: add --authors-prog option", 2009-05-14) the path > > to authors-prog was made absolute because git-svn changes the current > > directoy in some

Re: Reduce pack-objects memory footprint?

Duy Nguyen wrote: > struct revindex_entry { > off_t offset; > unsigned int nr; > }; > > We need on entry per object, so 6.5M objects * 16 bytes = 104 MB. If > we break this struct apart and store two arrays of offset and nr in > struct packed_git, we save 4

Re: Reduce pack-objects memory footprint?

Duy Nguyen wrote: > which saves 12 bytes (or another 74 MB). 222 MB total is plenty of > space to keep some file cache from being evicted. Nice! I can definitely benefit from lower memory usage when packing. Fwiw, I use pahole with other projects to help find packing

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Jeff King <p...@peff.net> wrote: > On Wed, Feb 28, 2018 at 04:07:18AM +0000, Eric Wong wrote: > > > > In the rest of git, die() makes a command exit with status 128. The > > > trouble here is that our code in Perl is assuming the same meaning for > > > die

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Jonathan Nieder wrote: > The fundamental thing is the actual Git commands, not the tests in the > testsuite, no? Right. I've never been picky about exit codes; only that a non-zero happens on errors. > In the rest of git, die() makes a command exit with status 128. The >

[PATCH] git-svn: control destruction order to avoid segfault

o fetch changes up to 2784b8d68faca823489949cbc69ead2f296cfc07: git-svn: control destruction order to avoid segfault (2018-01-29 23:12:00 +) ---- Eric Wong (1): git-svn: control destruction order to avoid segfault git-svn.perl | 5 +

Re: git send-email sets date

Ævar Arnfjörð Bjarmason wrote: > On Fri, Jan 26, 2018 at 6:32 PM, Michal Suchánek wrote: > > This is wrong because the message will most likely not get delivered > > when the author date differs from current time. Even by a few seconds? I guess it depends

Re: Shawn Pearce has died

Johannes Schindelin wrote: > Hey fellow gitters, > > I found these sad news in my timeline today: > > https://twitter.com/cdibona/status/957822400518696960 I'm shocked and in denial over this. Thank you, Shawn! And thank you Johannes for passing this along.

Re: t9128 failing randomly with svn 1.9?

Todd Zullinger wrote: > brian m. carlson wrote: > > r7 = f8467f2cee3bcead03e84cb51cf44f467a87457d > > (refs/remotes/origin/tags/tag3) > > error: git-svn died of signal 11 > > > > Doing the following three times, I had two crashes. > > > > (set -e; for i in $(seq 1 20); do (cd t

Re: Git packs friendly to block-level deduplication

Ævar Arnfjörð Bjarmason wrote: > If you have a bunch of git repositories cloned of the same project on > the same filesystem, it would be nice of the packs that are produced > would be friendly to block-level deduplication. Fwiw, I currently get around this when mirroring by

Re: [PATCH v5] mru: Replace mru.[ch] with list.h implementation

Gargi Sharma wrote: > 7 files changed, 15 insertions(+), 86 deletions(-) Thanks! I like the code reduction and increased use of list.h Were you able to finish running the test suite? I wasn't :< > -void mru_clear(struct mru *head) > -{ > - struct list_head *pos; > -

Re: git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312

Jason Pyeron wrote: > > I am asuming that this is an issue caused by codeplex's svn > from tfs implementation. Does anyone here have any insight? Seems like it, even using svn(1) fails (see below) > r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn) >

[PATCH] fsck: fix leak when traversing trees

While fsck_walk/fsck_walk_tree/parse_tree populates "struct tree" idempotently, it is still up to the fsck_walk caller to call free_tree_buffer. Fixes: ad2db4030e42890e ("fsck: remove redundant parse_tree() invocation") Signed-off-by: Eric Wong <e...@80x24.org> ---

Re: [PATCH v3] mru: Replace mru.[ch] with list.h implementation

Gargi Sharma wrote: > --- a/list.h > +++ b/list.h > @@ -93,6 +93,13 @@ static inline void list_move(struct list_head *elem, > struct list_head *head) > list_add(elem, head); > } > > +/* Move to the front of the list. */ > +static inline void list_move_to_front(struct

Re: git svn clone of messy repository

Jason Greenbaum wrote: > --trunk=trunk/project_of_interest \ > --branches=branches/FF-1.0/project_of_interest \ > --branches=branches/FF-1.1/project_of_interest \ > The trunk seems to become the 'master' branch just fine, but my svn > branches are not pulled down. I'm not sure I

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

support changes should be tree-wide. > On Sun, Dec 24 2017, Eric Wong jotted: > > Maybe we change our docs to say we welcome 5.10 features for new > > code, but I'm against changing things for the sake of change. > > I should have mentioned this in the commit message, but for me

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

Ævar Arnfjörð Bjarmason wrote: > On Sun, Dec 24 2017, Jeff King jotted: > > As far as this actual perl change goes, I don't have a strong opinion. I > > agree it would be nice to eventually move forward, and your reasoning > > about what constitutes "old" seems sane. But we also

[PATCH] git-svn: convert CRLF to LF in commit message to SVN

bded25d55243dfb291: git-svn: convert CRLF to LF in commit message to SVN (2017-12-14 00:09:38 +) Eric Wong (1): git-svn: convert CRLF to LF in commit message to SVN git-svn.perl| 1 + t/t9169-git-svn-dc

Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules

Jonathan Nieder wrote: > Yeah, people really do use Git.pm as an external API. Yikes :< > If we want to prevent this, then we should not be installing it in the > public perl module path. Or we should at least add a note to the > manpages we ship :) to recommend not using

[PATCH v2] rebase: use mboxrd format to avoid split errors

Sorry, I forgot about this for a while :x Florian Weimer <fwei...@redhat.com> wrote: > On 10/08/2017 11:30 PM, Eric Wong wrote: > >diff --git a/git-rebase--am.sh b/git-rebase--am.sh <snip, identical change below> > My context is slightly different, but I added the

Re: Special strings in commit messages

ot;From " lines in commit messages without being misinterpreted by mailsplit Reported-by: Florian Weimer <fwei...@redhat.com> Signed-off-by: Eric Wong <e...@80x24.org> --- git-rebase--am.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index

Re: BUG in git diff-index

Marc Herbert wrote: > PS: I used NNTP and http://dir.gmane.org/gmane.comp.version-control.git > to quickly find this old thread (what could we do without NNTP?). Then > I googled for a web archive of this thread and Google could only find > this one: >

Re: [PATCH] git svn fetch: Create correct commit timestamp when using --localtime

Junio C Hamano wrote: > Urs Thuermann writes: > > > In parse_svn_date() prepend the correct UTC offset to the timestamp > > returned. This is the offset in effect at the commit time instead of > > the offset in effect at calling time. > > > >

[PATCH] set FD_CLOEXEC properly when O_CLOEXEC is not supported

FD_CLOEXEC only applies to the file descriptor, so it needs to be manipuluated via F_GETFD/F_SETFD. F_GETFL/F_SETFL are for file description flags. Verified via strace with o_cloexec set to zero. Signed-off-by: Eric Wong <e...@80x24.org> --- sha1_file.c | 6 +++--- 1 file changed, 3 inse

Re: reftable: new ref storage format

Jeff King wrote: > I agree that a full binary search of a reftable is harder because of the > prefix compression (it may still be possible by scanning backwards, but > I think there are ambiguities when you land in the middle of a record, > since there's no unambiguous

Re: [PATCH 6/6] reflog-walk: stop using fake parents

Jeff King <p...@peff.net> wrote: > On Fri, Jul 07, 2017 at 12:32:39AM +0000, Eric Wong wrote: > > > I'm not sure why, but this is causing t1414.8 failures on 32-bit > > x86 with the latest pu with Debian jessie (oldstable). > > > > Reverting this (beafb2c6294

Re: [PATCH 6/6] reflog-walk: stop using fake parents

I'm not sure why, but this is causing t1414.8 failures on 32-bit x86 with the latest pu with Debian jessie (oldstable). Reverting this (beafb2c62947a6d4a97b9c3baf99fe62ec8e830f) in pu seems to fix the test for me. +Cc: Ramsay since he also had a 32-bit environment. --8<-- ok 7 - --parents shows

Re: Monitoring a repository for changes

Eric Wong <e...@80x24.org> wrote: > And, yes, email does seem redundant, and > modern header sizes (with DKIM, etc) are gigantic; but > connection lifetime and concurrency is manageable to the server > even if not instantaneous. I should add that any email notificat

Re: Monitoring a repository for changes

Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Wed, Jun 21 2017, Eric Wong jotted: > > I've long wanted to do something better to allow others to keep > > public-inbox mirrors up-to-date. Having only 64-128 bytes of > > overhead per userspace per-connecti

Re: Monitoring a repository for changes

Ævar Arnfjörð Bjarmason wrote: > On Wed, Jun 21 2017, Tim Hutt jotted: > > > Hi, > > > > Currently if you want to monitor a repository for changes there are > > three options: > > > > * Polling - run a script to check for updates every 60 seconds. > > * Server side hooks > > *

Re: [PATCH] git-svn: document special options for commit-diff

Andreas Heiduk wrote: > Some options specific for `git svn commit-diff` where not documented > so far. > > Signed-off-by: Andreas Heiduk Thanks again. It's been a while since "commit-diff" :) Signed-off and pushed for Junio: The following changes

[ANNOUNCE] public-inbox.org/git/ search updates for diffs

Hey all, https://public-inbox.org/git/_/text/help has a few new prefixes which might help improve searching: dfn: match filename from diff dfa: match diff removed (-) lines dfb: match diff added (+) lines dfhh:match diff hunk header context

Re: [PATCH v2 1/2] git-compat-util: add a FREEZ() wrapper around free(ptr); ptr = NULL

Junio C Hamano <gits...@pobox.com> wrote: > Eric Wong <e...@80x24.org> writes: > > I don't see the point of a macro wrapper, forcing the user to > > type out the '&' should drive home the point that the pointer > > gets set to NULL. I also find capitali

Re: [PATCH v2 1/2] git-compat-util: add a FREEZ() wrapper around free(ptr); ptr = NULL

Jonathan Nieder wrote: > Hi, > > Ævar Arnfjörð Bjarmason wrote: > > > Add a FREEZ() wrapper marco for the common pattern of freeing a > > pointer and assigning NULL to it right afterwards. > > I'm conflicted. On one hand it makes code more concise and makes it > easier for

Re: [PATCH] doc: describe git svn init --ignore-refs

Andreas Heiduk wrote: > Add the missing documentation for `git svn init --ignore-refs`. > > Signed-off-by: Andreas Heiduk Thanks, signed-off and pushed for Junio: The following changes since commit 8d1b10321b20bd2a73a5b561cfc3cf2e8051b70b: Sync

Re: public inbox links, was: Re: preserve untracked cache, was Re: What's cooking in git.git (Jun 2017, #01; Thu, 1)

Stefan Beller wrote: > Today I learned again how public-inbox is awesome! Thanks Eric! You're welcome :) > * You can just copy the message ID INCLUDING the surrounding < > > and public inbox still just shows you the correct message. I had assumed > you would need to

[PATCH] name-rev: use larger timestamp for is_better_name

This fixes t4202 for me at "44 - log --graph with full output" on 32-bit x86. Signed-off-by: Eric Wong <e...@80x24.org> --- This is for pu, I'm still using the machine I used git with in 2005 :) builtin/name-rev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --gi

[TANGENT] run-command: use vfork instead of fork

e to bash, dash, make, and perl5. 8< Subject: [PATCH] run-command: use vfork instead of fork To enable vfork, we merely have to avoid modifying memory we share with the parent, so the guard functions `child_(error|warn|die)_fn` can now be disabled. FIXME: still missing au

Re: vger not relaying some of Junio's messages today?

Samuel Lijin wrote: > > Samuel Lijin wrote: > >> Yep, I see these on public-inbox.org/git/ but not in my gmail inbox: > > > > Hi Samuel, check your Spam box (and move it to a normal inbox so > > they can train it). Gmail filters are known to trigger happy >

Re: vger not relaying some of Junio's messages today?

Samuel Lijin wrote: > Sorry, should've been clearer - I did check my spambox in my original > message. Some old patches from Brandon were in there, but the ones I > mentioned in my original message just seem to have been dropped. Apparently, vger also throttles mail to gmail

Re: vger not relaying some of Junio's messages today?

Eric Wong <e...@80x24.org> wrote: > (OTOH, I noticed a thread/mbox download bug in public-inbox, > https://public-inbox.org/git/xmqqmvaq702u@gitster.mtv.corp.google.com/t.mbox.gz > only shows two messages out of many. Will need to fix that...) I think I fixed that bug,

Re: vger not relaying some of Junio's messages today?

Junio C Hamano wrote: > As it is a pain to access gmail inbox via imap (I was told that > something called "offline imap" may alleviate the pain, but I > haven't tried it yet), offlineimap isn't bad; I've been using it since 2003-2004 and can say it's easier-to-setup and more

Re: vger not relaying some of Junio's messages today?

Ævar Arnfjörð Bjarmason wrote: > Thanks a lot for public-inbox, my only problem with it is that it > doesn't cover every single mailing list I'm on, just git :) Yes, I'm hoping more folks can start running their own instances. I notice you're on p5p where I started to

Re: vger not relaying some of Junio's messages today?

(I have no idea what Jonathan Tirado wrote; it was encrypted (but sent to a public list). Samuel Lijin wrote: > Yep, I see these on public-inbox.org/git/ but not in my gmail inbox: Hi Samuel, check your Spam box (and move it to a normal inbox so they can train it). Gmail

Re: Bug? git svn tag Authentication failed

Ethan Clevenger wrote: > Git version: 2.12.2.windows.2 > > `git svn tag 1.0` results in: Note, "git svn tag" uses the same backend code as "git svn branch", and there was a recent fix for that in commit e0688e9b28f2c5ff711460ee8b62077be5df2360 ("git svn: fix

Re: [PATCH v5 11/11] run-command: block signals between fork and execve

Johannes Sixt wrote: > Am 19.04.2017 um 01:18 schrieb Brandon Williams: > >@@ -400,6 +404,53 @@ static char **prep_childenv(const char *const *deltaenv) > > } > > #endif > > > > Does this #endif in this hunk context belong to an #ifndef > GIT_WINDOWS_NATIVE? If so, I wonder why

Re: [PATCH v4 05/10] run-command: prepare child environment before forking

+Cc Karsten for comments below... Brandon Williams wrote: > In order to avoid allocation between 'fork()' and 'exec()' prepare the > environment to be used in the child process prior to forking. > > Switch to using 'execve()' so that the construct child environment can > used

Re: [PATCH v3 10/10] run-command: block signals between fork and execve

Brandon Williams wrote: > On 04/14, Brandon Williams wrote: > > /* > > +* restore default signal handlers here, in case > > +* we catch a signal right before execve below > > +*/ > > + for (sig = 1; sig < NSIG; sig++) {

Re: [PATCH v3 06/10] run-command: don't die in child when duping /dev/null

Brandon Williams wrote: > + if (cmd->no_stdin || cmd->no_stdout || cmd->no_stderr) { > + null_fd = open("/dev/null", O_RDWR | O_CLOEXEC | O_NONBLOCK); O_NONBLOCK? This was in my original patch, too :x Wow, I wonder what I was smoking that day...

Re: [PATCH v3 07/10] run-command: eliminate calls to error handling functions in child

Brandon Williams wrote: > +++ b/run-command.c > @@ -211,14 +211,82 @@ static const char **prepare_shell_cmd(struct argv_array > *out, const char **argv) > #ifndef GIT_WINDOWS_NATIVE > static int child_notifier = -1; > > -static void notify_parent(void) > +enum

Re: [PATCH 7/6] run-command: block signals between fork and execve

Eric Wong <e...@80x24.org> wrote: > Brandon Williams <bmw...@google.com> wrote: > > On 04/13, Eric Wong wrote: > > > @@ -277,6 +278,8 @@ static void child_err_spew(struct child_process *cmd, > > > struct child_err *cerr) > > >

Re: [PATCH 7/6] run-command: block signals between fork and execve

Brandon Williams <bmw...@google.com> wrote: > On 04/13, Eric Wong wrote: > > @@ -277,6 +278,8 @@ static void child_err_spew(struct child_process *cmd, > > struct child_err *cerr) > > error_errno("exec '%s': cd to '%s' failed", > >

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

Brandon Williams <bmw...@google.com> wrote: > On 04/13, Eric Wong wrote: > > Jonathan Nieder <jrnie...@gmail.com> wrote: > > > Brandon Williams wrote: > > > > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > > > > &q

[PATCH 7/6] run-command: block signals between fork and execve

we control can fire in the child. Continue ignoring ignored signals, but reset the rest to defaults. Similarly, disable pthread cancellation to future-proof our code in case we start using cancellation; as cancellation is implemented with signals in glibc. Signed-off-by: Eric Wong <e...@80x24

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

Jonathan Nieder wrote: > Brandon Williams wrote: > > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > > "!#/bin/sh" line which can cause issues with portability. Instead > > create the hook using the 'write_script' function which includes the > >

Re: [PATCH v2 4/6] run-command: don't die in child when duping /dev/null

Brandon Williams wrote: > @@ -487,7 +483,7 @@ int start_command(struct child_process *cmd) > atexit(notify_parent); > > if (cmd->no_stdin) > - dup_devnull(0); > + dup2(null_fd, 0); I prefer we keep error

Re: [PATCH 5/5] run-command: add note about forking and threading

Brandon Williams <bmw...@google.com> wrote: > On 04/11, Eric Wong wrote: > > On the other hand, I believe we should make run-command > > vfork-compatible (and Brandon's series is a big (but incomplete) > > step in the (IMHO) right direction); as anything which is > &

Re: [PATCH 6/5] run-command: avoid potential dangers in forked child

Brandon Williams <bmw...@google.com> wrote: > On 04/11, Eric Wong wrote: > > Hi Brandon, this series tickles an old itch of mine, so I > > started working off of it. I'm only somewhat concerned > > with the path resolution in execvp(e) pontentially calling > > ma

[PATCH 6/5] run-command: avoid potential dangers in forked child

unt chdir usage). Signed-off-by: Eric Wong <e...@80x24.org> --- run-command.c | 273 +- 1 file changed, 196 insertions(+), 77 deletions(-) diff --git a/run-command.c b/run-command.c index 2b3249de4..3d7a57385 100644 --- a/run-command.c

Re: [PATCH 5/5] run-command: add note about forking and threading

Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > --- a/run-command.c > > +++ b/run-command.c > > @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd) > > argv_array_pushv(, cmd->argv); > > } > > > > + /* > > +* NOTE: In

Re: Modifying a bare repo directly

Julian Goacher wrote: > Is it possible to modify a bare repo directly? e.g. is it possible to > insert a file into a bare repo without first cloning a non-bare copy? > I'm thinking along the lines of a command or sequence of commands that > modifies the file index and

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

Lars Schneider wrote: > > diff --git a/convert.h b/convert.h > > index 82871a11d5..da6c702090 100644 > > --- a/convert.h > > +++ b/convert.h > > @@ -42,6 +42,11 @@ extern int convert_to_git(const char *path, const char > > *src, size_t len, > >

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Mon, Apr 3, 2017 at 11:34 PM, Eric Wong <e...@80x24.org> wrote: > > Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > >> - Should we be covering good practices for your repo going forward to > >

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

Ævar Arnfjörð Bjarmason wrote: > Add a new manpage that gives an overview of how to tweak git's > performance. > > There's currently no good single resource for things a git site > administrator might want to look into to improve performance for his > site & his users. This

Re: git svn and SVN property svn:original-date

Craig McQueen <craig.mcqu...@innerrange.com> wrote: > Eric Wong wrote: > > Craig McQueen <craig.mcqu...@innerrange.com> wrote: > > > Apparently SVN revisions can have an "svn:original-date" property, which > > would be good to set on dcommit, to pres

Re: git svn propset and multi-line svn:externals property

Craig McQueen wrote: > Is it possible to set multi-line SVN properties somehow? Or > could this be a future enhancement? I'm not sure. I don't use this feature, but it seems tied to gitattributes(5), and I'm not sure if gitattributes supports multi-line values,

Re: git svn and SVN property svn:original-date

Craig McQueen wrote: > When doing "git svn dcommit", the SVN revision just has the date/time stamp > of the time of the dcommit. Yeah, that's sometimes annoying to me, too. > Apparently SVN revisions can have an "svn:original-date" property, which > would be good

Re: Issues with git send-email and msmtp

Jeff King wrote: > On Tue, Mar 21, 2017 at 03:49:21PM +, Roger Pau Monné wrote: > > > I'm trying to use git send-email with msmtp, and I have added the following > > to > > my .gitconfig: > > > > [sendemail] > > smtpserver = "/usr/local/bin/msmtp" > > > > This seems to

Re: Safe to use stdatomic.h?

"brian m. carlson" wrote: > I could support the argument for ditching RHEL/CentOS 5 support, but I > expect other people might disagree. After all, we're still targeting > C89. Yeah, I still use and support CentOS 5 in some places (but maybe not git, still using

[PULL] git svn branch authentication fix

Thank you. I fixed spelling in the title (s/authenticaton/authentication/), added my S-o-b, and pushed for Junio to pick up The following changes since commit 3bc53220cb2dcf709f7a027a3f526befd021d858: First batch after 2.12 (2017-02-27 14:04:24 -0800) are available in the git repository at:

[PATCH v2] http: inform about alternates-as-redirects behavior

Jeff King <p...@peff.net> wrote: > On Sat, Mar 04, 2017 at 06:55:48AM +0000, Eric Wong wrote: > > Jeff King <p...@peff.net> wrote: > > > The warning itself: > > > > > > > + warning("alternate disabled by > > > > h

Re: [PATCH] http: inform about alternates-as-redirects behavior

Jeff King wrote: > The warning itself: > > > + warning("alternate disabled by http.followRedirects!=true: %s", > > feels like it could use some whitespace around the "!=", but maybe > that's just me. Yeah, I kinda wanted to emulate the command-line syntax. Maybe

[PATCH] http: release strbuf on disabled alternates

This likely has no real-world impact on memory usage, but it is cleaner for future readers. Fixes: abcbdc03895f ("http: respect protocol.*.allow=user for http-alternates") Signed-off-by: Eric Wong <e...@80x24.org> --- http-walker.c | 2 ++ 1 file changed, 2 insertions(+) d

[PATCH] http: inform about alternates-as-redirects behavior

to enable http.followRedirects in their config. Signed-off-by: Eric Wong <e...@80x24.org> --- http-walker.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/http-walker.c b/http-walker.c index b34b6ace7..626badfe6 100644 --- a/http-walker.c +++ b/http-walker.c @@ -168,6 +168,

Re: [PATCH] README: create HTTP/HTTPS links from URLs in Markdown

Jeff King <p...@peff.net> wrote: > On Thu, Mar 02, 2017 at 07:34:21AM +0000, Eric Wong wrote: > > Jeff King <p...@peff.net> wrote: > > > On Wed, Mar 01, 2017 at 10:22:04PM +, Eric Wong wrote: > > > > > > > Markdown supports automatic li

  1   2   3   4   5   6   7   >