Re: [PATCH 0/3] Clarify interaction between signed pushes and push options

Jonathan Tan writes: > We noticed this when trying to use Git to make a signed push with push > options to a server using JGit (which rejects such pushes because the > Git client makes requests that are, strictly speaking, incompatible with > the documented protocol). >

Re: [PATCH v2 7/7] t4051: mark supporting files as requiring LF-only line endings

Johannes Schindelin writes: > The test t4051-diff-function-context.sh passes on Linux when > core.autocrlf=true even without marking its support files as LF-only, > but they fail when core.autocrlf=true in Git for Windows' SDK. > > The reason is that `grep ...

Re: [PATCH v2 6/7] Fix the remaining tests that failed with core.autocrlf=true

Johannes Schindelin writes: > Note: the test suite also uses the t/README file as well as the COPYING > file in t/diff-lib/, expecting LF-only line endings explicitly and > failing if that assumption does not hold true. That is why we mark them > as LF-only in the

Re: [PATCH v2 5/7] t4003, t4005, t4007 & t4008: handle CR/LF in t/README & t/diff-lib/README

Johannes Schindelin writes: > diff --git a/t/t4003-diff-rename-1.sh b/t/t4003-diff-rename-1.sh > index df2accb6555..c3e0a3c3fc9 100755 > --- a/t/t4003-diff-rename-1.sh > +++ b/t/t4003-diff-rename-1.sh > @@ -11,7 +11,7 @@ test_description='More rename detection > >

Re: [PATCH v2 4/7] t3901: move supporting files into t/t3901/

Johannes Schindelin writes: > The current convention is to either generate files on the fly in tests, > or to use supporting files taken from a t/t/ directory (where > matches the test's number, or the number of the test from which we > borrow supporting

Re: [PATCH v2 2/7] git-new-workdir: mark script as LF-only

Johannes Schindelin writes: > Bash does not handle scripts with CR/LF line endings correctly, therefore > they *have* to be forced to LF-only line endings. > > Funnily enough, this fixes t3000-ls-files-others and > t1021-rerere-in-workdir when git.git was checked out

Re: [PATCH v2 1/7] Fix build with core.autocrlf=true

Johannes Schindelin writes: > When generating common-cmds.h, the Unix tools we use generally operate on > the assumption that input and output deliminate their lines using LF-only > line endings. Consequently, they would happily copy the CR byte verbatim > into the

Re: [PATCH] pack-objects: disable pack reuse for object-selection options

Jeff King writes: > If certain options like --honor-pack-keep, --local, or > --incremental are used with pack-objects, then we need to > feed each potential object to want_object_in_pack() to see > if it should be filtered out. This is totally contrary to > the purpose of the

Re: [PATCH v2 6/9] dir: change linkage of cmp_name() and check_contains()

Samuel Lijin writes: > diff --git a/dir.h b/dir.h > index bf23a470a..1ddd8b611 100644 > --- a/dir.h > +++ b/dir.h > @@ -326,6 +326,9 @@ static inline int dir_path_match(const struct dir_entry > *ent, > has_trailing_dir); > } > > +int

Re: [PATCH v2 2/9] t7061: expect failure where expected behavior will change

Samuel Lijin writes: > This changes tests for `status --ignored` from test_expect_success to > test_expect_failure in preparation for a change in its expected behavior > (namely, that ignored files in untracked dirs will be reported). > > Signed-off-by: Samuel Lijin

Re: [RFC] Add warning when git discard changes on another branch?

On Mon, May 08, 2017 at 01:19:58PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > But to help "some users are not aware of this" situation, an opt-in > > "feature" would not help all that much. The same number of lines in > > the documentation to tell end-users

Re: [PATCH v2 0/9] Keep git clean -d from inadvertently removing ignored files

Samuel Lijin writes: > Addresses the issues raised by Stefan and Junio (thanks for your > feedback) about not using C99-style comments and keeping tests > working on every commit to prevent breaking git bisect. (About the > latter one: is it necessary to prevent compiler

Re: [RFC] Add warning when git discard changes on another branch?

Junio C Hamano writes: > But to help "some users are not aware of this" situation, an opt-in > "feature" would not help all that much. The same number of lines in > the documentation to tell end-users how to toggle on such a "safety" > feature can be spent to teach them that

Re: [PATCH v3] send-email: --batch-size to work around some SMTP server limit

xiaoqiang zhao writes: > @@ -1664,6 +1674,14 @@ foreach my $t (@files) { > } > } > $message_id = undef; > + $num_sent++; > + if ($num_sent == $batch_size) { > + $num_sent = 0; > + $smtp->quit; > + $smtp =

Re: [RFC] Add warning when git discard changes on another branch?

On Mon, May 08, 2017 at 12:41:03PM +0900, Junio C Hamano wrote: > Yubin Ruan writes: > > > I understand this. I just suggest that git add some warning in case some > > users > > are not aware of this, as it does when , on branch 'issue', changes to > > 'lala.txt' > >

Re: [RFC] Add warning when git discard changes on another branch?

Yubin Ruan writes: > I understand this. I just suggest that git add some warning in case some users > are not aware of this, as it does when , on branch 'issue', changes to > 'lala.txt' > are based on a commit different from where the checkout happened, i.e. > >

Re: [RFC] Add warning when git discard changes on another branch?

On Mon, May 08, 2017 at 12:05:31PM +0900, Junio C Hamano wrote: > Yubin Ruan writes: > > > I think it would be better if git can warn use if we switch to another > > branch > > without committing the modification. Git will warn if the modification is > > based > > on a

Re: [RFC] Add warning when git discard changes on another branch?

Yubin Ruan writes: > I think it would be better if git can warn use if we switch to another branch > without committing the modification. Git will warn if the modification is > based > on a commit different from where the checkout happened. > > For example, say I am now

Re: Git smart http: parsing commit messages in git-receive-pack

Bryan Turner writes: > That means if you pair a pre-receive hook with Git 2.11 or newer on > the server, you should be able to achieve what you're looking for. It probably is worth mentioning that even without the "quarantine" changes of 2.11, the new objects brought in

Re: [PATCH v2] tests: fix tests broken under GETTEXT_POISON=YesPlease

Ævar Arnfjörð Bjarmason writes: > Junio: I think between Travis now testing for this & the scary i18n > reflog regression (not that poison caught that, but that was lack of > testing, poisoining catches that class of issue) it makes sense to > discard my patch for removing

Re: [PATCH v7 00/10] refactor the filter process code into a reusable module

Ben Peart writes: > Changes from V6 include: > > convert: remove erroneous tests for errno == EPIPE > - split into separate patch to fix a preexisting bug discovered in the > review process Thanks. > pkt-line: Update packet_read_line() to test for len > 0 > - split into

Re: [PATCH 0/2] split index extra bits

Junio C Hamano writes: > Christian Couder writes: > >> This patch series contains 2 patches that have already been sent to >> the list but have felt through the cracks. It would be nice if they >> could be considered for v2.13.0. > > There is no

Re: [PATCH 0/2] split index extra bits

Christian Couder writes: > This patch series contains 2 patches that have already been sent to > the list but have felt through the cracks. It would be nice if they > could be considered for v2.13.0. There is no way for anything new to go to 2.13 without getting

Re: [PATCH] doc: replace a couple of broken gmane links

Junio C Hamano writes: >> Perhaps someone else will have better luck with the other ones, which >> are: Here is my attempt to fill the remainder. Documentation/git-bisect-lk2009.txt | 2 +- git-rebase--interactive.sh | 2 +- t/t4038-diff-combined.sh| 2

Re: [PATCH] doc: replace a couple of broken gmane links

Ævar Arnfjörð Bjarmason writes: > Replace a couple of broken links to gmane with links to other > archives. See commit 54471fdcc3 ("README: replace gmane link with > public-inbox", 2016-12-15) for prior art. > > With this change there's still 4 references left in the code: > >

Re: [RFC PATCH 02/10] Move textconv_object to be with other textconv methods

Stefan Beller writes: > I guess it is ok for now and in this series, but we may want > to split up diff.[ch] in the future into multiple finer grained files. For what end? Such a split would require more symbols internal to diff.[ch] to become external, which is a big

Re: [PATCH 0/7] Update the compat/regex engine from upstream

Ævar Arnfjörð Bjarmason writes: > See the first patch for motivation & why. I do not think it quite explains the motivation, though. "Doing this way, we can keep in sync with the upstream more easily"? Or is there anything more to it, e.g. "and we need to update from the

Re: [RESEND PATCH] diff: recurse into nested submodules for inline diff

Jacob Keller writes: > On Thu, May 4, 2017 at 2:43 PM, Stefan Beller wrote: >> When fd47ae6a5b (diff: teach diff to display submodule difference with an >> inline diff, 2016-08-31) was introduced, we did not think of recursing >> into nested

Re: [PATCH v4 11/25] checkout: fix memory leak

René Scharfe writes: >> /* >> * NEEDSWORK: >> * There is absolutely no reason to write this as a blob object >> - * and create a phony cache entry just to leak. This hack is >> - * primarily to get to the write_entry() machinery that massages >> - *

Re: [PATCH v2 00/21]

On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > Changes since v1: > > > > - fopen_or_warn() and warn_on_fopen_errors() are introduced. The > >latter's name is probably not great... > > - A new patch (first

Re: [PATCH v3 0/6] rebase -i: add config to abbreviate command-names

Liam Beguin writes: > Sorry for the delay, I don't mind switching to C but it would probably > be easier to see if the scripted version gets approved first. > If it does, I could then get started on the C implementation. > If you prefer I could also forget about the

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones writes: > Sure, I can add this. (Although, I don't think it actually > matters). > > Hmm, unless somebody objects in the meantime, I will re-roll > the patch (tomorrow, it's late!). Thanks.

Re: [PATCH 00/10] RFC Partial Clone and Fetch

Jonathan Nieder writes: > - there shouldn't be any need for the blobs to even be mentioned in > the .pack stored locally. The .idx file maps from sha1 to offset > within the packfile --- a special offset could mean "this is a > missing blob". Clever. > - However, the

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

Eric Wong writes: > 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. > >

[Announce] delaying 2.13 final by a few days

As -rc2 was delayed for a few days, I'd like to delay the release of the final 2.13 (which was originally scheduled on 8th) by a few days. For one thing that would give translaors a bit more time to update the message strings. Thanks.

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: [PATCH v3 0/6] rebase -i: add config to abbreviate command-names

Hi Junio, On Wed, 2017-05-03 at 22:04 -0700, Junio C Hamano wrote: > Johannes Schindelin writes: > > > > If 'git-rebase--interactive.sh' is bound to be replaced, I could > > > just shrink this to the Documentation cleanup (patches 4 and 5) > > > and rework the rest

[RFC] Add warning when git discard changes on another branch?

Hi, I think it would be better if git can warn use if we switch to another branch without committing the modification. Git will warn if the modification is based on a commit different from where the checkout happened. For example, say I am now on branch 'master' and all files *clean*. Now if I

Re: [PATCH 0/5] Abide by our own rules regarding line endings

Johannes Schindelin writes: > Let me repeat myself: Don't. Instead, read through what you are responding to the end before start typing a byte. In case you didn't do that, in the end I agree with the direction of the series ;-).

[GSoC] Project Selected: Incremental rewrite of git-submodules

Hey everyone, I am Prathamesh Chavan, an undergraduate student from the department of Computer Science and Engineering, at Indian Institue of Technology, Kharagpur. I applied for Google Summer of Code 2017 and my project "Incremental rewrite of git-submodules" has been selected. This project will

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

[PATCH v3] send-email: --batch-size to work around some SMTP server limit

Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session(connection) and this will lead to a faliure when sending many messages. Teach send-email to disconnect after sending a number of messages (configurable via the --batch-size= option), wait for a few seconds

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

Eric Wong 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, at least:

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: [PATCH 0/2] gitweb: tags feeds

Ping? On Wed, Apr 19, 2017 at 8:49 AM, Giuseppe Bilotta wrote: > A smallish patchset to implement RSS and Atom feeds to complement the > tags view, accessible as verbs `tags_rss` and `tags_atom`. > > (I actually made this some 5 years ago, and it has been running on >

Re: [PATCH v2 1/9] t7300: skip untracked dirs containing ignored files

On 2017-05-05 12:46, Samuel Lijin wrote: > If git sees a directory which contains only untracked and ignored > files, clean -d should not remove that directory. It was recently > discovered that this is *not* true of git clean -d, and it's possible > that this has never worked correctly; this test

Re: [PATCH v2] send-email: new options to walkaround email server limits

> 在 2017年5月2日，10:24，Junio C Hamano 写道： > > But I am having a huge problem seeing how this patch is correct. It > always is troubling to see a patch that makes the behaviour of a > program change even when the optional feature it implements is not > being used at all. Why

git and the Clang Static Analyzer

Hello, I compiled git/master using the clang 4.0 static analyzer with scan-build ./configure --with-libpcre --with-openssl scan-build make and here are the results: https://mail.aegee.org/dpa/scan-build-git-4fa66c85f11/ Please note, that the information is only about what gets actually